RFC 4800, Section 6 specifies that the CRC at the end of the
armor is optional, so do not fail to decode signatures missing
the CRC.
Credit: armor.go patch from engineer at Google
Change-Id: I39b04e0afaaafdf7aa86577fe4a35c50e7cf0b2b
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/215022
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
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 <agl@google.com>
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/173778
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When parsing a truncated clearsigned message (one that includes the
opening header but no armored data), the existing implementation of
clearsign.Decode() hangs in an infinite loop. This commit changes
Decode() to detect the end of the buffer and return as if no
clearsigned message was found.
Change-Id: Ibc85b29a08d22868470f48fe300bf8fcb4749768
Reviewed-on: https://go-review.googlesource.com/17693
Reviewed-by: Adam Langley <agl@golang.org>
clearsign.Encode currently creates bad signatures for inputs containing
lines that that consist of only whitespace (gpg --verify and
clearsign.Decode both agree the signature is bad).
RFC 4880 section 7.1 says trailing whitespace is removed when generating
the signature. The previous code correctly handled this for the case of
not being at the beginning of the line by buffering the whitespace.
The previous code had incorrect behavior for the case of being at the
beginning of a line. It was only special-casing dashes and newlines,
directly hashing all other characters.
This happened to work for lines that had leading whitespace followed by
non-whitespace characters, since in that case the leading whitespace is
not trailing.
However, this behavior is incorrect for whitespace-only lines: The
previous code would incorrectly add the first whitespace character to
the hash, when instead it should have been dropped.
This commit moves the whitespace check so that it always happens,
regardless of whether we are at the beginning of a line.
This adds a few tests to capture the expected behavior. The last three
tests fail without the included code change.
Change-Id: I17848b8aaad6f7a4cee414d486be236f7edddd0b
Reviewed-on: https://go-review.googlesource.com/13681
Reviewed-by: Adam Langley <agl@golang.org>
At some point in the distant past, crypto.Hash.New() changed from
returning nil when a hash function wasn't provided, to panicing. Some
of the code in openpgp predates this and was still using the nil check.
LGTM=bradfitz
R=sburford, bradfitz
CC=golang-codereviews
https://golang.org/cl/104850045
Clear signed messages are often seen in email and are formatted so
that the plaintext of the signed message is readable without any
special tools.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/5604043
Roland Shoemaker
Filippo Valsorda
Katie Hockman
Thomas Bushnell, BSG
Benjamin Wester
Peter Tseng
David Symonds
Andrew Gerrand
Adam Langley