Subject: [ietf-tls] Other AES key lengths

From: Pete Chown <[email-masked]>
Date: Mon, 27 Nov 2000 17:50:00 +0000

Okay, it would be useful to have as many views as possible on this key
length issue.  This should hopefully help us arrive at a consensus.
If you want AES-192 and/or AES-256, please could you also let us know
which, and how you would like to see interoperability dealt with.

Hironobu SUZUKI wrote:

> Cryptanalysis is not same as brute force attack. Cryptanalysis have
> been coming, differencal, liner, truncated-diff, boomerang,
> impossible-diff, slide, etc.etc.etc. In fact, DES was broke in 7 days
> with 20 workstations by Shimoyama's developed liner-diff attack in
> 1998. He didn't need EFF DES cracker and distribute.net.

On the other hand, even now the DES ciphersuites in TLS would normally
deliver their design strength.  None of the attacks on DES would work
against TLS unless it was used in a rather artificial way.  Hopefully
the AES has drawn on the lessons of DES and provides better security.

Would you feel happy using AES-256 if AES-128 had been broken in a
significant way?  I wouldn't.  I think if there was an attack on
AES-128 that was significant enough to work in a real world situation
it would call the *whole* cipher into question.

Shiho MORIAI wrote:

> The TLS protocol is (and will be extensively) also used on low-end
> terminals such as mobile phones or hand-held terminals. Thinking of
> computing power provided by such terminals, we should have the
> ciphersuites for AES-128.

Fair enough.

> Do many ciphersuites make implementation complicated?
> (I don't think so. I like a wide range of choices!)

Hmm.  TLS is already complicated enough.  Even if you don't mind the
extra effort, there is much more scope for bugs if you add extra
ciphersuites.

Dr S N Henson wrote:

> Since AES is also a variable block length cipher should we explicitly
> state the block length? I assume its 128 bits...

It is stated in the ciphersuite definitions -- do you feel it should
be stated somewhere else as well?

Finally, please could everyone have a think whether there is anything
else that needs to be changed with the draft.  That way I can make all
the changes at once and we can hopefully get everything finished off.

Of course, *I* am happy with everything in the draft, because I wrote
it!  But it is more important to get this right than to get it
approved quickly -- the draft is already vastly improved on my
original effort -- so please keep the suggestions coming.

-- 
Pete

---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: Dr S N Henson <[email-masked]>
Date: Mon, 27 Nov 2000 18:18:54 +0000

> be stated somewhere else as well?

Is it? I can see several references to the key length being 128 bits but
no reference to the block length being 128 bits, or have I missed
something obvious?

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [email-masked] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [email-masked] PGP key: via homepage.

---

---

From: "Andreas Sterbenz" <[email-masked]>
Date: Mon, 27 Nov 2000 20:12:21 +0100

> which, and how you would like to see interoperability dealt with.

Obviously a 128 bit key for AES will be strong enough for the next decades,
except if:

(a) AES has a fundumental security flaw. Even if AES with 192 and 256 would
remain secure in that case, people would soon stop using AES altogether.

(b) quantum cryptography or another major cryptographic breakthrough
happens. In that case TLS would most likely have to be reworked, in
particular the MAC algorithms replaced and all root certificates deployed in
software exchanged.

Hence I am not be in favor of adding another 6 or 12 ciphersuites to TLS.

 Andreas Sterbenz              mailto:[email-masked]

---

---

From: Pete Chown <[email-masked]>
Date: Tue, 28 Nov 2000 11:22:04 +0000

> no reference to the block length being 128 bits, or have I missed

Oh!  Sorry, I was so sure you ought to be talking about key length
that I didn't read your message properly.  :-)

I'll add a clarification about this at the same time as I make
whatever changes are agreed about key lengths.  (For me, AES would
imply 128-bit blocks, since that was the requirement of the AES
process.  However I agree that this should be spelled out.)

-- 
Pete

---

---

From: Pete Chown <[email-masked]>
Date: Tue, 28 Nov 2000 11:23:07 +0000

> Hence I am not be in favor of adding another 6 or 12 ciphersuites to TLS.

Thanks.  The views of people who agree with me are always the most
welcome! :-)

-- 
Pete

---

---

From: Rodney Thayer <[email-masked]>
Date: Tue, 28 Nov 2000 11:13:23 -0800

Sorry, stepping into this thread late.

It seems to me you are saying "AES will not be broken therefore
don't add other ciphersuites".  Is that what you meant?  I've
been advocating, for a while now, that we need multiple ciphersuites
in these protocols.  Crypto, unlike protocol design, is "not known not
to work".  We cannot assume AES won't be broken tomorrow.  That
would be Architecturally Irresponsible(TM).  Of course we don't
expect this, but we should not be designing for this assumption.

Of course, the current state of affairs, plus or minus AES, is that
we have several ciphersuites anyway.

At 08:12 PM 11/27/00 +0100, Andreas Sterbenz wrote:
>You are currently subscribed to ietf-tls as: [email-masked]
>To unsubscribe send a blank email to 
>[email-masked]

---

---

From: Hironobu SUZUKI <[email-masked]>
Date: Wed, 29 Nov 2000 11:30:31 +0900

Pete Chown <[email-masked]>:
>
> Okay, it would be useful to have as many views as possible on this
> key length issue.  This should hopefully help us arrive at a
> consensus.  If you want AES-192 and/or AES-256, please could you
> also let us know which, and how you would like to see
> interoperability dealt with .

I don't familiar with this TLS ML discussion. Anyway, I'd like to make
a list of ciphersuites for AES 128/192/256 as below.

TLS_RSA_WITH_AES_128_CBC_SHA          = { 0x00,0x2F }
TLS_DH_DSS_WITH_AES_128_CBC_SHA       = { 0x00,0x30 }
TLS_DH_RSA_WITH_AES_128_CBC_SHA       = { 0x00,0x31 }
TLS_DHE_DSS_WITH_AES_128_CBC_SHA      = { 0x00,0x32 }
TLS_DHE_RSA_WITH_AES_128_CBC_SHA      = { 0x00,0x33 }
TLS_DH_anon_WITH_AES_128_CBC_SHA      = { 0x00,0x34 }

TLS_RSA_WITH_AES_192_CBC_SHA          = { 0x00,0x35 }
TLS_DH_DSS_WITH_AES_192_CBC_SHA       = { 0x00,0x36 }
TLS_DH_RSA_WITH_AES_192_CBC_SHA       = { 0x00,0x37 }
TLS_DHE_DSS_WITH_AES_192_CBC_SHA      = { 0x00,0x38 }
TLS_DHE_RSA_WITH_AES_192_CBC_SHA      = { 0x00,0x39 }
TLS_DH_anon_WITH_AES_192_CBC_SHA      = { 0x00,0x3A }

TLS_RSA_WITH_AES_256_CBC_SHA          = { 0x00,0x3B }
TLS_DH_DSS_WITH_AES_256_CBC_SHA       = { 0x00,0x3C }
TLS_DH_RSA_WITH_AES_256_CBC_SHA       = { 0x00,0x3D }
TLS_DHE_DSS_WITH_AES_256_CBC_SHA      = { 0x00,0x3E }
TLS_DHE_RSA_WITH_AES_256_CBC_SHA      = { 0x00,0x3F }
TLS_DH_anon_WITH_AES_256_CBC_SHA      = { 0x00,0x40 }

> On the other hand, even now the DES ciphersuites in TLS would
> normally deliver their design strength.  None of the attacks on DES
> would work against TLS unless it was used in a rather artificial
> way.  

Your expression sounds unsuitable for secuirty.  I never heard that
TLS's ciphersuites which involved with DES_40 or RC4_40 was broken.
So far, I can say that "None of the attacks on DES_40 and RC4_40 would
work against TLS".  But it might be wrong. Is there someone who
believes it is safe?  Nobody knows tomorrow.  And I want to use better
one.

> extra effort, there is much more scope for bugs if you add extra

Basically Yes. But the difference in AES_128/192/256 is only key
length. Basically, AES_128/192/256 is used same codes in software
implementation, no additional costs.  We can get big advantage with
tiny costs.

-- 
Hironobu SUZUKI        Independent Software Consultant
E-Mail: [email-masked]
URL: http://h2np.net

---

---

From: "Andreas Sterbenz" <[email-masked]>
Date: Wed, 29 Nov 2000 13:46:51 +0100

> don't add other ciphersuites".  Is that what you meant?  I've

No, what I am saying is that AES with 256 bit keys is not a good backup for
AES with 128 bit keys.

---