On 10/03/2011 01:37 PM, Jon Callas wrote:
At the risk of feeding the conspiracy angle, I note that there is
only one stream cipher for SSL/TLS (RC4). All the others in common
use are CBC modes, with that same predictable IV weakness as IPsec
(i.e. BEAST). There are no DHE cipher suites defined for RC4. So
if you want PFS, you have to accept predictable IVs. If you want
resistance to BEAST, you have to give up PFS.
Personally, I don't interpret this as anything more than the IETF
process and some vendor biases back in the 90s. But it shows that
designing for this concept of 'agility' is important, in
particular for reasons you don't know at the time.
Oh, please.
I'm sorry, Marsh, but this is just silly, suggesting that there are
vendor biases against stream ciphers and agility.
Hmmm, I wasn't trying to say that exactly. Mainly I thought it was a
little ironic. Let me try to clarify.
I think there were, and still are, "biases" among vendors like everyone
else. This is Situation Normal, to suggest otherwise is to say that
every party acts perfectly rational and with complete information.
Understanding how we make decisions when faced with imperfect logic or
information is critical to making our own best decisions and
interpreting those of others. The technique of "putting one's self in
another's shoes" is particularly helpful.
After all, if we look through the library of publicly-available,
well-trusted stream ciphers there is, ummmm, well, there's always,
urrrrr, well.
Right.
The document best describing SSLv3 is:
http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt
It has a date of November 18, 1996 on it, this was probably the date on
which the draft was uploaded to the IETF. This draft was allowed to expire.
RC4 http://en.wikipedia.org/wiki/RC4 is the only stream cipher defined.
As you point out, there weren't exactly a lot to choose from. RC4 had
been a poorly kept trade secret of RSA until September 1994 when someone
posted some source code for an equivalent implementation on the net. For
some reason, RSA seems to have refused to acknowledge its child in the
algorithm itself, yet they claim ownership of the name RC4.
The authors of the draft302 document undoubtedly found the situation
difficult. Evidence of their struggle surfaces in the body, where
citations are made "DES[DES], RC4[RC4], etc.", yet there is no actual
entry for [RC4] in the References section. The Glossary puts it thusly:
RC2, RC4 Proprietary bulk ciphers from RSA Data Security, Inc. (There
is no good reference to these as they are unpublished works; however,
see [RSADSI]). RC2 is block cipher and RC4 is a stream cipher.
Later specs would not fare much better.
http://tools.ietf.org/html/rfc2246 TLS 1.0 January 1999
RC4
A stream cipher licensed by RSA Data Security [RSADSI]. A
compatible cipher is described in [RC4].
...
[RC4] Thayer, R. and K. Kaukonen, A Stream Cipher Encryption
Algorithm, Work in Progress.
http://tools.ietf.org/html/rfc4346 TLS 1.1 April 2006 and
http://tools.ietf.org/html/rfc5246 TLS 1.2 August 2008:
RC4
A stream cipher invented by Ron Rivest. A compatible cipher is
described in [SCH].
...
[SCH] B. Schneier. "Applied Cryptography: Protocols, Algorithms,
and Source Code in C, 2nd ed.", Published by John Wiley &
Sons, Inc. 1996.
The IETF really likes to have the RFCs describe things well enough that
they can actually be implemented and interoperable. They also really
like to have intellectual property disclosures along with the things
they standardize too.
Putting myself in those spec authors' shoes, I think they were probably
wishing the RC4 problem would just go away somehow. But it couldn't for
two good reasons:
* RC4 was (and still is) preferred by many sites for performance
reasons. DES was specifically designed for a hardware implementation.
* RC4 was the only defined stream cipher. In fact, the RC4-based cipher
suites were the only non 64 bit block size CBC cipher modes at all!
Dropping RC4 would effectively amount to dropping a significant bit of
the standard's functionality.
From 1999 onward, defining a new cipher suite for using Diffie-Hellman
key exchange would have been straightforward matter of writing it up and
allocating the code point. But it would have been a largely pointless
exercise unless Microsoft or Mozilla implemented it. Or worse, possibly
the author would have been accused of contributing to the "unnecessary
proliferation of ciphersuites" [RFC 3268]
What would have been the demand for it? Security-minded endpoints
wanting PFS would prefer triple-DES or, later, AES. Performance-minded
sites wouldn't have touched EDH with a ten foot pole. Or so the thinking
probably went.
Take a look at the RFC 3268, the one which allocates the code points for
AES based ciphersites.
http://tools.ietf.org/html/rfc3268 June 2002
Overview
At present, the symmetric ciphers supported by TLS are RC2, RC4,
IDEA, DES, and triple DES. The protocol would be enhanced by the
addition of AES [AES] ciphersuites, for the following reasons:
1. RC2, RC4, and IDEA are all subject to intellectual property
claims. RSA Security Inc. has trademark rights in the names RC2
and RC4, and claims that the RC4 algorithm itself is a trade
secret. Ascom Systec Ltd. owns a patent on the IDEA algorithm.
Reason numero uno. The other reasons given are interesting too. None of
them really seem too concerned with the prospect of RC4 being less
secure than AES.
So yeah, in summary, I'd say there was some "vendor bias" in the process
going on. Not against stream ciphers in general, but against RC4 and its
uncooperative vendor in particular.
On 10/03/2011 01:37 PM, Jon Callas wrote:
Oh, I know! Counter mode! Yeah, that's it.
Yeah that would have come in handy about now.
http://www.dial911anddie.com/dtls/tlsctr.html
As I understand it, people weren't comfortable with using DES or 3DES in
a way that looked so much like a related-plaintext attack. Or maybe they
simply didn't see much of a need to improve upon CBC:
http://www.ietf.org/mail-archive/web/tls/current/msg00337.html
On the agility front, most people seem to be against it. Weren't we
in a huge no-choices-are-the-only-security mood a few weeks ago?
In SSL/TLS the thing you really can't have agility on is the HMAC that
authenticates the handshake messages negotiating all the other
specifics. If there's a choice of algorithm there, the attacker gets to
choose the weakest one to attack. In TLS 1.2 this was changed from a
combination of MD5 and SHA-1 to SHA-256.
But there have been multiple generations of ciphers to have come in and
fallen out of favor over the lifespan of SSL/TLS. Cipher suite agility
is one reason the protocol survives today.
Stream ciphers are hard. They're hard to build correctly, hard to
use correctly, and have been the red-headed-stepchild of cipher
design for really good reasons.
They're not as amenable to cryptanalysis with the standard
linear/differential framework developed for DES.
Time and power are objectively measurable (in $) whereas security beyond
the minimum needed to resist standard attacks is largely subjective. So
in practice the designer is going to have a harder time arguing for any
additional computational expense made for the sake of security.
Remember WEP? The most damning
problem in it to my mind was the order-2^24 attack caused by using a
stream cipher (and a 24-bit pseudo-IV).
Well the problem was the specific stream cipher RC4 and the way it was
used, not stream ciphers in general. The problem with WEP was so bad it
allowed for key recovery, not just a many-megabyte distinguisher.
Unlike, say, the way that block ciphers in general require additional
complexity (and things to go wrong) in the form of CBC mode :-)
TLS does a really good job of deriving pseudorandom keys for every new
connection. Even resumed sessions get new cipher and MAC keys in each
direction. My understanding is that this makes it not vulnerable to the
same issues as WEP, even though it does use the initial bytes out of RC4
instead of discarding them per modern recommendations.
Any stream cipher that gets created has to answer this really good
question: Why are you better than AES-CTR?
I know some secure websites that would love to be able to choose AES-CTR
right now. Why can't they?
Probably some of the same reasons there's only one stream cipher to
choose from.
The next question would
be why it's better than Serpent-CTR, or Twofish-CTR, or heck why not
use Threefish-CTR?
Just some example answers for RC4, I'm not sure how well they generalize
to stream ciphers:
RC4 may be faster for you.
RC4 maintains an internal state size of around 1600 bits using 272 bytes
of storage. That's a lot for a symmetric cipher! Those who are concerned
with the collision properties of small block ciphers may consider that
an advantage.
The general algorithm is even well-defined as large as you'd like to
make it. If you were to make it larger than a memory chip, you could
define a work factor in terms of external memory transactions like
scrypt. RC4 probably comes closest to a maximizing this (random memory
lookup cost)/(other stuff that can be accelerated by ASIC) ratio.
Of course right now, the best thing to do stream-cipher-wise is to
use GCM mode, with is in TLS 1.2, but hardly deployed at all, no
doubt because of bias against wanting to use something that's
authenticated, right?
I've never heard of such a bias. Maybe it exists and I've never heard of
it, or maybe you're just pulling my leg.
After all, wouldn't the surveillance state
want us all to be vulnerable to CBC attacks like BEAST, and people
who are preventing that must be in cahoots with the NSA, right?
But of course, GCM mode is part of Suite B, and that's the NSA's
push for using an authenticated data stream. So that means that the
people who are pushing for stream ciphers are also in cahoots with
the surveillance state by pushing for authenticated modes, too!
In case anyone missed it, the sarcasm bits should have been showing
up in the UTF-8 over the last couple of paragraphs at some point or
other.
Come on. This discussion has descended past whacko, which is where
it went once the "broken by design" discussion started. Yeah,
security is hard, but it's software. We know how to do that, once we
understand the problems.
No, SSL/TLS is a protocol and implementations. Sometimes the important
parts are actually in hardware and sometimes they're in software in so
many machines nobody can break interoperability with 0.01% of them.
I don't believe we understand the problems. If we did, we wouldn't have
guys in Argentina decrypting PayPal cookies transmitted over
properly-encrypted TLS as a stage trick.
It's hard for me to imagine a first-rate engineer with an unbiased mind
knowing all the issues today sitting down with a clean sheet of paper
and coming up with CBC as a new design. Yet it continues to be regarded
as some kind of gold standard. Why? Because we love Mother AES and
Grandmother DES so much and CBC is such an improvement over ECB that
surely it's "good enough"? Because people who propose alternatives are
alternately ignored or accused of "inventing their own crypto", "vanity
crypto", or "wasting our precious cipher suite code points"?
The wrong questions have been asked for so
long in this long discussion that I think the only reasonable people
are the ones ignoring the whole thing.
Yeah. I wish those reasonable people would participate more. :-)
- Marsh
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
