Re: [Cfrg] draft-irtf-cfrg-randomness-improvements-00 vs currently-deployed alternatives

["Stanislav V. Smyshlyaev" <[e-mail]>]

Dear Brian!

Sorry for the delay – all this time we've been discussing the issues you
raised in an off-list discussion among the authors of the draft.

First of all, thank you very much for your questions and comments. They
highlight the issues that haven't been discussed thoroughly enough in the
current version of the draft.


About deterministic signature functions.

Actually the worst case scenario we are defending against is a complete
breakdown of all existing entropy sources (say, because of failure of
hardware RNG) on a certain computer. In this case we don't have even the
initial randomness to feed a DRBG (say, HMAC-DRBG you mentioned), and DRBG
without initialization with good randomness of course does not provide any
pseudorandom properties of outputs. But, yes, if we use (non-deterministic)
ECDSA or, say, EC-RDSA implemented in a separate hardware with a separate
entropy source (say, an HSM with its own RNGs), we can use it. The problem
occurs in another case  - when a random value used in ECDSA/EC-RDSA is
obtained from the same potentially broken entropy source.

According to your comments, we believe that recommendations should be
stated more explicitly in the draft, and comments of what would occur if
one uses a non-deterministic signature scheme (with no additional separated
trusted entropy source) with our techniques. We'll try to address this
issue in the future versions of the draft.


About different tags.

Of course it would be better to mix-in entropy, but we'd like to stress
that the main reason of using the techniques described in our draft is to
address the possible worst-case scenarios of having no working entropy
sources – when we cannot rely on any mixed-in entropy at all.
You cite the following place of the draft: "one HSM with a private key is
used from several servers, or if virtual machines are cloned". In fact the
problem we're trying to address here is the following. If we do not have
any actual entropy, then, in case of using our techniques, we'll leverage
the security of such worst-case scenarios – but – if we also have two
equivalent environments (two cloned virtual machines, for example) and two
tags are equivalent, then we can do nothing at all: no entropy and no
differences between two environments would lead to completely equivalent
outputs.
It seems that we really need to add some explanations about it in the text,
since such questions remain after reading the current version.


Thank you again for your comments, Brian.

We'll try our best to address these issues in the future versions of the
document.


Best regards,
Stanislav



2018-06-03 7:00 GMT+03:00 Brian Smith <[e-mail]>:

> Hi,
>
> Hi all,
>
> Here are the initial questions that came into my haed after my first
> skim of draft-irtf-cfrg-randomness-improvements-00 [0]. I'm probably
> stating the obvious, but I just thought I'd double-check.
>
> The document says "Sig MUST be a deterministic signature function,
> e.g., deterministic ECDSA [RFC6979]."
>
> Let's say you did use Determistic ECDSA as described in RFC 6979. Then
> really you've basically implemented a special case of NIST HMAC-DRBG,
> perhaps by literally using an HMAC-DRBG implementation as described in
> section 3.3 of that RFC [1]. Given that, why not just use your
> HMAC-DRBG implementation for the individual nonces too, instead of
> implementing draft-cremers-cfrg-randomness-improvements-00 on top of
> it? For example, why not use (a variant of) the scheme that Cisco
> documented at [2], which they claim is even FIPS-certifiable? It seems
> BoringSSL switched to a variant of that as well [3] during their FIPS
> certification. I think explicitly stating the advantages of
> draft-cremers-cfrg-randomness-improvements-00 over that technique
> would be very helpful for people evaluating both.
>
> More generally, it seems problematic to me to require that we seed
> this with a *deterministic* signature to start out with. I understand
> that we want to protect ourselves against the case where we have
> little to no secret entropy. However, isn't it going to be pretty
> likely that we have a pretty good amount of secret entropy available
> from the beginning? It seems bad to just ignore it when it is probably
> available. I think it would be good to reformulate the mechanism in a
> way that allowed a possibly-randomized computation to be used instead.
>
> The draft says "Both tags SHOULD be generated such that they never
> collide with another accessor or owner of the private key.  This can
> happen if, for example, one HSM with a private key is used from
> several servers, or if virtual machines are cloned." Isn't it highly
> likely that people will fail to follow this recommendation due to the
> fact that it's very easy to accidentally break this rule? In fact many
> crypto libraries have specific defenses built-in and enabled by
> default, based on the assumption that users cannot follow such
> recommendations. This seems like one reason why it would be good to
> mix in some entropy into the initial key. With that in mind, I think
> it would be good to reformulate the mechanism in a way where we feel
> comfortable removing this requirement.
>
> [0] https://tools.ietf.org/html/draft-irtf-cfrg-randomness-improvements-00
> [1] https://tools.ietf.org/html/rfc6979#section-3.3
> [2] https://blogs.cisco.com/security/fips-and-deterministic-
> ecdsa-achieving-robust-security-and-conformance
> [3] https://boringssl.googlesource.com/boringssl/+/783e0957875ac
> 62b35aa4f8741069e133695a3d4
>
> Cheers,
> Brian
> --
> https://briansmith.org/
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>