<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><span style="background-color: rgba(255, 255, 255, 0);">On </span><span style="background-color: rgba(255, 255, 255, 0); -webkit-text-size-adjust: auto;">Mon, 3 Feb 2014 11:24 </span><span style="-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);">John Kelsey <<a href="mailto:crypto.jmk@gmail.com" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="39">crypto.jmk@gmail.com</a>> wrote:<br></span><blockquote type="cite"><font color="#000000"><span style="-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);"><br></span></font></blockquote><blockquote type="cite"><span style="background-color: rgba(255, 255, 255, 0);">What attack do you think is made practical by having only a 160-bit PRNG state, instead of a 256-bit state? </span></blockquote><span style="-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);"><div><span style="-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);"><br></span></div>NSA requires 256-bit AES keys for top secret. Assuming they have some good reason, a user who believes their data deserves the same level of protection and naively generates such a key using the 160-bit state RNG will not get the security they expect. </span><div><br></div><div><blockquote type="cite"><span style="background-color: rgba(255, 255, 255, 0);">Any validation process you come up with is going to have the same feature: once you've gotten something validated, changing it is, in general, going to mess up your validation. Otherwise the validation means nothing, because you could get a crypto device validated using RSA2048 and SHA256, and then change it over to using RSA512 and MD5. </span></blockquote><br></div><div>There is a long history of crypto primitives becoming obsolete as technology and crypto analysis progresses. So new primitives are developed from time to time and old ones depreciated. Ideally the depreciated primitives should be replaced well before there is any exploitable weakness. The validation process should not be an obstacle to such deployment. Perhaps there should be an expedited validation for recommended upgrades or maybe validations should have a limited life time to force periodic review. </div><div><br></div><div>In this case it seems that Apple picked wisely back in 1999 when it selected Yarrow and got a solution that still offers good security after 15 years, but I think their users would be better served if they made a simple upgrade. Yes, I know they have tons of cash, but there is always competition for budget. I wouldn't doubt their technical people have suggested such a change and some manager vetoed it on the grounds they are still FIPS-140 certified. That's a problem. </div><div><br></div><div>Arnold Reinhold</div></body></html>