The current draft assumes that key lengths for MAC are the same as the
MAC output length, and states this as a constraint. The counter-example
is AES-CMAC-256, which has a 256 bit key for AES, and a 128 bit output.
The question for the WG is whether or not this is relevant. The feel
of the r
Hi,
Please respond FOR or AGAINST making the input and output lengths
independent. This consensus call will last until August 19.
I vote FOR independence.
Stefan Winter
--
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la
Hi Alan,
I vote FOR independent lengths, because it will promote algorithm
agility.
David
On Aug 5, 2008, at 3:09 AM, Alan DeKok wrote:
The current draft assumes that key lengths for MAC are the same as
the
MAC output length, and states this as a constraint. The counter-
example
is AES
I also vote FOR independent lengths.
Thanks,
Steve
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of David McGrew
> Sent: Tuesday, August 05, 2008 11:51 AM
> To: Alan DeKok
> Cc: emu@ietf.org
> Subject: Re: [Emu] Consensus call on EAP-GPSK key leng
If we make the change below then we also have to change section 12.9. I
think this is a bit problematic since at one point we had consensus to
address the issues on client state avoidance raised by folks at
Stanford. The goal was that the peer could store its nonce on a
per-server basis rather th
