Nostr Web Client

QUESTION:

In RSA, you can send an encrypted message to someone cold without any prior interaction, as long as you have their public key.

In elliptic curve cryptosystems, you cannot send somebody an encrypted message cold. In order to send someone an encrypted message you first have to both generate ephemeral keypairs and exchange them (and compute a shared secret with them). And these ephemeral keys must only be used once.

secp256k1 seems to have a way of sending encrypted messages cold (NIP-44) with a non-ephemeral shared point. I'm wondering

* Is this somehow special about secp256k1 that doesn't apply to ed25519? Or,

* Could you also do this in ed25519 but also suffer similar security consequences?

Reply to this note

Please Login to reply.

Discussion

Rijndael 1y ago

Check out ECIES

Mike Dilger ☑️ 1y ago

So the sender uses an ephemeral keypair but exchanges with the recipients long-term well-known public key?

Rijndael 1y ago

Yep. Usually

Dr. Hax 1y ago

In RSA, you can only encrypt an handful of bytes with the public key. I think the limit is 512 bytes for a 4096-bit RSA key. So what RSA encrypts is a symmetric key (e.g. AES-256), which is what encrypts your data.

My memory on ECC hasn't been burned into my brain as heavily, but I recall it being basically the same overall process, of encrypting a symmetric key, not the message.

A quick search shows that the encryption key and decryption key are the same, which confirms it's symmetric (by definition). https://cryptobook.nakov.com/asymmetric-key-ciphers/ecc-encryption-decryption

All thr ECC algorithms (ed25519, secp, etc) are going to be basically the same. It's just the curve that is changing.

Good luck with whatever you're working on.

Mike Dilger ☑️ 1y ago

Yep that was convenient how PGP did it, encrypting the symmetric key to each recipient in the header of the encrypted message. But ECC keys don't work like RSA keys and encryption has to be done with diffie-hellman key exchange to agree upon a shared secret which might then be used for XChaCha20Poly1305 or AES or whatever. And for some security reason you can't use that same shared secret twice (or so I am cautioned by the cyrpto libraries I'm reading the docs in).

nostr:npub1mxrssnzg8y9zjr6a9g6xqwhxfa23xlvmftluakxqatsrp6ez9gjssu0htc gave me a good lead.

Brunswick 1y ago

Are you saying this because you believe secp256k1 is only able to encrypt to the reciever and doesen't include a sender's message signing scheme? Generally EC algorithms only support either signing (e.g. ECDSA) or encryption (ECIES), whereas the RSA algo can do both. However I'm unclear if one can use the same keypair for two EC algorithms. IIRC secp256k1 is a curve associated with ECDSA, but I'm unclear if it's suitable for ECIES

Brunswick 1y ago

Update: it appears both of the curves you mention are suitable for both signing and encryption

Brunswick 1y ago

If you already know the receiver's public key, there's no need to "handshake" before sending the encrypted message, because at that point you only need to securely send the session key

Mike Dilger ☑️ 1y ago

You can use a curve for both signing and Diffie-Hellman key exchange. It is with the latter that you can construct encryption using ECIES. But Diffie-Hellman key exchange is constructed as an online back-and-forth thing. Alice needs Bob's ephemeral public key to compute the shared secret, and she needs the shared secret to encrypted data to Bob. But in many instances Bob isn't online and Alice is just sending him an encrypted DM, so she cannot get an ephemeral public key from him.

It is not safe to use your long term public keys to compute a shared secret. At least one side should be using an ephemeral keypair, and that is where I think it is ok to use Bob's long-term private key as long as Alice is using an ephemeral keypair.

And no this wasn't about secp256k1 in particular.

Mike Dilger ☑️ 1y ago

EDIT I meant Bob's long-term public key.