Key pairs import/export/generation

[jedisct1]

Hi!

jwt_compact provides helpers to generate symmetric keys for HS256/HS384/HS512.

However, it doesn't expose anything similar ECDSA/EdDSA/RSA signatures.

This forces applications to also import and use the low-level underlying implementations. Even in the jwt-compact test suite, this is not convenient, as individual tests have to be written according to every possible backend.

Would you be opposed to exposing a backend-agnostic API to import, export and generate asymmetric keys?

[slowli]

Hi! Sorry for such a delay with the answer 🤦‍♂️

Would you be opposed to exposing a backend-agnostic API to import, export and generate asymmetric keys?

Do you mean using one-size-fits-all data types for all cryptographic backends? (That is, a data type for an "signing key".) Or for data types within a single algorithm with possible multiple backends? (That is, a data type for a "Ed25519 signing key".) I'm soft-opposed to the first idea; one of motivations behind the crate was type safety, which is hard to achieve with such all-encompassing types. Regarding the second idea, I'm more welcoming, but I'd like to elaborate on it still.

Even in the jwt-compact test suite, this is not convenient, as individual tests have to be written according to every possible backend.

I don't think that exposing backend-specific types is a bad idea per se. In the current crate architecture, it's the developer responsibility to enable the backend, and the key management is (intentionally) moved out of the area of responsibility of the crate - backends (usually) know how to deal with keys secure, and introducing additional layer of abstraction just increases the risks of something going terribly wrong™, IMO.

Regarding the tests specifically, this is issue specific to tests. I think in most of use cases the library user will deal with fewer backends than are supported by the library, and certainly won't have to deal with the "overlapping" backends for the same crypto algorithm.

[jedisct1]

Hi!

I meant the later. Having backend-independent types for a given algorithm.

Creating a key currently requires diving into the documentation of unrelated crates. Switching backends (e.g. using ed25519-compact in a WebAssembly envirionment and dalek otherwise) requires different code.
Since the backends are not re-exported, applications also have to explicitly reimport them, and make sure to import the same version as jwt-compact.

This makes usage of jwt-compact more complicated and confusing than it could, and the HS* schemes API inconsistent with asymmetric schemes.

[slowli]

@jedisct1 I've sketched the abstraction layer in #16. Does it look passable to you, or is some functionality missing?

[jedisct1]

Looking good!

I'm wondering if generate() couldn't eventually be a trait as well. But your changes are nice and clean.

[slowli]

Moved the remaining part of the issue to #26.