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:[email protected]] On Behalf Of Alyssa > Rowan > Sent: Tuesday, March 11, 2014 2:27 PM > To: [email protected] > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/dsfjdssdfsd
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dsfjdssdfsd mailing list [email protected] https://www.ietf.org/mailman/listinfo/dsfjdssdfsd
