[Cryptography] RC4 again (actual security, scalability and other discussion)

Watson Ladd watsonbladd at gmail.com
Sun Mar 9 18:26:59 EDT 2014

On Sun, Mar 9, 2014 at 2:11 PM, Theodore Ts'o <tytso at mit.edu> wrote:
> On Sun, Mar 09, 2014 at 12:33:44PM +0100, Hanno Böck wrote:
>> * Matthew Green thinks salsa20 is the way to go [1]. chacha20 is the
>>   successor of salsa20 with very few changes.
> That's not really a fair summary of Matthew's blog entry.  To quote
> from his summary:
>    "I realize none of the above actually tells you which AES
>    alternative to use, and that's mostly because I don't want to
>    legitimize the question. Unless your adversary is the NSA or you
>    have some serious performance constraints that AES can't satisfy,
>    my recommendation is to stick with AES -- it's the one standard
>    cipher that nobody gets fired for using."
> He was recommending salsa20 only if you have performance requirements
> that can't be met by AES.  And given that many modern CPU chips have
> hardware support for AES, including Intel, Arm, and Power chipsets,
> presumably this mostly applies to people who need to implement
> software on legacy CPU's.
>> * Adam Langley tries to improve SSL and thinks chacha20 is the way to
>>   go [2]
> And if you read Adam's blog post carefully, he added chacha20 as a
> _fallback_ cipher.  Since it is different from RC4 and AES, that's
> useful if you want something that will hopefully survive some new
> cryptographic attack that is able to make RC4 or AES fall.  But that's
> __not__ the same as saying that it's "the way to go".

Well, here is the paper about RC4:
http://www.isg.rhul.ac.uk/tls/RC4biases.pdf. It turns out that for
plaintext which is highly compressible, using a Verbiti-style decoding
algorithm recovers quite a bit given a small number (2^20) of
identical ciphertexts. Add in the use of Javascript to make requests
automatically, and you can decrypt responses that should be

RC4 is broken in TLS. The attack looks like BEAST or Lucky13, and is
intermediate in complexity in terms of number of connections gathered.
In any setting you learn a lot about the plaintext sent. Turning it
into a "real break" is not surprising. Why take the risk?

AES-GCM is tough to do in software on things like mobile phones or
embedded devices. I can run Chacha20 in constant time efficiently on a
$1 8 pin DIP ARM-M0. AES-GCM is a bit tricky there.

Furthermore, I read AGLs blog post and never saw him describe ChaCha20
as a fallback for cryptographic reasons. He indicated that it was a
matter of performance and hardware support between AES-GCM and
Chacha20-Poly1305, and I think most cryptographers would agree with

Watson Ladd

> Cheers,
>                                                 - Ted
>> [1]
>> http://blog.cryptographyengineering.com/2012/10/so-you-want-to-use-alternative-cipher.html
>> [2] https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography

"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

More information about the cryptography mailing list