Re: [dsfjdssdfsd] Should secure RNGs be a MUST?

[Dan Brown <[e-mail]>]

Hi Alyssa,

Thanks for your input.

By the way, I believe current specs from ANSI X9F1 and NIST (in SP 800-56A
...) have taken the view that keys MUST be generated with a secure RNG, and
have gone further to specify various details of the RNG such as a DRBG
(PRNG) mechanism that MUST be one of three or four mechanisms, and further
the seeds for the DRBG must adhere to various requirements. 

I do not disagree with these requirements, from a security perspective, but
I guess I was asking whether they are in scope, or priorities, of IETF.
Maybe, IETF places such a high priority on connectivity that security is
just a close second.  

Some IETF docs refer to ECDSA, often via X9.62-2005, which, as already
noted, requires secure RNGs, namely one of the ANSI X9.82 RNGs, or any
future ANSI-approved RNGs.  So, in that regard, the IETF docs would already
inherit a MUST for secure RNGs, including the DRBG mechanisms and so on.
(Other crypto algorithms, including IETF re-specified algorithms, may not
have these ANSI/NIST requirements, I have not checked yet.)

If so, then maybe this list should discuss whether these ANSI/NIST
requirements are necessary and/or sufficient for IETF, at least in the case
of ECDSA. 

Best regards,

Dan  




> -----Original Message-----
> From: dsfjdssdfsd [mailto:[e-mail]] On Behalf Of
Alyssa
> Rowan
> Sent: Tuesday, March 11, 2014 2:27 PM
> To: [e-mail]
> Subject: Re: [dsfjdssdfsd] Should secure RNGs be a MUST?
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> On 11/03/2014 17:08, Dan Brown wrote:
> 
> > So, I am not totally sure about the question of whether secure RNGs
> > should be a MUST.  I wonder what others think.
> 
> Given this list exists, I'd say yes: going forward, they MUST be. <g>
> 
> Regarding your counterargument: I think security considerations warrant
MUST.
> 
> I think secure RNGs really need to be considered a vital component to
analyse.
> They have clearly been considered a vital component to
> attack: and no wonder. Insecure RNGs introduce major unexpected problems,
> including predictable keys and key leakage, in protocols which rely on
secure
> RNGs to satisfy their security requirements. But they can be subtle, and
hard to
> verify.
> 
> We should consider how robust protocols may be if those requirements are
not
> met, and generally prefer (as a "safety net") protocols which do not fail
> catastrophically if the RNG is weak, if a practical alternative exists.
But it's
> perfectly reasonable I think to also specify at the same time that the RNG
MUST
> be strong and if it isn't, you're doing it wrong.
> 
> We know really vital problems have existed in implementations. Someone
> should figure out what any further problems may be; look for them; find
them;
> fix them; disclose them. (Not necessarily in that order.) It seems that in
many
> cases, this hasn't happened. (Maybe everyone thought it was someone else's
> problem.) It needs to.
> 
> It doesn't matter so much whose problems they are: as you correctly say,
an
> insecure implementation would not be securely interoperable even with a
secure
> one. While a bad RNG is in the wild, it could be everyone's problem: I
think we
> need to do what we can to avoid that.
> 
> - --
> /akr
> -----BEGIN PGP SIGNATURE-----
> 
> iQIcBAEBCgAGBQJTH1VzAAoJEOyEjtkWi2t6nBsP/0CqWHtgs7WBXQto5lD+pFTE
> 8Uh7Nkoc7Kiy6VBadGEb7irR4+gfLhxJboAbJO3cUfqJDuEHczkTZLhiM2PV1FFS
> zHycQv8JwGs1EM2OUEX607jQgnV+3Jy/c+LTTGZJLCSEGXnvgD+BwQ7wlOfqvQq
> 4
> kWGsAe54VhvKGCb944H+pqTSeTZbCEUpTOQBaQoNl2JUAKwXY0QVk10o5dRV1
> bJt
> xXirhmV+sNVpCkcg7ExL8GkOcxQ9RLWIVAMzaAqwqH/FHK4FmLLGNWjuwePThp
> G/
> AbngohDsei7YOecMkwkcB1+14XdgAnGxfnNMXq6eslQi9XhGrF24gEQBI8JJzJ6d
> EqwrJGCRP7PVkJdAvufwgAiiP3hUURGFHjMuNZmFb7XGLO/Yeu2xKmT6Z4CsIk6j
> W1bOP7MPJsztprFQC2qtOgzV5qbsEia0/6LiXnpQRn8Zz8LkJNjpLlgzr3xsDwLj
> pLkglDVZf3HIKzIk6DuY1dAN6zcgpCS2xMa1PDyZJAS6QNXPg1Tuq2IkMSgwPt3F
> 165pALuohuWk5AL+UQsu4KgSTmHYFUl9EX5nRNgMiaNwM0NNJF37VexFIyHzc0
> 4i
> NlTHe4pW1vo4ngeIss07fN8/cS5X4ymYpmiobbi1KBjrDkUestZpFCOR1MjdGfs9
> RyY8FgwLznkNiBYuLYLc
> =sHBQ
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> dsfjdssdfsd mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dsfjdssdfsd