Re: [Cfrg] I-D Action: draft-irtf-cfrg-randomness-improvements-08.txt

John Mattsson <> Tue, 26 November 2019 12:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 249B21208C2 for <>; Tue, 26 Nov 2019 04:43:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kaCkSJtDy9up for <>; Tue, 26 Nov 2019 04:43:53 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 20DAC12081B for <>; Tue, 26 Nov 2019 04:43:52 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=IQKGhW7wrlby1gSVXOSLDEKX7L8/VNZ3M1sda0Ar+IgvFI1hRvfjs+xbWrrVKHR9bO+Lrb8EYk4ZOknCfhZlxajxWsG4rxKJDYK4TIsMvp4S8nrOxCde1InVivGMjg4ulrkXVI97a/Op7p4HWqGc7+TxVM850KJMZrirHwhrNF/rKv63jTbZvJTfQ2Nynm2RS5ZQ7ZhIpf5fj4mhdmLK7qLL8X2j4S4PkHmsgzD9AcAUYKCM/DtveZ5RUaiPmJYlzVu9WYk/eMcx3UQNMgnSbtHhMU9s/JfLefM2zCrPwiNnxtwJnbdlvX8hu2JV9brXZBz7Urglbd8WEtV+ZoQO1w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tgJ9Rdz2KRyfIJKZFSlwRUJ8OE6c3T2tYDrUwDMqiRM=; b=OH2q9QkTu+sWWFtgNKJ9fsy5d6Ac07LeCoA9WbZxL3C/ORw3MNtU9LnEx12vgKhMO2MQk90IQ4yH8x80dleFOPwv5AFNwPCDP1RviNBpqI21oAUc4bjddtuON91WiEMHQNOxMIYdBe/xOGNnZ10XPnp6b/+vrYoQvrXivMcECh+j/41aPKsULWxfJwRlZIQRG759Bqi6cR4btnoeLDCSxHI20BPHJpBgXtDelbg88FMT7qPG5kA2sttpcWTIw+rk4IEz1Gg6w/uaiYEsS7RFu9peGsFtoA4FOsKhySqo5gLp3G+gAaSyz1f4drylAVpBCx8e4p2Hu9OOeGHj1ep9uQ==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tgJ9Rdz2KRyfIJKZFSlwRUJ8OE6c3T2tYDrUwDMqiRM=; b=jw4HkuvgdF51XoMaRlo4n8osUIOc4xx0u0q+ytFSf5YLnHwPsgv73VQoLF1cctk9KM9VM6F+Thm30RdMUd8+fWN77UQcG57OZzsL0nTGUmhUS1EfzntZP+9piKbQeB+3rQEpRgEehKNsPrBEGV250snDoQZvNOFkOrwKKjXpcWM=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.10; Tue, 26 Nov 2019 12:43:50 +0000
Received: from ([fe80::21e5:eaae:99ed:41ac]) by ([fe80::21e5:eaae:99ed:41ac%3]) with mapi id 15.20.2495.014; Tue, 26 Nov 2019 12:43:50 +0000
From: John Mattsson <>
To: "Stanislav V. Smyshlyaev" <>, "Riad S. Wahby" <>
CC: "" <>
Thread-Topic: [Cfrg] I-D Action: draft-irtf-cfrg-randomness-improvements-08.txt
Date: Tue, 26 Nov 2019 12:43:50 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-GB
user-agent: Microsoft-MacOutlook/10.1f.0.191110
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9266f018-48b5-4035-3543-08d7726e49b5
x-ms-traffictypediagnostic: HE1PR07MB4154:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0233768B38
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(396003)(136003)(376002)(39860400002)(199004)(189003)(51444003)(13464003)(76176011)(186003)(81156014)(8676002)(6512007)(6506007)(81166006)(2616005)(6306002)(53546011)(446003)(26005)(102836004)(14454004)(305945005)(11346002)(8936002)(5660300002)(478600001)(3846002)(6246003)(25786009)(966005)(4326008)(86362001)(229853002)(91956017)(7736002)(44832011)(6486002)(64756008)(58126008)(76116006)(6436002)(6116002)(33656002)(110136005)(316002)(66476007)(66446008)(36756003)(66946007)(66066001)(14444005)(2906002)(71200400001)(71190400001)(256004)(66556008)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4154;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: bLNKbXfUWx6sTRtBzGn5A2+0KOQOTkKH8hVtJ7rfYcl4IuWp6CD2yc5Hl18X5ORZcGfUshkmdMsU1R3AK9EXxnTAThGENkFdLE+ZT9qnCXgAGSBOc7jcbG3Iv6FPd7nZ40A01FnxCOtqONQkJVp9yO0p8lXKQadXioFPBTW9jtIvSFlUkdnoXbCtpg0XDgJc6WmMjDEnD2Te4XvwbJmT2r376p3yrTJqpyIIfwWhM5b+yjz+3be+xb4Kn4Z6xthOXu0k/tJzP/eEdscnm4jJ1hFWX1+lKkv4y+wLdoNbyMBVr6y5S7f+sVdLUGQmL2fSJTBynhPi+iPvs/uW692TfrwwsTo7pxkA7jSFBNachui3LbUcJd9yhBN8JMbThxXZ/U7gZN1guMYLNSXEnaIggYnxUevyeRp7bE0EcW+uknSqYQCrTi+5mI9lcDgb9jofhzOZ8S/4dhFGIIrZ3S6oVPNBoTLfo78CcKRL78LzVRQ=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 9266f018-48b5-4035-3543-08d7726e49b5
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Nov 2019 12:43:50.3916 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: hRWdMbuj7BlB39w44OT4XcF8wVNQR5cUAOhXehFeHN0EARI7MoMvH2yXo+mKAiyS4NcJkbHxJ0CqKiRCWrSCjyB3PBUXPXqAxY9sMTb1IHs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4154
Archived-At: <>
Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-randomness-improvements-08.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Nov 2019 12:43:56 -0000

Thanks for answers Stanislav!

Stanislav V. Smyshlyaev wrote:

>The security analysis can be modified for HMAC instead of Signature without
>significant problems, I suppose. And also several useful alternative
>constructions can be proposed (based on HMAC or DH as an operation with a

I think that would be a very useful thing for CFRG to do in a new draft. Even if you only look at TLS servers, they may only have a PSK (RFC 4279 or TLS 1.3), and in the future, they may only have a static DH key (draft-rescorla-tls-semistatic-dh-02). More good recommendations and concrete constructs for randomness is very needed practically. The ideas in the draft to 
use a context tag1, a nonce tag2, to split of inside HSM/outside HSM, and to prove the security of the construction are great.

How to use randomness is also a topic for discussion (I don’t suggest inclusion in this draft). NIST (FIPS 186-5 Draft) is currently planning to include deterministic ECDSA but does not recommend it in general due to side-channel and fault attacks ( One of the recommendation in that paper is to calculate k based on the message, but with added noise, an approach implemented in several places such as

>As an example, it can happen if CSPRNG used by some user gets its data based on a joint
>system entropy pool, which can be affected by another user (an adversary).

Ok, that is a good explanation why the attacker could control the CSPRNG but not other parameters. I would suggest adding that to the draft.

>Which word would you suggest instead of “dynamically”?.

unique or nonce would be better. Looking at the draft again, I think it would make sense to just rename tag2 to "nonce" and tag1 to "context". That make things easier to understand and aligns with other RFCs.

>Yes, we’ve had a lot of discussions about whether to include this limitation (following
>from the security assessment, see [SecAnalysis]) into the I-D – just for the reasons you
>are talking about. But since we wanted our construction to be solid and well-proven for
>all recommended cases, we decided not to omit this limitation. And you are right about
>the encoding issue – the thing is that in the security assessment we assume that tag2
>can have 2^L’.

If you keep the limitation, I think you need to add more clarification and guidance to the reader.

- The limitation the construction cannot output more than L + L' bytes for each nonce tag2 would be good to write in a sentence.
- Given a fixed L (e.g. 32 in HMAC-SHA-256) and a need to generate N byte of randomness. Should the implementer then choose a N - L byte encoding for the counter tag2? (Even after reading [SecAnalysis], I do not understand why the encoding of tag2 would affect the output length n). Or should the implementer choose a small L' and then generate several outputs (with different tag2) and concatenate?
- Is L' fixed or can the implementation choose different encoding lengths for each value of tag2 depending on how many output bytes are needed.
- When using a function with fixed-length output like HMAC-SHA-256 the value of L is given. When using a function with variable-length output like KMAC128 the value L is set by the user. Any recommendation there, or are all values of L equally good?
- Is L fixed or can the implementation use different L for different values of tag1?


-----Original Message-----
From: Cfrg <>; on behalf of "Riad S. Wahby" <>;
Date: Sunday, 24 November 2019 at 22:37
To: "Stanislav V. Smyshlyaev" <>;
Cc: ""; <>;
Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-randomness-improvements-08.txt

    "Stanislav V. Smyshlyaev" <>; wrote:
    > But this makes the scope of the I-D (initially motivated by TLS servers)
    > wider - a "menu of choices" of good solutions instead of one good solution.
    > If we want to do this, then, as it seems to me, the current process with an
    > I-D, which has already passed the RGLC and has moved to Waiting for
    > Document Shepherd stage, should be stopped and returned to the previous
    > stage of a work item before RGLC.
    In this case, it seems like a separate document for other constructions
    is definitely more appropriate---no sense introducing serious delay for
    this document.
    But: would it be possible to clarify, maybe just in the intro, that this
    document is primarily geared toward the HSM case?
    Cfrg mailing list