cms: ECC KeyAgreementRecipientInfo initial support

[nemynm]

This PR intends to bring initial support for Elliptic Curve Cryptography (ECC) for CMS - addressing #1544.

• Following rfc5753, it implements KeyAgreementRecipientInfoBuilder for ECC. For now only EnvelopedData using (ephemeral-static) ECDH is supported.
• It does not include reader/decryption logic (it could be part of another PR if there is interest).
• It does not support SHA1 and 3DES schemes (For SHA1, it could maybe be introduced and gated behind a feature to parse/read/decrypt older/legacy incoming CMS message that use them. However RustCrypto does not seem to support 3DES key wrap)

1. Utils functions:

   • KDF and key-wrapping operation are hosted in their own submodules.
   • Key-derivation uses an internal HashDigest enum to select the hash function to use during key-derivation
   • KeyWrapper is a struct that aims at abstracting the key-wrapping logic for different AES algorithm and different incoming key size.

2. Key Agreement Recipient Info:

   • KeyAgreementRecipientInfoBuilder is hosted in its own submodule.
   • Supported schemes and algorithm are represented using enums. At least three are needed for the builder:
     • EcKeyEncryptionInfo - recipient public key (generic over RustCrypto elliptic-curve).
       While EcKeyEncryptionInfo is essentially the ECC equivalent of the existing KeyEncryptionInfo, it has been introduced to limit API breakage - as it introduces a generic over the chosen elliptic-curve.
     • KeyAgreementAlgorithm - key agreement as per RFC (SHA1 schemes are not supported on purpose, can be amended if needed).
     • KeyWrapAlgorithm - key-wrap algorithm to use.
       For the sake of simplicity From<ContentEncryptionAlgorithm> for KeyWrapAlgorithm trait has been implemented.

3. Testing:
   Unit tests have been written in the relevant files. One integration test showcasing KeyAgreeRecipientInfoBuilder is available, leveraging the existing test P256 key material. Obtained message can be decrypted using:

   openssl cms -decrypt -inkey cms/tests/examples/p256-priv.der -inform PEM

[baloo]

This duplicates the dependency on aes and cipher, we should bump aes-kw to use "aes 0.9.0-pre.2" & "cipher 0.5.0-pre.7".

[baloo]

RustCrypto/key-wraps#34

[baloo]

nemynm#1

[nemynm]

Thanks, I'll merge once it's ready

[nemynm]

Merged

[baloo]

Could we convert that to a trait instead:

pub trait KeyAgreementAlgorithm: AssociatedOid {
    fn kdf(secret: &[u8]);
}

And then make a struct like:

struct DhSinglePassStdDhKdf<D> where D:Digest + {
    digest: PhantomData<D>,
}

impl<D> KeyAgreementAlgorithm for DhSinglePassStdDhKdf<D> where D:Digest {
    fn kdf(secret: &[u8]) {
        ansi_x963_kdf::derive_key_into::<D>(secret)
    }
}

impl AssociatedOid for DhSinglePassStdDhKdf<sha2::Sha224> {
   const OID: ObjectIdentifier = rfc5753::DH_SINGLE_PASS_STD_DH_SHA_224_KDF_SCHEME;
}

[baloo]

I had something like that in mind:
nemynm#2

[nemynm]

Thanks!
Indeed I was not particularly convinced by the current KDF handling, but I thought it was a fair solution that was easily extensible for other schemes/algo (maybe with the help of a quick macro to derive try_ansi_x963_kdf).

At first I actually went the trait route in my code (close-ish to what you proposed), but then settled on the enum and dispatch function. Rationales were:

1. This snippet in EnvelopedDataBuilder at builder.rs#L890 which caught my eye:

    // TODO bk Not good to offer both, `content_encryptor` and `content_encryption_algorithm`.
    // We should
    // (1) either derive `content_encryption_algorithm` from `content_encryptor` (but this is not
    //            yet supported by RustCrypto),
    // (2) or     pass `content_encryption_algorithm` and create an encryptor for it.
    // In the first case, we might need a new trait here, e.g. `DynEncryptionAlgorithmIdentifier` in
    // analogy to `DynSignatureAlgorithmIdentifier`.
    // Going for (2)
    //  content_encryptor: E,
    content_encryption_algorithm: ContentEncryptionAlgorithm,

Even if its not the same situation, I interprated it as "work with enum rather than trait", at least until some is finalized. That was somewhat re-inforced by the current get_hasher() function.

2. Consequently, just passing an enum looked closer to the current API for other builders (having to specify the KA generic in KeyAgreeRecipientInfoBuilder seemed a tad less user-friendly).

3. I thought that if we ended up supporting the other key agreement algorithm (e.g. cofactor ECDH and 1-Pass ECMQV ), we may want to have a more complete trait like:

pub trait KeyAgreementAlgorithm: AssociatedOid {
    fn shared_secret()
    fn try_kdf(secret: &[u8], other_info: &[u8], key: &mut impl AsMut<[u8]>) -> Result<()>;
}

-> So essentially folding most of the build() logic behind a trait - so to speak.

However not exactly knowing yet:

• what shared_secret() signature should look like for all.
• the input to try_kdf() would be with other schemes (would that always be a SharedSecret<C> or something more generic like &[u8]).
• if we should have three structs (DhSinglePassStdDhKdf, DhSinglePassCoFactorDhKdf, MqvSinglePassKdf) or maybe just one generic for the three schemes.

I figured that a trait was maybe not the best solution yet.

Anyway as you can see, these are more generic thoughts than strong reasons not to, so I am also ok to go the trait route now too.

[baloo]

TODO: We should implement AssociatedOid in https://github.com/RustCrypto/key-wraps/tree/master/aes-kw

[baloo]

RustCrypto/key-wraps#35

[nemynm]

Thanks will merge once its merged upstream

[baloo]

we will need to move that to a generic parameter as well

[nemynm]

I could add a trait for Key Wrapping too. Do you want the trait to only implement AssociateOid, or the key wrapping logic itself as well (akin to kdf for the KeyAgreement trait)?

[nemynm]

we will need to move that to a generic parameter as well

@baloo, I came up with a trait-based approach for key-wrapping, a first draft is available here nemynm#3, let me know your thoughts and if this is the kind of things you had in mind.