Support other types of derived keys

[sosthene-nitrokey]

Right now the derive_key mechanism implemented in #10 only allows deriving a secret 256 bit keys. It might be interesting to make the type of the key configurable.

The current implementation is already not that practical. In Opcard, the admin PIN can be used to change the GPG key, which can then be only used after verification of the user pin.
This means that the admin pin need to somehow be capable of encrypting the GPG key as if it had the user's pin. To do that, the opcard implementation wraps the user pin key using the admin pin key.

This works, but is not viable for PIV, or with secure messaging. In those context, no "admin pin" is used, and authentication happens through an AES encryption or challenge-response. This means that there is no way to derive entropy from the admin authentication which can be used to wrap the user pin key.

The solution I propose would be to allow other mechanisms to be used to derive the key that is obtained by get_pin_key. The main goal would be to support either x25519 or P256 keys that can be used to asymmetrically encrypt data. That way an authenticated admin could still wrap the keys in a way that can only be read by the user.

[sosthene-nitrokey]

I suggest going for X25519 keys.

I think we might want to think about how we go about this.  For trussed-auth, it's pretty easy to use the symmetric derived key to wrap/unwrap the key below, and return it as a normal asymmetric key stored on the filesystem.

Currently the trussed-auth implementation in the SE050 backend similarly unwraps the symmetric key, and the symmetric decryption is then performed in software. This is the only option since the SE050 does not support any AEAD cipher. But for X25519 it is possible to do just that. After key agreement however, the se050 backend will still need to perform decryption in software.

I believe it will be possible for the SE050 backend and the trussed-auth to deal with this optimally.