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.
Calling `openpgp.decrypt` with a message that contains encrypted session keys
followed by a non-encrypted packet (e.g. Literal or Compressed Data packet)
used to succeed, even if a wrong passphrase/key was provided.
With this change, the operation will always fail, and the user is warned that
the data was not encrypted.
NB: a message that did not contain any encrypted session key packet would fail
to decrypt even prior to this change.
The relevant packets will be considered unsupported instead of malformed.
Hence, parsing them will succeed by default (based on
`config.ignoreUnsupportedPackets`).
When parsing errors are being ignored, packets that fail to parse are now
included in the resulting packet list as `UnparseablePacket`s . This way, when
parsing keys that contain unparsable (sub)key, we avoid associating the
following non-key packets to the wrong key entity.
On serialization, `UnparseablePacket`s are also included by writing their raw
packet body as it was read.
Breaking change: `openpgp.encryptKey` now throws if an empty string is given as
passphrase. The operation used to succeed, but the resulting key was left in an
inconsistent state, and e.g. serialization would not be possible.
Non-breaking changes:
- `options.passphrase` in `generateKey` and `reformatKey` now defaults to
`undefined` instead of empty string. Passing an empty string does not throw for
now, but this might change in the future to align with `encryptKey`'s
behaviour.
- In TS, add `GenerateKeyOptions` as alias of `KeyOptions`, to clarify its
scope.
In browsers, encryption of messages larger than 3MB (or a custom value
based on `config.minBytesForWebCrypto`) would throw the error `Error encrypting
message: 'crypto.getCipher' is not a function`.
The issue was introduced in v5.1 .
