|author||Filippo Valsorda <email@example.com>||Tue Apr 23 15:32:34 2019 -0400|
|committer||Filippo Valsorda <firstname.lastname@example.org>||Wed Apr 24 20:35:55 2019 +0000|
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. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1\x0b\x0bThis text is part of the header. Hello world! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iJwEAQECAAYFAk8kMuEACgkQO9o98PRieSpMsAQAhmY/vwmNpflrPgmfWsYhk5O8 [...] MyTpno24AjIAGb+mH1U= =hIJ6 -----END PGP SIGNATURE----- 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. and 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 -----BEGIN PGP SIGNED MESSAGE----- Reminder: I need you to wire $100k to 12345566 as soon as possible. Thank you! -----BEGIN PGP SIGNATURE----- [...] 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-on: https://team-review.git.corp.google.com/c/golang/go-private/+/453011 Reviewed-by: Adam Langley <email@example.com> Reviewed-on: https://go-review.googlesource.com/c/crypto/+/173778 Run-TryBot: Filippo Valsorda <firstname.lastname@example.org> Reviewed-by: Adam Langley <email@example.com> TryBot-Result: Gobot Gobot <firstname.lastname@example.org>
This repository holds supplementary Go cryptography libraries.
The easiest way to install is to run
go get -u golang.org/x/crypto/.... You can also manually git clone the repository to
This repository uses Gerrit for code changes. To learn how to submit changes to this repository, see https://golang.org/doc/contribute.html.
The main issue tracker for the crypto repository is located at https://github.com/golang/go/issues. 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.