efail -> improvements in case w/o AE (e.g. CMS)

Bernhard Reiter bernhard at intevation.de
Tue May 15 12:38:41 CEST 2018


Am Dienstag 15 Mai 2018 08:45:03 schrieb Bernhard Reiter:
> I'm suggesting to change GnuPG to

to only display or save decrypted contents if it was integrity protected by
either

> >  a) MDC
> >  b) AEAD
> >  c) a signature over the whole contents from someone where it has been
> >     encrypted to (if this is feasable to detect).

for c) it may be enough that the integrity was protected by the hash in the 
signature, if we make sure that it is always signed and then encrypted.

This is an interesting case, because a) and b) is currently not easily
available for CMS with gpgsm. There is an authenticated-data type defined in 
STD 70 (aka RFC 5652) but not yet implemented in Gpgsm 
(https://dev.gnupg.org/T3979).

I read that CMS would allow signing before or after encryption.
The crypto gadget attack would need to be able to reorder, delete and insert 
encrypted data blocks because the plaintext is not yet known. So an attacker
cannot fake the hash done within a signature over the plaintext.
So in the case

   [encrypted  [signed  [ contents]]

the contents can be considered integrity protected and could be displayed
if the hash on the signature is fine, even if we cannot verify the 
authentication.

We would need to disallow the case
  [signed [encrypted [signed [contents]]]
as an attacker might put his own valid signature outside the manipulated 
ciphertext.

(This has been an idea coming up by Andre while we were talking.)

Regards,
Bernhard


-- 
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180515/a186894d/attachment.sig>


More information about the Gnupg-devel mailing list