feat(config): support modern ECDH/AES-GCM encryption

[viceice]

Changes

• Add modern ECDH/AES-GCM encryption.
• Add Docs
• build-in function to geneate a private key
• build-in function to encrypt a secret

Context

• closes Switch from openpgp to node crypto #27377

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[rarkins]

Will this support the same RSA 4096 private/public keys?

[viceice]

Will this support the same RSA 4096 private/public keys?

which keys? the gpg keys? no. the key derive is only possible with two ecdh keys.
but we can support rsa encryption too if you like

[Churro]

Suggested change

	export const EcJwkPriv = EcJwkPub.extend({
	const EcJwkPriv = EcJwkPub.extend({

[Churro]

This looks cryptographically problematic to me.

The shared secret derived by an ECDH key agreement is not uniformly random. deriveKey doesn't perform any key stretching or hashing on the shared secret. It is basically the same as calling deriveBits to get a byte array and then passing it to importKey to use as a symmetric key with AES. P-384 generates more output bits than needed, some part will simply be dropped to fit the 256 bits needed for AES.

To derive a cryptographically strong key for AES-GCM, the shared secret needs to be processed via HKDF. An example how to do this can be found here: https://stackoverflow.com/a/67942717/589259
Note that this example uses an empty salt. I'd say it makes sense to use a salt though, as it ensures that reusing the same shared secret for two operations will still yield different encryption keys. I'd suggest prepending it to the ciphertext.

Also see:

• Problems with ECDH deriveBits/deriveKey operations w3c/webcrypto#193
• https://security.stackexchange.com/questions/201284/ecdh-and-static-key-encryption
• https://crypto.stackexchange.com/questions/30367/ecdh-security-when-no-kdf-is-used
• https://crypto.stackexchange.com/questions/97975/applications-in-which-you-should-shouldnt-use-a-salt-with-hkdf

[viceice]

🤔 didn't know that. do we need a separate value for salt, or can we reuse the aes-gcm iv?
We should try to make the encypted object as small as possible but of cause as secure as possible.

[Churro]

Salt and IV are similar in some ways but also need to fulfill different requirements depending on what you want to achieve. I'd suggest to not simply reuse the same values. What you could do in this particular case:

Call deriveBits({ name: "HKDF", ... (as shown in the stackoverflow example above) and produce bits for both the key and the VI. You can use the iv (as it is currently named in your code) as a salt value for the HKDF. When calling deriveBits, increase the length param by the 96 bits you need for the IV, so 256 + 96 bits overall, then use the trailing 96 bits for the IV.

This way you don't need to prepend it to the ciphertext and the HKDF ensures it's uniformly random for use with a symmetric cipher like AES. If you change the salt, the encryption key and IV will change as well. This is generally desirable because it ensures that if you encrypt multiple texts (with different salt values in the HKDF call), a unique encryption key and IV will be used as well.

[viceice]

closing for now, as we've an alternate pgp implementation