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

[Alyssa Rowan <[e-mail]>]

-----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+BwQ7wlOfqvQq4
kWGsAe54VhvKGCb944H+pqTSeTZbCEUpTOQBaQoNl2JUAKwXY0QVk10o5dRV1bJt
xXirhmV+sNVpCkcg7ExL8GkOcxQ9RLWIVAMzaAqwqH/FHK4FmLLGNWjuwePThpG/
AbngohDsei7YOecMkwkcB1+14XdgAnGxfnNMXq6eslQi9XhGrF24gEQBI8JJzJ6d
EqwrJGCRP7PVkJdAvufwgAiiP3hUURGFHjMuNZmFb7XGLO/Yeu2xKmT6Z4CsIk6j
W1bOP7MPJsztprFQC2qtOgzV5qbsEia0/6LiXnpQRn8Zz8LkJNjpLlgzr3xsDwLj
pLkglDVZf3HIKzIk6DuY1dAN6zcgpCS2xMa1PDyZJAS6QNXPg1Tuq2IkMSgwPt3F
165pALuohuWk5AL+UQsu4KgSTmHYFUl9EX5nRNgMiaNwM0NNJF37VexFIyHzc04i
NlTHe4pW1vo4ngeIss07fN8/cS5X4ymYpmiobbi1KBjrDkUestZpFCOR1MjdGfs9
RyY8FgwLznkNiBYuLYLc
=sHBQ
-----END PGP SIGNATURE-----