[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.



> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Theodore Ts'o
> Sent: Thursday, May 23, 2002 1:48 PM
> To: ipsec@lists.tislabs.com; sheila.frankel@nist.gov
> Cc: byfraser@cisco.com
> Subject: WG LAST CALL: draft-ietf-ipsec-ciph-aes-xcbc-mac-01.txt
>
>
>
> This is a working group last call for comments for the aes-xcbc-mac-01
> draft, for progression to Proposed Standard.  This last call
> will expire
> on June 6th.
>
> Sheila, could you please work with IANA to get assignments for the
> AH_AES_XCBC_MAC_96 and AES-XCBC-MAC-96 for the AH and ESP transforms,
> respectively.  Many thanks!!
>
> 					- Ted and Barbara
>