This is to signal support to senders who wish to use these algos.
Note that SHA256 remains as first default preference, followed by SHA512,
as in the context of OpenPGP signatures they provide
better performance/security ratio than their SHA3 counterparts.
Key flags are needed to restrict key usage to specific purposes:
https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#section-5.2.3.29 .
Some older keys (e.g. from OpenPGP.js v1) do not declare any key flags.
In previous OpenPGP.js versions, we've allowed such keys to be used for any operation for which they were compatible.
This behaviour has now changed, and these keys are not allowed to be used for any operation.
The setting `config.allowMissingKeyFlags` has been added to selectively revert to the past behaviour.
This is the default setting and it ensures that the main chunk does not include
additional exports, which is is important when importing the module as `import *`
as shown in the readme.
In practice, this change does not affect the chunking with the current code.
This primarily affects the lightweight build, which will not include these
(fairly large) libs in the main bundle file. This allows fetching their code only if required:
- Noble-curves is only needed for curves other than curve25519.
- Noble-hashes is needed for streamed hashing and e.g. SHA3 on web.
- BN.js is used by the above libs, and it's also separately needed for platforms
without native BigInt support.
At some point we used to generate invalid ECDSA sigs with the js (non-native) elliptic lib,
if the signature digest had leading zeros: https://github.com/openpgpjs/openpgpjs/pull/948 .
Brainpool curves are the most likely to have been affected by the bug, since they do not
have WebCrypto support (unlike NIST curves).
This commit reintroduces support on web to verify such invalid signatures
(support for this was previously built-in in the indutny-elliptic library).
It also expands the fix to work in Node.
Unlike elliptic, noble-curves targets algorithmic constant time, and
it relies on the native BigInts when available, resulting in a smaller bundle
and improved performance.
Also, expand testing of fallback elliptic implementation.
As per the spec, v6 keys must not use the legacy curve25519 format.
The new format is not used by default with v4 keys as it's not compatible with OpenPGP.js older than v5.10.0 .
However, v6 keys already break compatibility, so if the user requests them via config flag, we can safely use the new curve format as well.
Determine whether AEAD should be used for encryption solely based the encryption key preferences.
Previously, the config flag was also used to control the behaviour, since AEAD messages were not standardised nor widely supported.
To generate keys that declare AEAD in their preferences, use `generateKey` with `config.aeadProtect = true`.
This special cipher value can be relevant for unencrypted private keys:
https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#section-12.2.1 .
However, it is no longer used internally, and on the contrary it could cause
confusion on SKESK decryption, where "random" cipher algos are returned in case
of wrong password.
This change also fixes a flaky test on password-based decryption, caused by the
PKESK v6 changes which add support for `null` cipher algos. The code did not
distinguish between a `null` and a `0` (plaintext) algo identifier, and would
break when the latter was returned on SKESK decryption.
The latest version of the crypto refresh (i.e., !313, !314) specifies that
the "Hash" header is depricated. This commit changes that the Hash header
is only generated if a cleartext message contains a non-V6 signature.
The latest version of the crypto refresh (i.e., !313, !314) specifies that
the "Hash" header is deprecated, and that an implementation that is verifying
a cleartext signed message MUST ignore this header.
However, we go against this directive, and keep the checks in place to avoid
arbitrary injection of text as part of the "Hash" header payload.
We also mandate that if the hash header is present, the declared
algorithm matches the signature algorithm. This is again to avoid
a spoofing attack where e.g. a SHA1 signature is presented as
using SHA512.
Related CVEs: CVE-2019-11841, CVE-2023-41037.
This commit does not change the writing part of cleartext messages.
# Conflicts:
# src/cleartext.js
Introduces v6 one-pass signature packets required for v6 signatures.
Includes the changes from !305 of the crypto refresh:
https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/305
Also, introduce `OnePassSignaturePacket.fromSignaturePacket` to simplify
OPS generation.
The Packet Tag space is now partitioned into critical packets and non-critical packets.
If an implementation encounters a critical packet where the packet type is unknown in a packet sequence,
it MUST reject the whole packet sequence. On the other hand, an unknown non-critical packet MUST be ignored.
See https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#section-4.3.1 .
Rather than using the config to determine which algorithms to try
to decrypt session keys for, try the algorithm we know the message
was encrypted with.
Instead of calling getPreferredAlgo('symmetric') and
getPreferredAlgo('aead'), we define and call getPreferredCipherSuite()
to determine the preferred symmetric and AEAD algorithm.
Additionally, we remove isAEADSupported(), instead we return
aeadAlgorithm: undefined from getPreferredCipherSuite() if AEAD is not
supported (CFB is used instead).
And finally, we define getPreferredCompressionAlgo() to replace
getPreferredAlgo('compression').
The latest crypto refresh specifies an HKDF step to be used for
deriving the key to encrypt the session key with.
It also specifies two additional length fields.
The crypto refresh says that we MUST NOT reject messages where the
CRC24 checksum is incorrect. So, we remove the check for it.
Also, remove the checksumRequired config.
