Subject: Re: New bulk encryption algorithms

From: Markku-Juhani Saarinen <[email-masked]>
Date: Tue, 3 Oct 2000 12:35:11 +0300 (EET DST)

Mats Andersson wrote:

> Since rijndael is proposed for AES wouldn't it be nice to have
> Rijndael-cbc as RECOMMENDED in the drafts?

I'd rather see "AES" than "Rijndael" in the drafts. (most of us prefer to
use the word "DES" rather than the original name "Lucifer" after all.. )

Note that the speed of AES varies according to the key size. Going from
128 bits to 256 bits slows AES down by about 40%.

For this reason I'd like to propose names for the various standard key
sizes:

  "aes128-cbc"	(663 Mbit / sec @ 1 GHz P3) 
  "aes192-cbc"	(448 Mbit / sec @ 1 GHz P3)
  "aes256-cbc"	(384 Mbit / sec @ 1 GHz P3)

The block size is 128 bits in all cases. The timings are based on the
paper "Fast Implementations of AES Candidates" by Aoki and Lipmaa
(presented in the AES 3 conference).

- mj

Markku-Juhani O. Saarinen <[email-masked]>  University of Jyväskylä, Finland

---

From: [email-masked] (Niels M�ller)
Date: 03 Oct 2000 14:01:41 +0200

> use the word "DES" rather than the original name "Lucifer" after all.. )

That depends a little on what becomes the usual way to refer to the
cipher. I don't really know, but if you think that "aes" is what
people will be calling the cipher in a year or two, it makes sense to
call it it aes rather than rijndael.

>   "aes256-cbc"	(384 Mbit / sec @ 1 GHz P3)

Sounds reasonable.

/Niels

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 03 Oct 2000 09:45:48 -0400

> I'd rather see "AES" than "Rijndael" in the drafts. 

This makes sense.  It's shorter and easier to type..

> Note that the speed of AES varies according to the key size. Going
> from 128 bits to 256 bits slows AES down by about 40%.  For this
> reason I'd like to propose names for the various standard key sizes:

>   "aes256-cbc"	(384 Mbit / sec @ 1 GHz P3)

Given how secsh parameter negotiation works, this makes sense.

					- Bill

---

From: Martin Forssen <[email-masked]>
Date: Tue, 3 Oct 2000 15:56:20 +0200 (MEST)

> call it it aes rather than rijndael.

Please keep in mind that NIST has only proposed that Rijndael should be
the new AES. The actual certification will take some time yet (maybe
years). So we can not be 100% that Rijndael will become the AES, there
is still a possibility (although very a very faint one) that some other
algorithm will be chosen as AES. Therefore I think it is a bad idea to
use "aes" when we mean "rijndael", at least at the protocol level.

Also I am not sure the analogy with Lucifer/DES holds since Lucifer was
another cipher. There is a thread on exactly this topic in sci.crypt at
the moment.

>>   "aes256-cbc"	(384 Mbit / sec @ 1 GHz P3)

Yes it does (with changing "aes" to "rijndael" of course:-)

	/MaF

---

From: [email-masked] (Niels M�ller)
Date: 03 Oct 2000 16:07:30 +0200

> use "aes" when we mean "rijndael", at least at the protocol level.

Good point. It makes sense to use "rijndael" to refer to the cipher
that was input to the AES process, and "aes" for whatever comes out at
the other end. One possible thing that might happen before the AES
process is over is NIST tweaking the number of rounds, I guess. If no
tweaking happens, "aes" and "rijndael" will turn out to be synonyms.

/Niels

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 03 Oct 2000 17:22:07 -0400

>use "aes" when we mean "rijndael", at least at the protocol level.

Disagree.  It definitely won't take years.  The decision is made
and the only thing is to publish a formal FIPS for AES.  The formal 
process for the AES FIPS document to be approved only involves:
        (1) NIST publishes draft FIPS for AES in the US Federal Register
        (2) legal comment period occurs (which is N weeks, not years)
        (3) The full FIPS gets approved

I'll be surprised if AES FIPS isn't fully completed by the end of
the Minneapolis IETF.  In any event, IANA has already allocated
an IPsec magic number for AES (and also numbers for SHA-2), 
see the URL below:
        http://www.isi.edu/in-notes/iana/assignments/ipsec-registry

Ran
[email-masked]

---

From: Martin Forssen <[email-masked]>
Date: Wed, 4 Oct 2000 08:58:56 +0200 (MEST)

> Disagree.  It definitely won't take years.  The decision is made

Ok, I stand corrected. It seems as they expect it to be final somewhere
around April-June 2001
(http://csrc.nist.gov/encryption/aes/round2/aesfact.html item #9).

>         (3) The full FIPS gets approved

I think you forgot one step here:
	(2.5) NIST makes apropriate changes to the draft
	      (See above url item #8)

So as far as I understand it there is nothing which guarantees that the
cipher we today know as Rijndael is going to meet the conformance
testing criteriaof the official AES. NIST may still make changes to the
draft.

So IMHO this leaves us two choices, either we define the name rijndael
and are the able to start using it now, or we define the name as aes and
wait until it is official.

Perhaps I just have a vivid imagination but I can see potential problems
if people now implement what they think is AES and nist then tweaks the
algorithm so we have incompatible versions of the "same" algorithm.

So to summarize: I do not see any real advantages of calling it aes, but
I see one drawback in that we may get implementations which do not
conform to the official AES when that is released.

	/MaF

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 04 Oct 2000 11:19:47 -0400

>        (2.5) NIST makes apropriate changes to the draft

        Changes to draft will definitely NOT include changing 
the algorithm chosen.  It might involve changes to which 
US Government agencies are required to use it, what modes a
US Government agency must deploy, or to what set of conformance 
testing procedures have to be gone through.  

        Please recall that the document NIST is producing is a 
(US) Federal Information Processing Standard (FIPS), which 
levies requirements ONLY upon US Government agencies (sometimes 
FIPS are not mandatory for US Dept of Defence).  This is not an ANSI,
ISO, or ITU document or standard, where meaningful technical changes
might happen before final publication.

>testing criteriaof the official AES. NIST may still make changes to the

        I believe there is no risk to us that the AES algorithm will
change, based on past experience with the FIPS process, public
statements by NIST folks about AES, and conversations with folks 
at NIST/Gaithersburg, MD.  If the Security ADs disagreed with my
analysis, they wouldn't have asked IANA to allocate an IPsec magic
number for AES.  The ADs did so yesterday and IANA allocated the
magic number within a couple of hours.

Regards,

Ran
[email-masked]

---

From: Sami Lehtinen <[email-masked]>
Date: Tue, 10 Oct 2000 23:50:29 +0300 (EEST)

AES or Rijndael?

There have been opinions about this for both sides, but no real
consensus. As I'm currently trying to finish these, I'd like to know
which should it be. Personally, I'd like AES, but because it isn't
officially official yet, there just might be changes. OTOH, there have
been opinions Rijndael will become AES without changes, and that's the
impression I got after threading through the NIST pages. And it would
be a shame if we were to use the "rijndael" name long after it has
been declared AES.

So, what's it going to be?

-- 
[[email-masked]          --  Sami J. Lehtinen  --           [email-masked]]
[work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl]
[SSH Communications Security Corp               http://www.ssh.com/]

---

From: "Jeff P. Van Dyke" <[email-masked]>
Date: Tue, 10 Oct 2000 19:04:46 -0600

From: "Sami Lehtinen" <[email-masked]>
> So, what's it going to be?

After reading the NIST pages...

I would prefer we use AES in the draft.  Something like:

  "aes128-cbc"
  "aes192-cbc"
  "aes256-cbc" 

Jeff P. Van Dyke
[email-masked]

---

From: [email-masked] (Niels M�ller)
Date: 11 Oct 2000 11:37:27 +0200

Sami Lehtinen <[email-masked]> writes:

> officially official yet, there just might be changes.

"aes256-cbc" is fine with me, provided that we all agree that *if* the
final "aes" turns out to be different from today's "rijndael" (say,
two more rounds or something like that), we'll all update our
implementations and just accept the temporary interoperability
problems that causes. I.e. it should be clear that the specs that
exist today (i.e. the rijndael aes proposal documents) are not a
canonical definition of "aes".

I'm considering also using "[email-masked]" as a local
alias for the time being.

/Niels