[Cryptography-dev] GCM tag truncation, backwards compatibility

[Laurens Van Houtven]

Yes, yes, a thousand times yes!

Keep in mind that if you truncate a GCM tag at all, let's say down to your
32 bit example, the security level for existential forgery is much lower
than 32 bits. Furthermore, successful forgeries may reveal the
authentication key. [Ferguson05]

[Ferguson05]:
http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Ferguson2.pdf


On Mon, Jun 30, 2014 at 6:29 PM, Alex Gaynor <alex.gaynor at gmail.com> wrote:

> Background:
>
> Right now when you provide a tag to GCM for decryption/verification, we
> allow it to be truncated, always. This means that applications that don't
> want truncation must add their own length checking.
>
> Analysis:
>
> This is terrible, because it means most applications will silently allow
> truncation down to a 4-byte MAC (32-bits), which is much easier to brute
> force to otherwise exploit than the full 16-byte MAC.
>
> Proposal:
>
> Changing the constructor to disallow truncated MACs by default, and
> require the user to explicitly opt in to truncation.
>
> This is technically backwards-incompatible, but I think it's a good
> change, because of the enormity of the improvement in security.
>
> A patch doing this is here: https://github.com/pyca/cryptography/pull/1201
>
> Feedback please!
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your right
> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: 125F 5C67 DFE9 4084
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140630/ea14a10d/attachment.html>