Support "passphrase" option in crytpo.generateKeyPair #3

It would be nice to be able to provide a passphrase, and have that used in the creation of the private key. This is per the options available on crypto's generateKeyPair.

👍 Agreed.

Would you mind pasting an example of how this works in node, for reference, and also check to see if and how this could be supported in the browser?

I'm planning to get Rasha and Eckles ported to the browser this weekend and I'm hoping to keep the APIs consistent.

This could be added PEM-only at first - which means that the x509/asn1 code would need to be updated to support it - and I believe there's something in the JOSE spec that dictates how it's done for JWK as well.

This is just copy-pasted from the Crypto docs:

const { generateKeyPair } = require('crypto');
generateKeyPair('rsa', {
  modulusLength: 4096,
  publicKeyEncoding: {
    type: 'spki',
    format: 'pem'
  },
  privateKeyEncoding: {
    type: 'pkcs8',
    format: 'pem',
    cipher: 'aes-256-cbc',
    passphrase: 'top secret'
  }
}, (err, publicKey, privateKey) => {
  // Handle errors and use the generated key pair.
});

Since in lib/rasha.js:57 crypto's generateKeyPair is being called, it should be possible to just pass in passphrase as part of the privateKeyEncoding parameter.

As for whether it's available in the browser, I'm looking right now.

Crypto in the browser is new to me, but this seems like it may be related: https://stackoverflow.com/a/38425525

Passing it in would seem simple enough, but Rasha is intended to do signing with jwk and jose, so the change would affect multiple layers of the code.

I'll do a little more to check if WebCrypto supports it, but from that post it looks like not. Though they're talking about 3DES, which was broken wide open years ago and offers no security benefit in today's world. There's probably an AES version that might work in WebCrypto.

This isn't a priority for me, but I'm very willing to work with you to help get it implemented, documented and tested, and I'm okay if we have to document that it works for a, b and c calls in the API, but not x, y, and z.

In other words: I'm actively maintaining this and I have a policy of "move to approve" when it comes to PRs, so I'm not going to ask you to do 11,000 things, be super nit-picky, and then ignore your commits for 2 whole years...

(I've had some bad experiences in open source...)