Also, switch from returning false to throwing errors in most verify*()
functions, as well as in `await signatures[*].verified`, in order to be
able to show more informative error messages.
(When config.allow_unauthenticated_stream is set or the message is
AEAD-encrypted.)
The issue was that, when hashing the data for verification, we would
only start hashing at the very end (and keep the message in memory)
because nobody was "pulling" the stream containing the hash yet, so
backpressure was keeping the data from being hashed.
Note that, of the two patches in this commit, only the onePassSig.hashed
property actually mattered, for some reason. Also, the minimum
highWaterMark of 1 should have pulled the hashed stream anyway, I think.
I'm not sure why that didn't happen.
Both those with a 2-byte hash (instead of SHA1 or an AEAD authentication
tag) and those without an S2K specifier (i.e., using MD5 for S2K) -
support for the latter was already broken.
Vulnerabilities can arise not just from generating keys like this, but
from using them as well (if an attacker can tamper with them), hence why
we're removing support.
This function checks whether the private and public key parameters
of the primary key match.
This check is necessary when using your own private key to encrypt
data if the private key was stored on an untrusted medium, and
trust is derived from being able to decrypt the private key.
This also has the effect that we only throw on them when trying to use
the key, instead of when parsing it, and that we don't throw when the
authorized revocation key is specified in a separate direct-key
signature instead of a User ID self-signature (the spec only specifies
including it in a direct-key signature, so that means that we
effectively don't reject them anymore. This is because users that
wanted to use the key, could remove this separate signature, anyway.)
