Can I use elliptic curve DSA in a secure message service?

I'm looking to design a system that allows a user of a crypto-coin such as Bitcoin to both have an online wallet and to be able to send and receive encrypted emails in the same system.

The relevant portion concerning Bitcoin is that for a user's address, such `31uEbMgunupShBVTewXjtqbBv5MndwfXhb`, is a hash of the user's public key. The keypair is a ECDSA public-private key pair.

If I am a user, could I use this key pair for both Bitcoin transactions and for sending and receiving encrypted emails? Besides the given that using a key pair for both things may be unwise, are there any additional pitfalls I should be aware of?

Edit: I'm looking to use a system such as OpenPGP, not S/MIME. To be more specific, I'm attempting to see if it's possible to use the key pair generated by a Bitcoin or Litecoin derivative, which is a ECDSA key pair, in an email like system so that users of this email system can use and exchange key pairs with other, non-system users such as those using GnuPG.

• If you're asking this question, then you shouldn't be designing this software. Commented Mar 25, 2014 at 17:28
• related: Using same keypair for Diffie-Hellman and signing on crypto.se. Commented Mar 25, 2014 at 18:27
• @tylerl Some of us learn best by designing systems and then learning why they're broken. If people shouldn't ask questions about things they don't already understand, then they'd never learn. Commented Mar 25, 2014 at 19:33
• @BrendanLong Sure. Feel free to build anything you want. Just don't let it out into the world if it can hurt people. Commented Mar 25, 2014 at 19:38

ECDSA is a signature algorithm. The private key for ECDSA is an integer x between 1 and n-1, where n is the size of (the subgroup of) the used elliptic curve (normally a prime number). The public key is a curve point Q equal to xG, where G is a conventional fixed point on the curve.

You cannot use a signature algorithm for anything else than signing, of course, but it so happens that there is a key exchange algorithm called ECDH which uses public/private key pairs with exactly the same format. In that sense, it is technically feasible to use the same key for ECDSA and ECDH. Key exchange can be used for asymmetric encryption through hybrid encryption (you use the exchanged secret as basis for symmetric encryption); in the case of ECDH, this process has even be standardized under the name ECIES.

However, using the same key pair for signature and encryption is not a very good idea. This is frowned upon by many cryptographers and standards; it is a capital offence in the world of risk analysis and certifications. There are two main reasons for that:

• Signature and encryption keys have distinct life cycles and call for distinct, incompatible management methods. In particular, you usually want to have a backup or escrow of your encryption private key, and you certainly do not want such a backup or escrow for your signature private key. See this answer for a discussion.

• Interactions between different cryptographic algorithms have not been thoroughly analysed. We do not really know whether using the same private key for both ECDH and ECDSA may put either at risk (e.g. allowing an attacker to forge a fake signature by engaging in some ECDH with you, with niftily crafted DH messages, or something like that). Remember that any given cryptographic algorithm can be deemed secure only because it has sustained scrutiny from many cryptographers for several years; interactions between ECDH and ECDSA cannot boast such an amount of review.

When in doubt, abstain. And, in this case, you should doubt. Really.

• The paper "On the Joint Security of Encryption and Signature in EMV" claims to prove that there are no dangerous interactions. But I have some doubts about the quality of the proof. Commented Mar 25, 2014 at 18:29
• Since I've asked the question I've realized that it kind of doesn't make sense, and your link to the signature vs encryption key answer was also helpful in understanding the difference. Thanks!
– josh
Commented Mar 26, 2014 at 5:05

ECDSA cannot be used for encryption purposes. ECDSA is the elliptic curve implementation of the digital signature algorithm and, thus, can only be used for digital signing purposes.

Encrypted email utilize S/MIME usually, which allows the sender of the email to generate an symmetric encryption key and uses it to encrypt the email message. Using the public key of each recipient, the symmetric key is encrypted. The encrypted mail and encrypted key for each recipient is packaged together and sent as an email. Each recipient will be able to decrypt the symmetric key with their private key and, thus, read the decrypted email message.

Using S/MIME you can also created digitally signed emails. The email message is hashed and that hash is encrypted. Sender bundles the message, encrypted hash and digital certificate (if these are being used) into an S/MIME message and sends in an email. The recipient can read the message and recreated the hash from the message. They can also decrypt the encrypted hash with the public key (in the certificate) and compare the two hashes.

In order to implement this type of mechanism you will need to use an asymmetric algorithm which supports encryption. The most obvious choice is RSA.

There is no reason why you cannot use RSA for a new crypto-coin implementation and secure email. RSA can be used for digital signing and encryption. PKI best practice would be to utilize two different key pairs for the different purposes, but you will not be signing certificates.

As bitcoin utilizes ECDSA as its public key crypto-system, you are restricted to digital signing only. Currently most crypto-currencies are based on the bitcoin method, so if you wanted to implement a new one using RSA, you'd be doing it from scratch!

• I'm talking about using a system such as PGP, not using `S/MIME`. OpenPGP supports ECDSA according to this mailing list thread.
– josh
Commented Mar 24, 2014 at 5:51
• OK. That's cool. The you are better off combining the signing and encryption and using ECDH for key agreement with ECDSA used for authentication. For signing you bundle your public key into the message and for encryption you'll need the recipient's public key. Using the GPG implementation that supports ECC you should be able to get it working. Commented Mar 24, 2014 at 6:09
• +1 for the simple breakdown, summary and contrast.
– Lex
Commented Mar 24, 2014 at 14:58

If you want to use ECC-based crypto, then you're looking for ECIES, although I'm unsure if using the same key for encryption and signing is a smart idea.

Information on ECIES can be found here, and there are examples of how to use this in the Bouncy Castle source code.

You can't use "31uEbMgunupShBVTewXjtqbBv5MndwfXhb" with any encryption scheme, because that is just the hash of a public key, and using the hash of a key doesn't allow you to encrypt messages using it.

In Bitcoin the private key is in fact 256 bit random number. You could use this as the private key and create a shared secret using ECDH. The shared can be used to encrypt the message data for example using AES.

Elliptic curve Diffie–Hellman (ECDH) is an anonymous key agreement protocol that allows two parties, each having an elliptic curve public–private key pair, to establish a shared secret over an insecure channel.

• You basically just described ECIES (see prior answer) Commented Dec 24, 2018 at 19:27