RE: WG LAST CALL: draft-ietf-ipsec-ciph-aes-xcbc-mac-01.txt

["Joseph D. Harwood" <jharwood@vesta-corp.com>]

The increased amount of memory is one consideration; another is the
increased memory bandwidth.  My estimate is that storing three keys
instead of storing just one key will add about 10% to the memory
bandwidth for SA accesses.  But you also have the option of storing just
the original key and generating K1, K2, and K3 on the fly.  With proper
pipelining it will affect latency but not throughput.  So another
trade-off is (amount of memory, memory bandwidth) vs. (number of gates).


Best Regards,
Joseph D. Harwood
(408) 838-9434
jharwood@vesta-corp.com
www.vesta-corp.com



> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
[mailto:owner-ipsec@lists.tislabs.com]
> On Behalf Of David A. Mcgrew
> Sent: Friday, May 31, 2002 7:48 AM
> To: Theodore Ts'o; Andrew Krywaniuk
> Cc: ipsec@lists.tislabs.com
> Subject: RE: WG LAST CALL: draft-ietf-ipsec-ciph-aes-xcbc-mac-01.txt
> 
> Ted, Andrew,
> 
> > -----Original Message-----
> > From: owner-ipsec@lists.tislabs.com
> > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Theodore Ts'o
> > Sent: Thursday, May 30, 2002 8:49 AM
> > To: Andrew Krywaniuk
> > Cc: ipsec@lists.tislabs.com
> > Subject: Re: WG LAST CALL: draft-ietf-ipsec-ciph-aes-xcbc-mac-01.txt
> >
> >
> > On Thu, May 23, 2002 at 02:59:51PM -0400, Andrew Krywaniuk wrote:
> > > This draft hasn't really been discussed on the list much. I guess
> people
> > > figure that "hey, it's just another crypto algorithm... there
can't be
> > > anything controversial about it".
> > >
> > > The issue which Dave brought up at the meeting and which I sent to
the
> > > authors is that XCBC-MAC skirts the "obvious" solution of
prepending
> the
> > > length of the buffer to the hash input. There is an engineering
> tradeoff
> > > here, which is not mentioned in the draft.
> > >
> > > AES-XCBC-MAC:
> > > a) requires 384 bits of keymat
> > > b) does not require that the length of the message be pre-computed
> > >
> > > The "obvious" solution:
> > > a) requires 128 bits of keymat
> > > b) requires that the length of the message be pre-computed
> > >
> > > Clearly, issue (b) was an important motivation in the design of
> > XCBC-MAC.
> > >
> > > My personal opinion is that this rationale makes sense, since
> > key storage
> > > capacity is unlikely to be the limiting factor in the design of
> > any future
> > > hardware. However, the tradeoff ought to at least be discussed
> > on the list
> > > and acknowledged in the draft.
> >
> > A week has gone by and there doesn't appear to have been any
> > discussion on this point which Andrew has raised.  Does anybody
think
> > that the extra use of keying material used by AES-XCBC-MAC is a
> > problem?  We will assume that silence means people are OK with it as
> > it currently stands.
> 
> I agree with Andrew on this point (and was on vacation for the last
week
> :-).  IMO it makes sense for the WG to record that kind of rationale,
and
> the draft is the natural place to do that.
> 
> As for the tradeoff, XCBC-MAC seems like a fine choice to me, though
> hardware vendors may not like the increased memory requirement.
> 
> David
> 
> >
> > Andrew, how strongly do you feel about requesting the draft be
> > modified to include discussion of this tradeoff?  I suspect that if
> > you contribute text to the document authors, it would probably
> > increase the likelihood that the draft will include discussion on
this
> > point.  :-)
> >
> > 						- Ted