1
$\begingroup$

A bitcoin address is created from an ECDSA keypair. It is common to use use a hashed version of the public key as the shared address, but the original bitcoin implementation also allowed for using the unaltered key directly. (which anyway is revealed when the coins in the address is spent) The purpose of public key cryptography here is that the owner can prove ownership of the address by a digital signature, which is required by the blockchain before accepting spending of the coins in an address.

The ECDSA algorithm is not suited for encrypting messages. If an RSA keypair was used it would allow the sender of money to encrypt and convey some personal information to the receiver (eg. by a public message server), which obviously could be a useful feature. Is there any reason why an RSA keypair should or could not be used for cryptocurrency addresses?

$\endgroup$
  • $\begingroup$ It's clear from the answers that the RSA is not feasible due to key size. But if a lower security can be tolerated for the messaging part, would that make it easier to suggest a more suitable choice of algortihm? $\endgroup$ – Svein May 24 '18 at 22:53
  • $\begingroup$ Maybe an algorithm like XEd25519, which provides higher security for signature and key agreement than RSA-2048 already? $\endgroup$ – Squeamish Ossifrage May 25 '18 at 3:32
3
$\begingroup$

In theory you could, but ECC is better suited for crypto-currencies.

RSA keys are big, you need at least a 2048-bit modulus compared to the 256-bit ECC keys bitcoin uses. Blockchains really care about space consumption. (There are some techniques to reduce the effective public key size for RSA, to about 1/3 IIRC, but I haven't seen them used anywhere. And it'd still be much larger than the ECC equivalent)

You can use an ECDSA keypair for ECIES style encryption

Though this kind of key reuse is somewhat discouraged, regardless if it's ECC or RSA.

$\endgroup$
3
$\begingroup$

You could do this, but you'd have to replace 32-byte public keys by 256-byte public keys and 64-byte signatures by >=256-byte signatures in the storage format, assuming you used 2048-bit RSA moduli. There are techniques for compressing RSA signatures, but I've never heard of anyone implementing them, so you might be on your own to write the code, and they won't beat 32-byte keys and 64-byte signatures at a remotely comparable security level. And, unlike ECDSA, RSA key generation is sloooooooooooooooooow.

Alternatively, you could use a Schnorr-style signature scheme, such as Ed25519, with size and computational cost comparable to the ECDSA over secp256k1 as used by Bitcoin, and then reuse the key pairs for ECDH/ECIES, like XEdDSA does. There is no shortage of ways to shoot yourself in the foot designing and implementing a bespoke cryptosystem, but the combination of EC-Schnorr and ECDH with the same key pairs does not necessarily seem to hurt security in itself.

(Whether you can do this with ECDSA, I leave this as an exercise for the reader to study. I'm not aware of literature on it; if you find any, please answer fgrieu's question on the subject! But your time is probably better spent just using XEd25519 than fussing with ECDSA.)

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.