rust-hpke icon indicating copy to clipboard operation
rust-hpke copied to clipboard

Usage of Ed25519 keys

Open shishkin opened this issue 10 months ago • 7 comments

As a disclaimer I'm not a cryptographer and barely try wrap my head around HPKE scheme.

I tried to use this library with ed25519-dalek keys in a base, single-shot seal scenario. It didn't work at first until I realized that HPKE needs x25519 keys for KEM. Dalek library provides conversion to x25519 keys with which HPKE works fine. However dalek warns that same keys should not be reused across different schemes. The linked paper suggests conditions under which ed25519 keys can be reused for for x25519-based KEM. The paper doesn't specifically mention HPKE, so I wonder if anyone with enough expertise can clarify if HPKE takes the risks mentioned by dalek into account.

shishkin avatar Feb 03 '25 15:02 shishkin

This is a totally valid question! The short answer is that this crate does not care where the public key comes from. It is pretty low level. So if someone decides that they’d like to re-use one public key for many purposes, they're free to do so.

As for specifically using an ed25519 key as an HPKE public key with X25519 as the underlying DHKEM: this has the same security properties as the things you linked.

Does this answer your question?

rozbb avatar Feb 03 '25 20:02 rozbb

Thanks for you reply. I re-read the linked paper but I'm still not able to map the language it uses to the HPKE parameters and thus can't properly assess its implications. So my question is more concretely: does HPKE algorithm by construction benefit from security proofs of Thormarker's paper? If not, how would I use HPKE to benefit, e.g. provide sufficiently random aad or not reuse info_str? Or would I need to some other form of key derivation from the ed25519 key?

shishkin avatar Feb 08 '25 15:02 shishkin

Does HPKE algorithm by construction benefit from security proofs of Thormarker's paper?

Yes, I believe so. The KEM defined in HPKE looks a lot like the one in the paper. That said, it is not considered good practice to reuse keys like this, and you probably shouldn't unless you have a very good reason.

rozbb avatar Feb 19 '25 06:02 rozbb

Thanks for your reply, however it makes things only more confusing to me. What is then a good practice to encrypt a message for a stable known ed25519 signing identity? Or what signing identity should be used instead to have a good encryption story?

shishkin avatar Feb 19 '25 07:02 shishkin

One should not encrypt to a signature public key. Rather, an entity with a signature public key should also expose a separate encryption public key. Each key should be used only for its specific purpose

rozbb avatar Feb 19 '25 07:02 rozbb

Thanks! One more question though... If this is general advice, does it invalidate PGP where entities only have one key pair for signing and encryption? If not, what is the deciding difference?

shishkin avatar Feb 19 '25 11:02 shishkin

PGP/GPG use separate keys for encryption and signing. Your master keypair is a signing key, and there is a subkey for encryption. Often there is also a separate signing subkey so the master signing key can be kept offline as much as possible.

tarcieri avatar Feb 19 '25 14:02 tarcieri