Subject: [Cfrg] Authenticated encryption

From: [email-masked] (David Wagner)
Date: 14 Apr 2003 04:36:10 GMT

I'd like to report the availability of two research papers on the
subject of authenticated encryption, which might be relevant to this
forum.  Any feedback you might have would be welcomed.

A Conventional Authenticated-Encryption Mode
M. Bellare and P. Rogaway and D. Wagner
http://www.cs.berkeley.edu/~daw/papers/eax.html

Abstract. We propose a block-cipher mode of operation, EAX, for
authenticated-encryption with associated-data (AEAD). Given a nonce $N$,
a message $M$, and a header $H$, the mode protects the privacy of $M$
and the authenticity of both $M$ and $H$. Strings $N,M,H \in \{0,1\}^*$
are arbitrary, and the mode uses $2\lceil M/n \rceil + \lceil H/n\rceil
+ \lceil N/n\rceil$ block-cipher calls when these strings are nonempty
and $n$ is the block length of the underlying block cipher. Among EAX's
characteristics are that it is on-line (the length of a message isn't
needed to begin processing it) and a fixed header can be pre-processed,
effectively removing the per-message cost of binding it to the
ciphertext. EAX is obtained by instantiating a simple generic-composition
method, EAX2, and then collapsing its two keys into one. EAX is provably
secure under a standard complexity-theoretic assumption. EAX is an
alternative to CCM [19], and is likewise patent-free.

A Critique of CCM
P. Rogaway and D. Wagner
http://www.cs.berkeley.edu/~daw/papers/ccm.html

Abstract. CCM is a conventional authenticated-encryption scheme obtained
from a 128-bit block cipher. The mechanism has been adopted as the
mandatory encryption algorithm in an IEEE 802.11 draft standard [15],
and its use has been proposed more broadly [16,17]. In this note we
point out a number of limitations of CCM. A related note provides an
alternative to CCM [5].
_______________________________________________
Cfrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cfrg

---

From: John Viega <[email-masked]>
Date: Tue, 15 Apr 2003 22:52:36 -0400

Nice work!  I'd also like to point people to another new authenticated
encryption mode called CWC:

	http://www.ietf.org/internet-drafts/draft-irtf-cfrg-cwc-00.txt

The main thing that CWC offers that other such modes don't is
that is that it is simultaneously patent-free, provably-secure and
parallelizable (meaning that it will be suitable for securing data over
10 gigabit/sec links).

We will be releasing the full version of our paper (including security
proofs) shortly.

There are some minor issues we'll fix in the next version of the draft,
such as using bit lengths to refer to CWC instances, instead of octet
lengths (i.e., AES-CWC-256 instead of AES-CWC-32).

John

---

From: David Mcgrew <[email-masked]>
Date: Thu, 24 Apr 2003 06:52:35 -0700

John,

>parallelizable (meaning that it will be suitable for securing data over

this is the great property of CWC.  The inability to pipeline chained modes 
like CBC or CBC-MAC makes those modes cost significantly more in hardware 
at speeds like 10gbps.   I'm not sure exactly what the speed limit for 
those modes are (and I'd be glad to hear from someone on the list with a 
hardware design background), but intuitively, I'd expect that an AES mode 
that can be pipelined can go ten times as fast as one that is chained, 
since I'd guess that a single AES round defines the length of the critical 
path in the AES computation.

For others on the list who may wonder what CWC has that UST and TMMH don't 
(besides a more compact description :-),  another good property of CWC is 
that its key size is small.  This is especially important for hardware 
implementations, since the operation of fetching the correct 
decryption/authentication key can be a significant bottleneck in a 
high-speed system.

David

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 24 Apr 2003 16:31:28 -0400

Dear John;

Do you know where I can get an on line version of the CWC reference :

    [CWC]           Kohno, T., Viega, J. and Whiting, D. "A Carter-Wegman
                    and Counter-Based Dual-Use Mode (CWC)".  Manuscript,
                    February, 2003.

Or is this the shortly to appear paper you refer to ?

                                   Regards
                                   Marshall Eubanks

> lengths (i.e., AES-CWC-256 instead of AES-CWC-32).

T.M. Eubanks
Multicast Technologies, Inc.
e-mail : [email-masked]
http://www.multicasttech.com

Test your network for multicast :
http://www.multicasttech.com/mt/

---

From: John Viega <[email-masked]>
Date: Thu, 24 Apr 2003 16:51:45 -0400

Indeed, this is the paper we're preparing.  We have just a bit more 
cosmetic work to do, and should be making it available some time next 
week.

John

---

From: Alex Alten <[email-masked]>
Date: Tue, 29 Apr 2003 10:19:59 -0700

John, Doug, Tadayoshi,

I've only had a chance to skim the I-D draft.  Just a quick question about the
hardware 10 Gbps performance.  For the receiver can this be sustained if
packets are dropped, corrupted or arrive out of order?  If not, is it a bad hit
requiring a resynchronization of some sort?

Thanks,

- Alex

At 04:51 PM 4/24/2003 -0400, John Viega wrote:
>cosmetic work to do, and should be making it available some time next week.
>
>John
>

--

Alex Alten
[email-masked]

---

From: John Viega <[email-masked]>
Date: Tue, 29 Apr 2003 13:43:47 -0400

First, let me say that CWC is designed in such a way that there is no 
kind of order-dependent chaining on block levels.  That is, inputs are 
treated in 96-bit atomic units.  If you have, say, 3000 words come in 
during a single time slice, you can run 1000 parallel computations if 
you want to do so.  In practice, that's not the way the world works, 
but it's at least theoretically possible to process as much data as you 
can handle in a single time slice about as fast as you can handle a 
single block.  That is, CWC could scale to speeds faster to 10 gigabits 
per second in hardware if you throw more hardware at the problem.  The 
tradeoffs are things like dye size and cost.

In short, my answer is that you can (more or less) make CWC run as fast 
as you need it to run (there's a limit somewhere, of course).  We don't 
do anything ourselves to handle dropped or out of order packets, etc.  
Those are problems that must be dealt with in the surrounding 
environment in which CWC is applied.

But, there's no intrinsic issue with CWC that would keep you from 
designing around the problems you mention at the 10 gigabit/second 
level.

John