As per the spec:
The one exception is that if the octet count is less than
the size of the salt plus passphrase, the full salt plus passphrase
will be hashed even though that is greater than the octet count.
This was broken in #922 (merged as part of #956).
This would cause GPG to be unable to parse unencrypted secret keys,
thinking they were encrypted.
rfc4880bis-08 hints at this requirement, saying:
o MPI of an integer representing the secret key, which is a scalar
of the public EC point.
Since scalar multiplication happens after masking the private key,
this implies that we should serialize the private key after masking,
as well.
This PR adds four config options to configure whether and how to load
indutny/elliptic: use_indutny_elliptic, external_indutny_elliptic,
indutny_elliptic_path and indutny_elliptic_fetch_options.
Also:
- Use tweetnacl.js instead of indutny/elliptic for curve25519 key generation
- Don't initialize indutny's curve25519, improving performance when using that curve
- Verify NIST signatures using Web Crypto instead of indutny/elliptic when not streaming
- Move KeyPair.sign/verify to ecdsa.js
- Move KeyPair.derive to ecdh.js
- Move keyFromPrivate and keyFromPublic to a new indutnyKey.js file
Keep supporting the old names as well though in `openpgp.generateKey`
and `getAlgorithmInfo`, but not in `openpgp.key.generate` (as it is
recommended that developers use `openpgp.generateKey` instead, and
it now throws when using `numBits` instead of `rsaBits`, so there's
no risk of silent key security downgrade).
The old names are now deprecated, and might be removed in v5.
Don't keep the entire message in memory.
This also fixes an unhandled promise rejection when the input
stream contains an error (e.g. an armor checksum mismatch).
Previously the signature parsing function ignored critical bit on
notations.
This change checks for notations that are marked "critical" but are not
on the known notations list (controlled by config array
`openpgp.config.known_notations`) and triggers parse error if such
a notation have been encountered.
See: #897.
Previous implementation used an object to hold notations so if multiple
notations had the same key name only the last one was visible.
After this change notations are exposed as an array of key-value pairs
that can be converted to a map through `new Map(notations)`.
See #897.
