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

John Mattsson <> Wed, 20 November 2019 22:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 69E5B12082D for <>; Wed, 20 Nov 2019 14:34:02 -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 BSMVhWzdvR9K for <>; Wed, 20 Nov 2019 14:33:59 -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 7DD141200CE for <>; Wed, 20 Nov 2019 14:33:58 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=F3wEze4VhZDwa0V6+BuEuRsB0kKIu5WPC6Jm/G/aN9a7A3VFKUETXJHQ9ZNZnOwes3SD9b/wRZCr21Fi0e8Cpi36is5L3mOqxSE1szeiJcjR+jR2/SM7f+C6McrPSedfchzc8L1ZUr6fWFQSMYX6zekoUrzwNlczAbYQmkkHGrua949fQ4+elx4vhVSXbjRhicXfjZamw2gJ1svyI0P8qVM+GX/Jq8PXRfwKfpw7HgAXPJRB2Pw4kKlYlX9rzIMUgqXGSJkbHoSsTApwhL0C0wfBbnwW+bEp1u6oTraZCNrLUCkiptRRFJMGfjTH4n7tWXps2d4HPXVff0M935cSeQ==
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=4QhcMeRucYUK0iMESeFJjyvOTi5G0pn0tnuiZowqLBE=; b=Pf/8bhYCaSkDD6QVUdTcDe1GIf0Jt/lK1wHmmS+hS78Foub4jbtSyO8qAJ9sF7O1VkM9iX5ema5Vmj3c8VB9Pqm3pORhMrJrypG+AhNAQxLS62yIippGCjrUmOAHI2pX+XFjOyukvGAqAbXNyKBbhfqNvky7UGrx28+e+FYGrNFysRbbI1NFy5Jnss6gUbYC87iNLBUjdqiz4d4WKkOjQGUApVeRw0CHjlyElBlTAtF9wMz6CcHH3/80XvuLftDyUQJ/z0VlB90ffliruqHboKFNpFIU14JIV7/DHQpW5Y7dLthXRJCgPYgK3zndMQ4qbCHxp05fHFSNMtCsyKPkdw==
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=4QhcMeRucYUK0iMESeFJjyvOTi5G0pn0tnuiZowqLBE=; b=tb53Jsn1KqDjm9cmPIgivDiW/EnZv1yuZ+Cz2aQU4f1t42uNonwjZZr4lEx5PmkRiD2a81yOwVJom4CujK6Eewrwgl4b6n6ZKGVWEUvPb9HERA7zLzLwNyUehjclF4EeUNtgJh/vPTvc/HsELKl8ucVnuKRfUh1/HAlrbpBb37w=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.9; Wed, 20 Nov 2019 22:33:56 +0000
Received: from ([fe80::21e5:eaae:99ed:41ac]) by ([fe80::21e5:eaae:99ed:41ac%3]) with mapi id 15.20.2474.015; Wed, 20 Nov 2019 22:33:56 +0000
From: John Mattsson <>
To: "" <>
Thread-Topic: [Cfrg] I-D Action: draft-irtf-cfrg-randomness-improvements-08.txt
Thread-Index: AQHVkdcWzFRsDTDWKUiQumkHNsH2iKeVR5sA
Date: Wed, 20 Nov 2019 22:33:55 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-GB
user-agent: Microsoft-MacOutlook/10.1e.0.191013
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a7964062-7b85-455a-9fe7-08d76e09ba9c
x-ms-traffictypediagnostic: HE1PR07MB4283:
x-ms-exchange-purlcount: 7
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:5797;
x-forefront-prvs: 02272225C5
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(376002)(366004)(346002)(39860400002)(13464003)(199004)(189003)(14454004)(478600001)(11346002)(2616005)(446003)(1730700003)(81156014)(44832011)(8676002)(2906002)(966005)(66066001)(81166006)(5660300002)(486006)(476003)(2351001)(102836004)(5640700003)(6486002)(186003)(6512007)(26005)(66574012)(66556008)(66446008)(64756008)(6506007)(6306002)(66946007)(66476007)(36756003)(58126008)(256004)(2501003)(76116006)(14444005)(91956017)(6116002)(99286004)(305945005)(3846002)(7736002)(76176011)(33656002)(6246003)(8936002)(86362001)(6436002)(6916009)(229853002)(71200400001)(316002)(71190400001)(25786009)(574754004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4283;; 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: od443R6GiNhhjjXo0bUU5w7ky+mn04tDR3Wh4HSu3M17Pt7ND0qheW4gvwHVq+k+TVueKEO0EeacJlC5d0ccCTuEa0m+Nsv9vGeq7dA5DDeYsXNG6UVvS3rc/0yvpFLKZhTEsYx8ED5gTSpap+kU/KapZ1Nq9OsUaXI9ESCrCaSOefgCRoTtfuBhJQ5HPc4hOykN5uDS4R5XPhRjPJm6YsW8xRdztad62j2AkuZnV3lEJgPAOOVqXV8aEb98q11Ef1EKzNZDNddUlQQLOrW+KrHlygc67QqpEuIPZH1wvdEyZqVKqMZ9wzQjteECS0qhqp6B0ih7TEoJDTcZtIGvsKRxs8ZON02kexO2oweCL+RXcHjF37dcvyYfJlbJWT+Km11o+DFPwDKO4PMih6b7hyWuvQ1CiDVjfDsrLWOYD/sRKlJlrxXPmRQdWCxn4f168guzphcSKbzLPlmtBmSXJAuXjwNJYE8Jio7xZXuydlg=
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: a7964062-7b85-455a-9fe7-08d76e09ba9c
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2019 22:33:55.8233 (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: H/3zngxXQ1tq16b+1Vt0gXDKEVfU5xbvVsX4mUx937f/X7V7yO9lVRBmJVjYzgOmI5kfS8xlFqA6GE0EfFgrMBHvhIgQJwZPJ9RJ/aNG0Pg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4283
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: Wed, 20 Nov 2019 22:34:02 -0000


This draft was discussed and recommended during the LAKE WG ( session yesterday, which encouraged me to review it. Some comments and suggestions.

-- I think this is great. Improving randomness more generally than RFC 6979 is very much needed. However the reliance on Signatures makes is quite unsuitable for many constrained IoT devices, which might be the single use case most needing improved randomness. Many IoT devices do not have a private signature key and adding code for signatures may take up significant storage (which may be limited). Would it be possible for the draft to also suggest a scheme with symmetric crypto commonly implemented in such devices (like e.g. SHA-256) using a symmetric key K. E.g. something like

G'(n) = Expand(Extract(HMAC(K, tag1), G(L)), tag2, n)

(I have not read [SecAnalysis]...)

-- "crucial ingredient for TLS and related security protocols"
I think it is crucial for many security protocol that are not related to TLS. Suggestion

OLD "crucial ingredient for TLS and related security protocols"
NEW "crucial ingredient for many security protocols, e.g. TLS"

-- "Implementations SHOULD apply this technique when indirect access to a private key is available and CSPRNG randomness guarantees are dubious, or to provide stronger guarantees about possible future issues with the randomness."

What if direct access is available? And what if indirect access is not available, shouldn't the recommendation then be to generate a key for this. I would suggest removing that part about access:

NEW "Implementations SHOULD apply this technique when CSPRNG randomness guarantees are dubious, or to provide stronger guarantees about possible future issues with the randomness."

--    "3.  If the CSPRNG is broken or controlled by adversary Adv, the
       output of the proposed construction remains indistinguishable
       from random provided the private key remains unknown to Adv."

This assumes that the adversary do not control other parts of the system like the generation of tag2. I don't know how probable a scenario is where the adversary controls CSPRNG but not tag2. While the construction helps in cases like [DualEC], the current text may give a wrong impression of the security when the attacker control essential part of the system like CSPRNG. I would suggest removing "or controlled" and only focus on the cases where the CSPRNG is broken or weak.

-- The abbreviation "Adv" feels a bit unnecessary. I would suggest removing the first two "Adv" and changing the third "Adv" to "the adversary"

-- "Let H be a cryptographic hash function that produces output of length M. "
    M is never used. Maybe just "Let H be a cryptographic hash function"

-- "dynamically changing" is not well-defined. I would for example say that a pendulum or y = sin(x) is dynamically changing.

-- "tag2 be a dynamically changing string (e.g., a counter) of L' bytes.  We require that L >=  n - L'."

   Note that L >=  n - L' implies that n <=  L + L'

   That is a quite big limitation of the augmented CSPRNG G' that should be stated clearer. HKDF-SHA-256 and a 64-bit encoding of tag2 gives n <= 40

   Also, that n depends on the encoding of tag2 seems strange to me.  Encoding tag2 as 0x0001, 0x00000001, or 0x0000000000000001 gives different maximum values for n. 

  I think you might want to do

          G'(n) = Expand(Extract(H(Sig(sk, tag1)), G(n)), tag2, n)

   or not put a limit on n at all (L is already greater or equal to 32 if current security levels are followed)

-- "Thus, the security of this construction depends upon the secrecy of H(Sig(sk, tag1)) and G(L)."
    I don't think any of the 3 stated security properties depends upon G(L)

--  "If the signature is leaked, then security of G'(n) reduces to the scenario wherein randomness is expanded directly from G(L)."

This should maybe be added as a forth security property.

--  "Generally speaking, the following security theorem has been proven: if the adversary learns only one of the signature or the usual randomness
      generated on one particular instance, then under the security
      assumptions on our primitives, the wrapper construction should output
      randomness that is indistinguishable from a random string."

The above sentence "proven:   ..... should ...." seems strange. Why is there a "should"?

-- "Under these conditions, applying this construction should never yield
     worse security guarantees than not applying it assuming that applying
     the PRF does not reduce entropy."

    Isn't this only true if n < = L. Not applying the construction would optimally give n bits entropy and using the construction gives entropy L (if the adversary learns the signature or the randomness).

 -- [SP80090A] was updated to rev. 1 in 2015

 -- There are two references [X9.62], [X9.62] to ANSI X.62. [X9.62] is not used.

 -- X.62 is withdrawn. I suggest referring to FIPS 186-5(Draft) instead


-----Original Message-----
From: Cfrg <> on behalf of "" <>
Reply to: "" <>
Date: Sunday, 3 November 2019 at 07:41
To: "" <>
Cc: "" <>
Subject: [Cfrg] I-D Action: draft-irtf-cfrg-randomness-improvements-08.txt

    A New Internet-Draft is available from the on-line Internet-Drafts directories.
    This draft is a work item of the Crypto Forum RG of the IRTF.
            Title           : Randomness Improvements for Security Protocols
            Authors         : Cas Cremers
                              Luke Garratt
                              Stanislav Smyshlyaev
                              Nick Sullivan
                              Christopher A. Wood
    	Filename        : draft-irtf-cfrg-randomness-improvements-08.txt
    	Pages           : 10
    	Date            : 2019-11-02
       Randomness is a crucial ingredient for TLS and related security
       protocols.  Weak or predictable "cryptographically-strong"
       pseudorandom number generators (CSPRNGs) can be abused or exploited
       for malicious purposes.  The Dual EC random number backdoor and
       Debian bugs are relevant examples of this problem.  An initial
       entropy source that seeds a CSPRNG might be weak or broken as well,
       which can also lead to critical and systemic security problems.  This
       document describes a way for security protocol participants to
       augment their CSPRNGs using long-term private keys.  This improves
       randomness from broken or otherwise subverted CSPRNGs.
    The IETF datatracker status page for this draft is:
    There are also htmlized versions available at:
    A diff from the previous version is available at:
    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at
    Internet-Drafts are also available by anonymous FTP at:
    Cfrg mailing list