When given a streamed `message` and a detached `signature` in input,
the function would return an empty array as `data` instead of
the input stream, meaning it was not possible to pull it, causing
the `verified` promise to hang indefinitely.
The above issue was introduced v5.0.0-2, and thus affects all v5 releases
up to v5.11.1.
Set to replace `enums.curve.ed25519` (resp. `.curve25519`), which can still be used everywhere,
but it will be dropped in v6.
Deprecation notices have been added to ease transition.
As mandated by the new crypto-refresh spec.
This applies to both the new and legacy EdDSA format.
For the legacy signatures, it is not expected to be a breaking change, since the spec
already mandated the use SHA-256 (or stronger).
The required hash size was determined based on the subkey algo rather than the primary key.
As a result, if the subkey being certified required a shorter hash size than the ECDSA primary key,
the issued signature would include a shorter digest than expected.
This issue is not expected to have practical security impact, and
it only affected keys with ECDSA subkeys with smaller key sizes than their ECDSA primary key
(e.g. NIST p521 primary key and NIST p256 subkey).
Due to a bug, a shorter hash could be selected, and signing would throw as a result.
This change fixes the issue by automatically picking SHA-256, if needed.
The same was already done for legacy EdDSA signatures.
Set to replace `enums.publicKey.eddsa`, which can still be used everywhere,
but it will be dropped in v6.
Deprecation notices have been added to ease transition.
The code used to wrongly consider e.g. x25519 keys without key flags as valid signing keys.
Keys without key flags are very rare nowadays, so this fix has low impact.
As specified in openpgp-crypto-refresh-09.
Instead of encoding the symmetric key algorithm in the PKESK ciphertext (requiring padding),
the symmetric key algorithm is left unencrypted.
Co-authored-by: Lukas Burkhalter <lukas.burkhalter@proton.ch>
Such keys are still capable of encryption and signature verification.
This change is relevant for forward compatibility of v4 keys encrypted using e.g. argon2.
Previously, `verifyAllUsers` would fail on keys with User Attributes.
Now, it returns a list of objects that have a either a non-null `userID`
property (in the case of User IDs) or a non-null `userAttribute`
property that contains the User Attribute packet.
Co-authored-by: Daniel Huigens <d.huigens@protonmail.com>
This config option allows parsing additional packet types when parsing
a packet list or armored object, in contexts where they are normally
not expected to appear, by passing a list of packet classes
(e.g. `additionalAllowedPackets: [PublicKeyPacket]`).
Most rules are derived from the `airbnb` template.
Some "bad" rule exceptions remain, but they require too many changes to fix, so
we leave it to a future refactoring.
Since we don't interpret these notations, it is up to the caller
to handle them, and thus also to decide whether they are "known".
If they are marked as critical, and aren't handled by the caller,
we should consider the signature unverified.
Assign most signature subpacket types a criticality based on whether
failing to interpret their meaning would negatively impact security.
For Notation Data subpackets, let the user indicate their criticality
using the `signatureNotations[*].critical` property.
The changes do not affect the public API:
`RandomBuffer` was used internally for secure randomness generation before
`crypto.getRandomValues` was made available to WebWorkers, requiring
generating randomness in the main thread.
As a result of the change, the internal `getRandomBytes()` and some functions
that use it are no longer async.
Move the Issuer, Issuer Fingerprint, and Embedded Signature subpackets
to the hashed subpackets for new signatures. While we allow these to be
unhashed, it's safer to hash them, and this simplifies the code as well.
When re-serializing a signature packet, don't add Issuer, Issuer
Fingerprint, and Embedded Signature subpackets to the unhashed
subpackets if they weren't already there.
Also, store all unhashed subpackets in `signature.unhashedSubpackets`,
not just the "disallowed" ones.
Signing a `CleartextMessage` containing trailing whitespace and \r\n line
endings (as opposed to \n) would result in an unverifiable signature. The issue
seems to have been present since v3.0.9 . These broken signatures were
unverifiable even in the OpenPGP.js version(s) that generated them.
Recent Node.js seems to have dropped support for ripemd160.
Thus, properly check the availability of hashes before using them.
Also, add Node.js 18 to CI.
