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

"Stanislav V. Smyshlyaev" <smyshsv@gmail.com> Thu, 21 November 2019 10:42 UTC

Return-Path: <smyshsv@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F8A12085F for <cfrg@ietfa.amsl.com>; Thu, 21 Nov 2019 02:42:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMWebgQkn3Vt for <cfrg@ietfa.amsl.com>; Thu, 21 Nov 2019 02:42:53 -0800 (PST)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9C91120937 for <cfrg@irtf.org>; Thu, 21 Nov 2019 02:42:52 -0800 (PST)
Received: by mail-lf1-x12e.google.com with SMTP id a17so2179328lfi.13 for <cfrg@irtf.org>; Thu, 21 Nov 2019 02:42:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=liKLR5478Jvs9BIds8B2SIv7AivQ84p6rfL9ieQ+Yzw=; b=oI+Adup1lfPvLw49pdWE0Sx02liKv5f9XI4IAEdvqiQewLkEeX1CrF8bs0oEMk6BYG 9GU2JpTnEmvUCleM64ktz/INAw40Up0PtnVE9PfNjeUYvCxhsSXlnZdLs82UA3+8F63D k1myrjjCdUztCoVGXcjfqBGqZUigBcz/fsXWiu3TCMLeF1reqikPcokzD7dk6qUeQmqM WEGS/0X/yhxXuZI6a/yzJufRoVNPU4iPqAvh8CGEvF6PvQgjJjWK7mpKqws9EgPD9+kW 2C/JIiuk38ock0+5Jlf2oB9nLb7c111cE3Ii1wpKfoFc6wHVpmg6OyRxWElICnMkYAcR JAuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=liKLR5478Jvs9BIds8B2SIv7AivQ84p6rfL9ieQ+Yzw=; b=IPWp8oyxzLoy41P26c5+KVsCnYUVCWS1kaz5nagoiApgjSQs5lNe8xJJyFVw/HC58G EKzNYhdb8S2aytIbwT+pzKOVR89LuArkYeo3iqKU1KiE++TBYA3Z3XwpV1bRrG0YvFZT UoDGt29BkSTLr0tAEIwefxaIfR1N3mAs0cdyQeuNUH7Vj0fX9PYJGoYIjGSngZ8g8MA1 QTiDEgUKs1k6gRHLN9CoseQ3avKM/Zlk0/gvV19JeJUF2VNjGNp4vLoSrO5IrerTgoGv DG7QelCN3XzDEpZU0MMy+YZzzMtVPiHwHSsWC09i0hLHMWyroGEcWUL7R/G1NUvMoosT ylcQ==
X-Gm-Message-State: APjAAAXv4h5R9ka52j1uVagLWlK9xcCA4BT2QX/Bi5fQW2Pt8rF+QE/S orfte2O+nQypHBLGt8ArFA+Izwm5GUIl7QfJwIw=
X-Google-Smtp-Source: APXvYqwbL34ZVKTKeSOKYjoJv6xQ7/RmVwm64BRl0/rctjmn/aA74TSvNzXjmUIqDAnyp3a6oCRydTb3eUr8oQAu7KY=
X-Received: by 2002:a05:6512:486:: with SMTP id v6mr6469777lfq.72.1574332970653; Thu, 21 Nov 2019 02:42:50 -0800 (PST)
MIME-Version: 1.0
References: <157273808364.6043.6715638492611593951@ietfa.amsl.com> <77AD232C-094D-4FC1-A966-DA56EC44A27F@ericsson.com>
In-Reply-To: <77AD232C-094D-4FC1-A966-DA56EC44A27F@ericsson.com>
From: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Date: Thu, 21 Nov 2019 13:42:41 +0300
Message-ID: <CAMr0u6=7r2wAD_3Yn1hBjJW-y=8FE27jeYQW8wk3wJ-Xh2g2hg@mail.gmail.com>
To: John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="000000000000795d220597d8f545"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/0VTu8xOBLvM21Qsh6s7VFichbMo>
Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-randomness-improvements-08.txt
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Nov 2019 10:42:56 -0000

Dear John,

Many thanks for your great comments!

*-- I think this is great. *

Thank you! :)

*-- Would it be possible for the draft to also suggest a scheme with
symmetric crypto commonly implemented in such devices using a symmetric key
K. E.g. something like G'(n) = Expand(Extract(HMAC(K, tag1), G(L)), tag2,
n)*

Yes, I believe that it can be a great future direction of work, but this
will be another construction, requiring additional security analysis etc. I
think that the topic of improving randomness will be always a very
important one, so a lot of other good ideas and good constructions may
arise in the future.

*-- "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"*

I like this change – if Chris, Cas, Nick and Luke won’t object, I believe
it’s worth to be made.

*-- "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."*

I like both variants, but personally I don’t see a big problem with the
current text: if direct access is available, then indirect access is also
available.

*--    "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.*

>From the cryptographic point of view, the controlled CSPRNG is a stronger
vulnerability than “just” a backdoored one – since it assumes that an
adversary can try to affect CSPRNG outputs adaptively. 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).

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

Agreed. Thanks!

*-- "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"*

Agreed! Many thanks, John!

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

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

*-- "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)*

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’.

*-- "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)*

The first one  (“If the CSPRNG works fine…”) does. But maybe it will be
better to rephrase this as “Thus, the security of this construction depends
upon G(L) and the secrecy of H(Sig(sk, tag1)).”, so no one can read it like
“the secrecy … of G(L). What do you think?

*--  "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.*

Actually, the first one is about this: “If the CSPRNG works fine”, we are
not afraid of signature leakage.


*--  "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"?*

Yes, “the wrapper construction outputs” seems to be less confusing. Thanks!

*-- "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).*

Yes, I get your point – the phrase was about deep and nontrivial security
properties, but reducing the length of CSPRNG output can clearly trivially
make things worse. I think that adding a clarification like “(for the
corresponding length of CSPRNG output)” can help.

* -- [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*
*     https://csrc.nist.gov/publications/detail/fips/186/5/draft
<https://csrc.nist.gov/publications/detail/fips/186/5/draft>*

Thanks a million! Instead of FIPS 186-2 (Draft) a reference to RFC 6979
looks reasonable.

Many thanks again, John!

Best regards,
Stanislav