Subject: [ietf-tls] New AES ciphersuites draft

From: Pete Chown <[email-masked]>
Date: Wed, 15 Nov 2000 16:35:06 +0000

I have made a new version of the AES ciphersuite draft available.  It
can currently be downloaded from:

ftp://ftp.skygate.co.uk/pub/tls-aes-drafts/draft-ietf-tls-ciphersuite-02.txt

In addition, the version on the IETF website should be updated soon.

Please let me know any comments which you have.  The major changes
with this update are:

1.  A ADH ciphersuite is now included (which is not deprecated), with
    an appropriate security warning at the end of the document.

2.  The document now indicates what an implementation must do in order
    to be interoperable.  Of course, any two TLS implementations
    should be interoperable, regardless of whether they implement AES.
    However, I want to ensure that two TLS implementations supporting
    AES can always negotiate an AES ciphersuite.

-- 
Pete

---
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: Thu, 23 Nov 2000 17:29:34 +0900

I'm a newcomer in TLS mailing list.

I have a question about key length of symmetric cipher in proposals of
TLS cipher suites.

Pete Chown recommended AES with 128 bits key length in his new AES
ciphersuites draft.  Hidenori Ohta recommended Camellia 128,192,256
bits key length in his lists.

I don't understand why they recommend 128 (or 192) bits key length.

I know that Rijndael and Camellia have different rounds between
128. 192, 256 bits key length. But it's a small different for
performance.  From my point of view, there is no reason and no value
to prepare 128,192,256 bits key length specification at same time.  

Shall we select only 256 bits key length which is most trusted one?

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

---

---

From: Pete Chown <[email-masked]>
Date: Thu, 23 Nov 2000 11:59:01 +0000

> I don't understand why they recommend 128 (or 192) bits key length.

Originally I proposed 256 bits, but there is really nothing to be
gained that I can see.  If AES-128 was broken it would be such a
massive advance in either hardware or cryptanalysis that we would have
to rethink everything anyway.

I wonder, actually, if AES-256 is meant to guard against a large
advance in quantum computing.  To provide security in this environment
I believe you would need to double the key lengths of symmetric
ciphers.  However, at the same time, current public key cryptosystems
would become unusably weak.  TLS would therefore be useless...
Presumably we would have to start using something more like Kerberos!

The other point is that the public key cryptosystems would have to
have ridiculously long keys to give the same resistance to attack that
AES-256 would have.  It is obvious that there is no benefit to
fielding a PKI system where some elements are much stronger than
others -- an attacker will always go for the weak link.

> performance.

It is a small difference, but IMHO it should be the deciding factor,
because there is no reason to use a longer key.

Incidentally there is also a theoretical issue with using longer keys,
in that more entropy is consumed from the master secret.  It is
therefore theoretically possible that AES-256 could be less secure
than AES-128.

(I don't see this as a very important issue, but I thought I would
explain the reasons underlying it.)

-- 
Pete

---

---

From: Hironobu SUZUKI <[email-masked]>
Date: Fri, 24 Nov 2000 11:41:04 +0900

> From: Pete Chown <[email-masked]>
> Subject: [ietf-tls] Re: New AES ciphersuites draft
>

I'm sorry that I didn't read your original proposal.

New cryptanalysis technique has appeared in every year. For example,
Skipjack seems un-secure cipher today because Biham and Shamir
developed new cryptanalysis. It took few year after Skipjack was
opened.

I know that Rijndael-128 is enough today. But after next 5 year,
nobody knows new effective cryptanalysis will be appeared.  In AES 3rd
conference at NY, some people mentioned that Rijndael had few security
margin and some people recommened to add 3 or more rounds. 

If new effective cryptoanalysis is appeared then we should add
AES-192, AES-256 into new cipher-suites of TLS.

Why not AES-256 first?

> However, at the same time, current public key cryptosystems

100% agree with you if QC is appeared.  First of all, an arithmetical
public key system will be broken.  Then we can add Okamoto's QC public
key system into TLS. It seems good than an arithmetical public key
system :-)

> because there is no reason to use a longer key.

AES-256 has more security margin than AES-128.

> therefore theoretically possible that AES-256 could be less secure

I agree with you there is "POSSIBILITY" of master secret entropy
problem. But also there is possible that total security of TLS is
depended on entropy of master secret, isn't depended on key lentgh of
symmetric cipher. Anyway, there is no proof.

---

---

From: "Hidenori Ohta" <[email-masked]>
Date: Fri, 24 Nov 2000 19:49:57 +0900

Hironobu-san,

> bits key length in his lists.

I just picked up the ciphersuites from the current Internet-Drafts and
numbered them. ;-)

On Fri, 06 Oct 2000 15:31:15 JST, Shiho MORIAI wrote:

> * The number of ciphersuites
> 
> Since Camellia supports three key sizes, 128, 192, and 256 bits,
> similarly to the AES, I simply defined ciphersuites for Camellia with
> each key size.  So there are 18 ciphersuites in total.  However, I
> will define only necessary ciphersuites following the AES
> ciphersuites.  I also remove a DH-anon ciphersuite, since I just
> followed the 3DES ciphersuites in RFC2246.

I missed these sentences. Moriai-san will drop 192 and 256 bits
when she will update the draft.

So, here is a new list.

TLS_RSA_WITH_SEED_CBC_MD5             = { 0x00,0x2C }
TLS_RSA_WITH_SEED_CBC_SHA             = { 0x00,0x2D }
TLS_RSA_WITH_SEED_CBC_HAS160          = { 0x00,0x2E }

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_MISTY1_CBC_SHA           = { 0x00,0x35 }
TLS_DH_DSS_WITH_MISTY1_CBC_SHA        = { 0x00,0x36 }
TLS_DH_RSA_WITH_MISTY1_CBC_SHA        = { 0x00,0x37 }
TLS_DHE_DSS_WITH_MISTY1_CBC_SHA       = { 0x00,0x38 }
TLS_DHE_RSA_WITH_MISTY1_CBC_SHA       = { 0x00,0x39 }

TLS_RSA_WITH_CAMELLIA_CBC_128_SHA     = { 0x00,0x3A }
TLS_DH_DSS_WITH_CAMELLIA_CBC_128_SHA  = { 0x00,0x3B }
TLS_DH_RSA_WITH_CAMELLIA_CBC_128_SHA  = { 0x00,0x3C }
TLS_DHE_DSS_WITH_CAMELLIA_CBC_128_SHA = { 0x00,0x3D }
TLS_DHE_RSA_WITH_CAMELLIA_CBC_128_SHA = { 0x00,0x3E }

TLS_KRB5_WITH_NULL_SHA                = { 0x00,0x3F }
TLS_KRB5_WITH_NULL_MD5                = { 0x00,0x40 }

> Shall we select only 256 bits key length which is most trusted one?

If we will select new public-key cyrptosystem which has the same
strength as the strength of 256-bits secret-key cryptosystem,
we should say yes.

Regards.
--
Hidenori Ohta

---

---

From: Pete Chown <[email-masked]>
Date: Fri, 24 Nov 2000 11:13:53 +0000

> developed new cryptanalysis. It took few year after Skipjack was

We are talking about different things here though.  Skipjack's
weakness doesn't really result from its short keys.

Skipjack was declassified in June 1998 and serious weaknesses were
discovered within only a few months.  None of the AES finalists had
anything like this level of vulnerability.

> margin and some people recommened to add 3 or more rounds.

So is your point that we should use AES-256 because it has more rounds
rather than because it has longer keys?

> 100% agree with you if QC is appeared.

But at the moment quantum computing is the only possible hope for
breaking a 128-bit key by brute force.  Distributed.net is up to 30%
of RC5-64 and is testing around around 140 billion keys per second.
The search is likely to take a couple more years.

Breaking a 128-bit key the same way and in the same time would take
about 10**19 times as much processing power.

> symmetric cipher. Anyway, there is no proof.

Which do you think is more likely?  A mathematical problem with the
entropy in the master secret or an increase in computing power by a
factor of 10**19?

-- 
Pete

---

---

From: Hironobu SUZUKI <[email-masked]>
Date: Fri, 24 Nov 2000 21:05:29 +0900

> So is your point that we should use AES-256 because it has more
> rounds rather than because it has longer keys?

Bacialy YES. And also more key space.

> about 10**19 times as much processing power.

I agree with you that 128-bit is safe in DESChall style situation,
brute force attack.

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.

What's next? I don't know.

Ross Anderson who is one of designer of SERPENT said "I recommend
SERPENT-256 for AES" in 3rd AES conference. I agree with him.
Rijndael/AES is also.  There is very small different beetween 128, 192
and 256bit key length. Why not 256?

Must I think about the master secret problem?

---

---

From: Shiho MORIAI <[email-masked]>
Date: Mon, 27 Nov 2000 00:55:06 JST

>and 256bit key length. Why not 256?

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.

However, if some people need a sense of greater security, we may add
the ciphersuites for AES-192 and AES-256, too.

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

Basically, I think 128-bit key length is enough for use of next 10-20
years (as NIST says).  However, I don't know whether AES-128 has a
high security margin for use of next 10-20 years. IMHO, if a certain
problem should be found in AES-128, AES-128 with more rounds would be
used, instead of AES-192 or AES-256. (Then, more rounds would be added
to AES-192 and AES-256, too.)

Shiho Moriai

---

---

From: Hironobu SUZUKI <[email-masked]>
Date: Mon, 27 Nov 2000 09:44:29 +0900

> the ciphersuites for AES-192 and AES-256, too.

I will agree with you if AES-192, AES-256 is added to TLS specs. 

I've got the "freedom of choice". DEVO! :-) And I'll use AES-256 as
default cipher-suite.

> Do many ciphersuites make implementation complicated?

Case by case.  Rijndael's round structure is very simple "rounds loop"
and is NOT required an additional code except loop branch codes in
software implementation.  Camellia is required addtional codes for
192/256( but cost is small as well as other AES finalist ).

---

---

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

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

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: Peter W <[email-masked]>
Date: Sun, 26 Nov 2000 21:03:41 -0500 (EST)

> I will agree with you if AES-192, AES-256 is added to TLS specs.

Is anyone really interested in AES-192 ? Or are AES-128 / AES-256 enough?

-Peter

---

---

From: Hironobu SUZUKI <[email-masked]>
Date: Mon, 27 Nov 2000 11:06:47 +0900

> Is anyone really interested in AES-192 ? Or are AES-128 / AES-256 enough?

Ya, you're right.

						--hironobu

---