Closed jedisct1 closed 4 years ago
Merging this, mainly to update the implementation since breaking changes happened in the wasmtime world. But we may want to go back to specialized types later, especially once tooling improves to make it easier to define structured interfaces.
Signatures used to have their own key types:
signature_keypair
andsignature_publickey
With a bunch of associated functions such as
signature_keypair_import()
.This changes these to generic
keypair
andpublickey
types, with generic functions over these, that can be shared by signatures and key exchange mechanisms.So,
signature_keypair_generate("Ed25519", None)
returning aSignatureKeyPair
becomes
keypair_generate(AlgorithmType::Signatures, "Ed25519", None)
returning aKeyPair
The exact same type and function can be used to create a key pair for non-signature purposes:
keypair_generate(AlgorithmType::KEM, "ntruhrss701", None)
This makes the API surface smaller compared to using specialized types and functions. The downside is that it makes static type checking more difficult.
In addition to an algorithm name, we also now need to provide an algorithm type (and the enum we had for options can be reused).
Without this, a
SignatureKeyPair::create(alg_name)
function exposed by a library could be used to create a different type of key pair. Signature operations would eventually fail, but the API should prevent the inconsistency at key creation time.Besides the key exchange API, a motivation for this change is the fact that once finite field arithmetic operations are available, a common requirement will be to convert the output of these operations directly into keys.
We may also want to be able to perform conversion between compatible keys (for example between X25519 and Ed25519).
Having specialized key types and functions for these operations would enlarge the API surface even further.
From a bindings perspective, the generic types can be implemented as internal classes, with user-facing classes being derived from these.
For example the AssemblyScript bindings still expose
SignaturePublicKey
andSignatureKeyPair
classes, but these classes just extendPublicKey
andKeyPair
withsign
andsignature_verify()
functions.In language supporting generics, generics can also be used to add compile-time type safety as an option to dedicated types and functions.