[Cryptography] Crypto best practices

[Arnold Reinhold]

On 03/16/2017 05:37 PM, Peter Gutmann wrote:
> Ray Dillinger <bear at sonic.net <mailto:bear at sonic.net>> writes:
> 
>> Stream Ciphers simply aren't worth the level of complexity risk required to
>> design with them any more, and have not been for a long time.
> 
> +1 to all of that.  It's the "RC4 all over again" thing, we have about two
> decades of experience showing that if you give J.Random coder a stream cipher
> to use for data encryption, they're probably going to get it wrong. 

The requirement for a unique IV for each encryption when employing stream ciphers is central to their security, but not as stringent as the requirements on the nonce needed for each signature using DSA or ECDSA or the need to use unique primes in generating RSA public keys. 

Detecting a duplicate IV with two stream cipher encryptions compromises just the two messages. The IVs can be predictable, as long as they are never duplicated. By contrast, a duplicate or even slightly predictable DSA signature nonce compromises the signing key itself (q.v. the Sony PS3 hack). With RSA, using the same prime in two different public keys allows them both to be broken and efficient methods have been demonstrated (by Lenstra, et al) for detecting such lapses in the universe of RSA public keys. The only cure is to use a strong random starting point when searching for primes. 

Thus most modern crypto systems require strong sources unpredictable bits and are extremely demanding of correct programming to insure their proper use. The Wikileaked CIA programming guide requires use of the crypto libraries and strong RNGs supplied with modern operating systems, in part to help maintain cover for their implants, but also to avoid programming errors. Excellent advice to J.Random coder. The big problems we face are in embedded applications, including IoT, where vetted crypto libraries are less commonly available and where strong randomness is harder to come by. It seems to me that eschewing stream ciphers, especially those with desirable properties that can prevent other JRC programming lapses, is not the best way to solve such problems.

Arnold Reinhold
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170319/7acc4cef/attachment.html>