implement KeySizeUser for SigningKey and VerifyingKey

[carloskiki]

Implements the KeyInit and KeySizeUser traits from crypto-common for SigningKey and VerifyingKey.

[tarcieri]

This couples the KeyInit trait to the version of crypto-common in use by the sha2 crate.

At the very least this needs a versioning strategy which can tolerate upgrades.

[carloskiki]

Would gating this behind the digest feature and using digest's reexport of crypto-common help?

Edit: Or we could use digest's KeyInit trait directly (it reexports the trait).

[carloskiki]

I believe the work with this PR is done and would be ready for review.

[rozbb]

Thank you! I'm confused, though, aren't these traits mostly intended for symmetric primitives?

[tarcieri]

We don't currently use them with the elliptic-curve crate but potentially could. That would probably be the proper way to implement them (e.g. like #746)

[rozbb]

I guess I'm not sure how you'd use these traits with a signer in practice. Do you have a use case in mind?

[tarcieri]

@rozbb the main advantage would probably be having a common trait-based API that can work across several key types, more for consistency than generic abstractions, IMO

[tarcieri]

I took a look at using KeyInit in elliptic-curve. While it works for e.g. Ed25519 due to clamping, for NIST P-curves we need a fallible constructor to handle the case that the key overflows the order. So we probably won't go that route, even though it works here.

[carloskiki]

I need a trait based interface for signing key generation because I am working on an cryptographic primitive that is agnostic over its signature scheme. The signature crate does not provide an interface for Signer creation so I was hoping to use the digest traits instead. As @tarcieri pointed out, we may want something that is fallible instead for the general case. Perhaps coming from the elliptic-curve crate, but that would narrow out the space of signature schemes to only those which use elliptic curve cryptography.

I think it is fine to still implement these traits as they are meant generalize what the from_bytes implementation currently does, even if this implementation cannot be generalized to other curves/schemes.

[tarcieri]

@carloskiki I would probably suggest using PKCS#8 for a common key init for that purpose, e.g. pkcs8::DecodePrivateKey. This should already be impl'd everywhere you need it.

[carloskiki]

With PKCS#8 I need to first encode the bytes and then decode them again in order to generate a key, but I already have the bytes of the private key, I just want to instantiate a signing key with them...

[tarcieri]

Either way it's a serialization of the key as bytes. PKCS#8 just includes algorithm information and is the "standard" private key format (and also offers features like password-based encryption).

It can also be used to dynamically dispatch to various supported algorithms, if you're interested in that sort of thing.

It's also available for all of the SigningKey types in the @RustCrypto org and dalek today.

[carloskiki]

I understand that. In my case I still need KeySizeUser to know the number of bytes used by the key in the type system.

I can remove the KeyInit implementation if this is not something we want.

[tarcieri]

KeyInit can't be used with e.g. ecdsa::SigningKey because at the minimum it requires fallibility.

Edit: or for that matter, rsa::pkcs1v15::SigningKey and rsa::pss::SigningKey.

Edit again: opened RustCrypto/traits#1897 to discuss a fallible KeyInit

[carloskiki]

Maybe something like From<Key<Self>> and TryFrom<Key<Self>> for those that have fallible constructors?

[carloskiki]

I removed the KeyInit implementation, and kept the KeySizeUser implementation as it did not seem troublesome from the discussion. I require this to know the key size of a signing key generically.

[tarcieri]

It should also be possible to impl the TryKeyInit and Generate traits that will be in the next release of crypto-common

[carloskiki]

Sorry for the churn with recent forced pushes.

I implemented Generate and TryKeyInit as suggested in #733 (comment).