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

Reply to this note

Please Login to reply.

Discussion

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

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

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.

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