[Cryptography] Crypto best practices

[Peter Gutmann]

Hanno Böck <hanno at hboeck.de> writes:

>I'm not sure I fully understand your remark about RC4. I guess it's something
>that RC4 is a stream cipher and GCM is based on counter mode and thus also
>"like a stream cipher". One can argue that this is a more fragile thing than
>some other constructions. But the main problem with RC4 was that the
>keystream is biased. I'm not aware of any similar issue with GCM.

It's not "like a stream cipher", it's a KSG like RC4 is.  And the main problem
with RC4 isn't the biases, it's that it's so easy to get wrong that in most
uses outside of mainstream crypto protocols (SSL and SSH), the standard
approach on seeing RC4 used was to look for two lots of ciphertext so you
could XOR them together and cancel out the keystream.  I loved RC4 back when
everyone had it as their favourite go-to cipher, it was easy to use and
equally easy to bypass.

The situation was sufficiently dire that Microsoft was recommending against
its use more than a decade ago ("your application’s use of RC4 should be
reviewed by a cryptographer. This last point is very important—there are
numerous subtle errors that can arise when using stream ciphers such as RC4.
Best Practices: The RC4 stream cipher should be used with extreme caution, and
any use of the algorithm should be reviewed by a cryptographer").  That's for
legacy code, for new code the rules for which stream cipher to use was
"None—use a block cipher".

The fact that if you used the example CryptoAPI code for RC4, or probably any
code anywhere (Google rc4 encryption code example), you were going to get it
wrong, probably helped in this rule-making.  No need to perform actual
cryptanalysis, just XOR any two ciphertexts.

AES-CTR, and by extension AES-GCM, have exactly the same problem, if you use
them in their most straightforward modes where you memcpy() in a fixed or all-
zero IV, you've got RC4 again.

Peter.