Separate all crypto implementation details from Pack/Unpack

[Moopli]

Extending #352 and #385, make pack/unpack invoke an injectable crypto-operator (could call it a crypter and do some renaming) for all encryption, decryption, AEAD, etc, using format-agnostic parameters, so the envelope format can be algorithm-independent.

[Moopli]

Expected to be needed for the JWE DIDcomm envelope format to be accepted by the IETF, probably not necessary for the legacy envelope format. Uncertain how soon we'll need it.

[Moopli]

What our Packers need as part of this:

For JWE:

• Remove specific uses of chacha or Ed/Curve25519 key size
• Crypter needs to return values of parameters like nonce size, key sizes (pub, priv, symmetric), encryption name string (eg, chacha20poly1305_ietf or ECDH-SS+XC20PKW) (or values which can be used to determine the name string)
• Create generic AEAD encryption functions, including one that can return the nonce used, and the tag and ciphertext separately; and one that can be given the nonce. (nonce is encoded in envelope in some places)
• Provide a function that can provide correct encryption keys given signing keys (conversion of ed25519 -> curve25519, or a lookup for RSA, for example)
• Use generic Crypter interface for crypto functions in creating/decoding SPK, JWK, etc

For Legacy:

• Remove dependency on specific key sizes
• same generic AEAD functions in Crypter
• same signing->encryption public key conversion in Crypter
• DH+AEAD encryption - crypto box and ability to implement and use logically-equivalent functions (like RSA + AES-GCM equivalents to crypto box). "Box Easy" interface needs a decrypt that can accept a nonce, and encrypt that returns the nonce generated (some nonces are part of the envelope).

A note on public key conversion - key types won't necessarily support this (or be able to do it safely), but the pack/unpack algorithms could be modified to operate using only encryption keys, with some updates to the draft specs.

[troyronda]

For the JWE envelope, we should also support all public key formats and algorithms that are being specified in the W3C DID WG & DIF Interop Group.

For public key formats, this is specifically:

• RSA
• ed25519
• sec256k1

For algorithms, we should support:

• XChaCha20-Poly1305
• ChaCha20-Poly1305
• 256-bit AES-GCM

[Moopli]

I think there's a conflation here between two interfaces - one interface is the "logical operations" interface - a crypto user might need, for example, a key wrapping algorithm, a password KDF, a secret-based KDF, an AEAD stream cipher, DH, Sign/Verify, etc. Those can be provided by different algorithms, and we could provide those algorithms in one package - for example, the Ed25519/X25519 Xc20P suite that we are essentially using right now. We could also provide those algorithms as separate interfaces, and I don't know which is cleaner.

To allow the Packers, for example, to be independent of the crypto operation algorithms, then they need to consume an interface that provides the logical operations, so with a suitable implementation, any of RSA, ed25519, and secp256k1 could be used for Diffie-Hellman, for example.

The other interface being conflated is the interface to the crypto plugin itself - this is interface which we will fulfill with a single provider in an aries instance, which provides all of the crypto operations that aries components need. If there is any circumstance where we need multiple alternatives available to an aries instance for the same logical operation (you provided such a circumstance above @troyronda ), then we need to have the crypto plugin have multiple implementations of the relevant logical-operation interfaces.

So, with that example, a crypto plugin that satisfies the relevant specs would have 3 implementations of the public-key-logical-operation interface; for RSA, Ed25519, and secp256k1.