openpgp/clearsign: reject potentially misleading headers and messages

Aida Mynzhasova of SEC Consult Vulnerability Lab reported that the
clearsign package accepts some malformed messages, which can make it
possible for an attacker to trick a human user (but not a Go program)
into thinking unverified text is part of the message.

For example, if in the following message the vertical tab character is
printed as a new line, a human observer could believe that the
unverified header text is part of the signed message.

Hash: SHA1\x0b\x0bThis text is part of the header.

Hello world!
Version: GnuPG v1.4.10 (GNU/Linux)


The OpenPGP specs are delightfully vague about purpose and validation of
these headers. RFC 4880, Section 7 says

    The cleartext signed message consists of:

        - The cleartext header '-----BEGIN PGP SIGNED MESSAGE-----' on a
        single line,

        - One or more "Hash" Armor Headers,

        - Exactly one empty line not included into the message digest,

but also

    If MD5 is the only hash used, then an
    implementation MAY omit this header for improved V2.x compatibility.


    If more than one message digest is used in the signature, the "Hash"
    armor header contains a comma-delimited list of used message digests.

which seems to suggest that there can be zero or more Hash headers, each
with one or more algorithms, and no other header types.

Anyway, it's entirely unclear what security purpose, if any, the Hash
header accomplishes. If the hash is too weak to be secure or
unsupported, the verification will fail. Otherwise, the user shouldn't
care. Given its dubious function, avoid breaking abstractions to check
that it matches the signature, and just document it as unverified.

As for valid characters, RFC 4880 is silent, except reluctantly
mentioning that the Comment header can be UTF-8, but I am going to
assume that all hash algorithms will have ASCII names, because come on.

Even more importantly, reject non-Hash SIGNED MESSAGE headers (as opposed
to the SIGNATURE headers), to prevent a "Thank you!" message turning into

Reminder: I need you to wire $100k to 12345566 as soon as possible.

Thank you!

While at it, also check for trailing characters after the signed message
delimiter, as they are invalid and can be similarly used to confuse humans.

The Decode API is also unfortunate in that it doesn't return an error,
so we can't tell the user what's wrong with the message, but that's what
we've got.

Change-Id: I8a72c4851075337443d7a27e0b49a6b6e39f5a41
Reviewed-by: Adam Langley <>
Run-TryBot: Filippo Valsorda <>
Reviewed-by: Adam Langley <>
TryBot-Result: Gobot Gobot <>
2 files changed
tree: 04ff3b2029564ba5aef3931b25f74712f4f86578
  1. acme/
  2. argon2/
  3. bcrypt/
  4. blake2b/
  5. blake2s/
  6. blowfish/
  7. bn256/
  8. cast5/
  9. chacha20poly1305/
  10. cryptobyte/
  11. curve25519/
  12. ed25519/
  13. hkdf/
  14. internal/
  15. md4/
  16. nacl/
  17. ocsp/
  18. openpgp/
  19. otr/
  20. pbkdf2/
  21. pkcs12/
  22. poly1305/
  23. ripemd160/
  24. salsa20/
  25. scrypt/
  26. sha3/
  27. ssh/
  28. tea/
  29. twofish/
  30. xtea/
  31. xts/
  32. .gitattributes
  33. .gitignore
  35. codereview.cfg
  38. go.mod
  39. go.sum

Go Cryptography

This repository holds supplementary Go cryptography libraries.


The easiest way to install is to run go get -u You can also manually git clone the repository to $GOPATH/src/

Report Issues / Send Patches

This repository uses Gerrit for code changes. To learn how to submit changes to this repository, see

The main issue tracker for the crypto repository is located at Prefix your issue with “x/crypto:” in the subject line, so it is easy to find.

Note that contributions to the cryptography package receive additional scrutiny due to their sensitive nature. Patches may take longer than normal to receive feedback.