We had an entire API for each type of key (including key pairs and managed keys) for signatures.
The very same set of functions are required for other operations such as key exchange. So, instead of duplicating everything for each class of algorithm, move everything to generic types that can be shared.
Creating one of these keys now just requires an algorithm family to provide some run-time type safety.
For signatures, we didn't had a secretkey type. This has been introduced.
This causes quite a lot of changes to the API but not to its actual mechanisms.
Aliases are defined at WITX level for the different operation types as a guidance to guest implementations.
As an example of another API using key pairs, a new key exchange namespace has been added, currently providing the simple Diffie-Hellman operation, to be extended with key encapsulation mechanisms.
Managed keys can also now be replaced.
Documentation has also been improved for symmetric operations.
We had an entire API for each type of key (including key pairs and managed keys) for signatures.
The very same set of functions are required for other operations such as key exchange. So, instead of duplicating everything for each class of algorithm, move everything to generic types that can be shared.
Creating one of these keys now just requires an algorithm family to provide some run-time type safety.
For signatures, we didn't had a secretkey type. This has been introduced.
This causes quite a lot of changes to the API but not to its actual mechanisms.
Aliases are defined at WITX level for the different operation types as a guidance to guest implementations.
As an example of another API using key pairs, a new key exchange namespace has been added, currently providing the simple Diffie-Hellman operation, to be extended with key encapsulation mechanisms.
Managed keys can also now be replaced.
Documentation has also been improved for symmetric operations.