Re: Padding twice in GCM - why?

On Apr 9, 12:17 am, WTShaw <lure...@xxxxxxxxx> wrote:
On Apr 8, 8:33 am, "Scott Fluhrer" <sfluh...@xxxxxxxxxxxxx> wrote:



"TRNG" <T...@xxxxxxxxxxxxxxxxxx> wrote in message

news:01ec9394$0$20628$c3e8da3@xxxxxxxxxxxxxxxxxxxx

Hi,

In the GHASH calcuation in GCM, the input to the GF multiplier is padded
to a block boundary with zeros *twice*, first at the end of the
"AAD" (authenticated but not encrypted data), and then again at the end
of the ciphertext.

I can understand that the concatenation of the AAD and ciphertext must be
padded to match the block size, but this could be achieved with just one
lot of padding at the end of the ciphertext.

Questions:
1.  Is there a security advantage to padding twice?  (Or, put another
way, if the padding at the end of AAD was removed, would there be any
reduction in the security?)
Or is it just an implementation thing?

It's just an implementation thing.

2.  If it is just an implementation thing, can someone please suggest a
reason why padding twice would be simpler than padding once, particularly
with respect to high-speed hardware designs?

Alignment; as designed, the core of the algorithm (which includes the AES
implementation and the GHASH unit) deals only with 128 bit chunks as entire
units.  This does make it simpler in a pipelined architecture.

In the encrypt direction, a pipelined implementation of GCM (and GCM was
designed specifically to be pipeline friendly) can take each 128 bit chunk
coming out of the AES pipeline, xor it with the next 128 bits of plaintext
and then immediately xor that result with the running GHASH.  If the
encrypted region wasn't aligned to a 128 bit boundary, then what we would
need to present to the GHASH unit would be N bits of this ciphertext and
128-N bits of the previous ciphertext (and the value of N would depend on
how long the AAD data actually is).  Similar logic would be needed in the
decrypt direction.  This is certainly doable, but it would add another step
and more complexity.

--
poncho

Imagine that reducing complexity makes it easier to verify a guessed
key, a particular key or many trials in a any shorter period of time.
Now, just WHO would want this?

The people doing multi-gigabit per second GCM that's who.

Tom
.

Relevant Pages

  • Re: Padding twice in GCM - why?
    ... to a block boundary with zeros *twice*, first at the end of the ... "AAD", and then again at the end ... lot of padding at the end of the ciphertext. ... In the encrypt direction, a pipelined implementation of GCM (and GCM was ...
    (sci.crypt)
  • Re: Padding twice in GCM - why?
    ... In the GHASH calcuation in GCM, the input to the GF multiplier is padded ... to a block boundary with zeros *twice*, first at the end of the ... I can understand that the concatenation of the AAD and ciphertext must be ... lot of padding at the end of the ciphertext. ...
    (sci.crypt)
  • Re: Padding twice in GCM - why?
    ... In the GHASH calcuation in GCM, the input to the GF multiplier is padded ... I can understand that the concatenation of the AAD and ciphertext must be ... Is there a security advantage to padding twice? ...
    (sci.crypt)
  • Padding twice in GCM - why?
    ... In the GHASH calcuation in GCM, the input to the GF multiplier is padded ... I can understand that the concatenation of the AAD and ciphertext must be ... Is there a security advantage to padding twice? ...
    (sci.crypt)
  • Re: Meaning of memset (Was: Re: Assigning values to char arrays)
    ... I didn't think twice to clear all bits with ... memset clones including the likes of the code above. ... if unsigned char has padding bits in its ... char is expressly forbidden to have padding ...
    (comp.lang.c)
Quantcast