V6 #1629
Draft
V6 #1629
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
larabr
force-pushed
the
v6
branch
4 times, most recently
from
2951fe8
to
b8995e7
Compare
Closed
larabr
force-pushed
the
v6
branch
2 times, most recently
from
de9b4d5
to
da2edd5
Compare
Require the application to load a polyfill instead.
In terms of API, this feature is backwards compatible, no breaking changes. However, since a Wasm module is loaded for the Argon2 computation, browser apps might need to make changes to their CSP policy in order to use the feature. Newly introduced config fields: - `config.s2kType` (defaulting to `enums.s2k.iterated`): s2k to use on password-based encryption as well as private key encryption; - `config.s2kArgon2Params` (defaulting to "uniformly safe settings" from Argon RFC): parameters to use on encryption when `config.s2kType` is set to `enums.s2k.argon2`;
…s` to package.json Mocha v10 requires the lib to be esm compliant. ESM mandates the use of file extensions in imports, so to minimize the changes (for now), we rely on the flag `experimental-specifier-resolution=node` and on `ts-node` (needed only for Node 20). Breaking changes: downstream bundlers might be affected by the package.json changes depending on how they load the library. NB: legacy package.json entrypoints are still available.
Also, init config before any code is run in tests
…e.js Unclear why the Node tests fails, but we're planning to drop support
fflate already supports ESM and is actively maintained
…to asmcrypto only if key size is not supported CFB decryption is too slow using WebCrypto (CBC mode), since every block needs to be decrypted separately
WebCrypto performance is now on-par or better than non-native libs even for small messages
Fallback needed for AES192, due to missing Chromium support.
The module was barely used, and its presence confusing, since WebCrypto or asmcrypto are often directly used and usable instead. Also, use AES_CBC instead of AES_ECB for single-block encryption, so that we can drop support for the latter in the asmcrypto lib.
asn1.js is a fairly large lib and was simply needed to handle DER encodings in some NodeCrypto operations. This change replaces the dependency by moving to: - JWT encoding for RSA (support added in Node v15) - a much lighter dependency (eckey-utils) for ECDSA, where JWT cannot be used for now, as Node has yet to add decoding support for Brainpool curves. The change also allows us to drop BN.js as a direct dependency, optimising the BigInteger-related chunking in the lightweight build.
larabr
force-pushed
the
v6
branch
2 times, most recently
from
360760e
to
fd2b021
Compare
…esh tests, and compare with gopenpgp v3 sop-openpgpjs did not correctly apply the `OPENPGPJS_PATH` env variable; as a result, it did not actually test the code from either the PR and base branch, but always from the hardcoded version bundled with it.
GPG v2 fails to parse detached signatures without the checksum
The cleartext session key symmetric algorithm was accidentally included in the packet. As a result, the generated messages may fail to parse and/or decrypt in other implementations. The messages would still decrypt successfully in OpenPGP.js, due to an overly permissive parsing procedure, which simply discarded the unused additional byte. We know also throw on unexpected cleartext symmetric algo in PKESK v6.
…instead (#1736) Unclear motivation for adding the original config option; if an expiration is there, it should be honoured. Breaking change: the option used to default to `false`, and ignore revocation expirations. We now honour those expirations, namely match the behaviour resulting from setting the option to `true`.
…terministicSignaturesViaNotation` to disable feature (#1737) EdDSA is known to be vulnerable to fault attacks which can lead to secret key extraction if two signatures over the same data can be collected. Randomly occurring bitflips in specific parts of the computation might in principle result in vulnerable faulty signatures being generated. To protect signatures generated using v4 and v5 keys from this possibility, we randomise each signature by adding a custom notation with a random value, functioning as a salt. For simplicity, we add the salt to all algos, not just EdDSA, as it may also serve as protection in case of weaknesses in the hash algo, potentially hindering e.g. some chosen-prefix attacks. v6 signatures do not need to rely on this, as they are non-deterministic by design. While this notation solution is interoperable, it will reveal that the signature has been generated using OpenPGP.js, which may not be desirable in some cases. For this reason, the option `config.nonDeterministicSignaturesViaNotation` (defaulting to true) has been added to turn off the feature.
The implemented profiles do not work on v5, hence for now they need to be manually disabled in the config of 'sop-openpgpjs-main'.
We need to include the checksum to work around a GnuPG bug where data fails to be decoded if the base64 ends with no padding chars (=) (see https://dev.gnupg.org/T7071). Pure v6 artifacts are unaffected and won't include the checksum, as mandated by the spec. Breaking change: `openpgp.armor` takes an additional `emitChecksum` argument (defaults to false). NB: some types of data must not include the checksum, but compliance is left as responsibility of the caller: this function does not carry out any checks. Refer to the crypto-refresh RFC for more details. --------- Co-authored-by: Daniel Huigens <d.huigens@protonmail.com>
The `config` input was not passed down to the armor function due to an oversight.
…urther relax constraints (#1739) We relaxed constraints in a previous commit, but excluded unicode chars, which are however allowed in v5. We now drop almost all email address constraints, by primarily rejecting control and spaces char classes. Library users are strongly encouraged to implement additional checks as needed, based on their supported email address format. NB: the validity checks in question affect the userID inputs accepted by e.g. `generateKey` and `reformatKey`, not the values parsed from existing entities, e.g. using `readKey` (where almost no validation is performed).
…Protect` The logic was updated in github.com//pull/1678 . The tests worked anyway thanks to the config option matching the (monkey patched) keys' feature flags, which are the deciding factor for whether to use AEAD.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Breaking changes:
(Further changes to be added via PRs to this branch.)
TODO:
draft-ietf-openpgp-crypto-refresh#1442enums.publicKey.eddsa(only keepenums.publicKey.eddsaLegacy)enums.curve(p256->nistP256)enums.curve"aliases" (e.g. OIDs)? are they used?cryptois not definedconfig.allowMissingKeyFlags#1677add eddsa signature validation after signing (except for v6 sigs, which are non-deterministic thanks to the salt) -> waiting for stats about how frequent random bitflips may berandomise v4 signatures by adding notation subpacket (optional, based on newconfigoption)=(this is the actual cause of them failing to parse detached signatures without checksum, it's not due to the latter, just a coincidence)Includes changes from sub-PRs:
crypto-refresh: add support for Ed448/X448 #1625crypto-refresh: support generating Curve448 and Curve25519 keys (new format) #1676config.allowMissingKeyFlags#1677