Topic: Encrypt/Decrypt arbitrary text using bitcoin keys? (Read 5089 times)

As it turns out, yes.

https://bitcointalksearch.org/topic/announce-bitmessage-p2p-messaging-system-based-partially-on-bitcoin-128230 (PyBitmessage)

https://bitcointalksearch.org/topic/encryptdecrypt-arbitrary-text-using-bitcoin-keys-145098 (three lines python script using PyBitmessage libs)

Has anybody given some more thought to this?

So I misread the specification originally: NIST and SECG actually make no reference to encryption/decryption or signing/verification in their specification:

"NIST Recommended Elliptic Curves for Government Use"
http://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf

and

"SEC 2: Recommended Elliptic Curve Domain Parameters"
http://www.secg.org/collateral/sec2_final.pdf  (secp256k1 defined here)

They simply recommend elliptic curves and provide the associated parameters needed for implementation.  These curves can be used with any EC-based algorithms, including ECDSA and ECIES.

Elliptic Curve DSA and Elliptic Curve encryption are almost as closely related to one another as signing and encryption in RSA.  

   RSA Signing and Decryption:        both are exponentiation mod N with the private key
   RSA Verification and Encryption:   both are exponentiation mod N with the public key

In ECDSA and ECIES, the key-pair relationship is similar, but instead of simple exponentiation mod N, you're applying a different mathematical equation for all four operations (signing, verification, encrypting, decrypting).  The only real difference is that NIST has blessed different elliptic curves for ECDSA and ECIES.  That doesn't meant that the secp256k1 curve can't be used for encryption, it just means that people smarter than us have decided that different curves should be used for cryptography and signing.  

Unfortunately, in my graduate cryptography class, we didn't dive into elliptic curves far enough for me to know what kinds of vulnerabilities there are with naive elliptic curve selection, but there was also no reason why security of the two would be different on the same curve.  I would say that the security of ECDSA keys on the secp256k1 curve will provide sufficient security for encryption as well.  I wouldn't guard nuclear launch codes with it, but I would venture that your 256-bit key will give you at least 128-bits of security.

A more-likely explanation is that the security is actually identical between the two.  But it's standard practice in cryptographic protocols/implementations to use different keys for signing and encryption.  Perhaps this is why NIST chose two different curves:  so that if you decide to use NIST curves, you can't pick the same key for both, even if you wanted to.

But as has been said before:  you don't have the person's public key until they either give it to you, or you see a transaction signed with it.  Having their BTC address is not enough.

-Eto

Also, if people flag addresses with their public key, they can receive encrypted messages with addresses that have appeared in the network just as outputs.

But he can add encrypted notes for addresses that have already sent some bitcoins, right?
Aren't public addresses on the inputs of a transaction?

yes it will do! as long as both algorithms are using the same curve parameters, it should work fine.

but then again: bitcoin does not use public keys as addresses, it use hashes of public keys.
which means it will not work. of course you could grab it, if the address has been used before.

There is an algorithm very similar to ECDSA that performs encryption, ECIES. The algorithm is explained here:
http://en.wikipedia.org/wiki/Integrated_Encryption_Scheme
I'm 95% sure ECIES can work with keys generated for ECDSA.

(This is, by the way, a somewhat surprising thing. It is definitely not true that because the keys can be used for signing they can obviously be used for secure encryption. It is not like RSA where signing and encrypting are almost the same operation. It just so happens that someone found a clever way to make it work.)

not true!
and the ECDSA algorithm can only be used as signing, it is not that insecure if you are encrypting with it. you just simply can't.
its like eating soup with a fork.

and *even if* you could encrypt something with it, it may mot be secure anyway, even if it is secure for signing.

you'll have to elaborate, as i really am new to cryptography and hashing.

Why not just use the BTC Address as a salt?

thanks for that.

i think i'll just get back to providing the 'public note' functionality and come back to this with a clearer head later

maybe once the public version is up and running it'll be easier to think up good ways to allow private notes.

The bitcoin client sends it to the address. You later prove you own that address by providing the public key and the signature. The transaction is verified by proving that the public key is the one corresponding to the address and the corresponding private key was used to generate the signature. The mapping from public key to address is one-way and cannot be reversed.

So:

1) You generate a private key randomly.

2) You calculate the corresponding public key for that private key.

3) You calculate the corresponding address for that public key with a hashing function.

4) You publish the address.

5) People send coins to the address.

6) You claim the money by providing the public key and the signature (both of which you can generate from the private key, just as you did in steps 2 and 3).

7) Clients verify that the public key you provided in 6 is for the address just as you did in step 3. Then they verify the signature with the public key. If you pass these two checks, you have claimed the coins.

sorry i don't get it.

say i want someone to pay me at a new address... 15bghCkDhPTs3QamEotH7kGuAQAtNHv3rM

if i'm not publishing my public key anywhere, and it can't be derived from that 'hash' known as an address, then how does YOUR bitcoin client send me coins?

When you execute a transaction, you are actually passing two tests:
(1) You provide a public key that, when hashed, matches the address that the previous coins were sent to
(2) The transaction is signed with the private key associated with the public key from part (1)

Up until the first time you sign a transaction, no one actually knows your private or your public key.  Of course they never get your private key, but they don't know the public key, either.  The interesting part about this is that even if someone knew a vulnerability in the ECDSA algorithm, they can't even begin applying it until they see your first transaction -- because they don't have your public key until that point.  And, if you always use a new address for every transaction, then the first and only time they see your public key is after you have transferred the coins to a new address. 

I don't know if this was an intentional "feature" of BTC, but it's pretty cool.  Even if ECDSA was broken, the network could probably still function, as long as it takes longer than one block to break a private key once you have the public key -- by the time they break the key, the transaction is already in the blockchain.

in that case, how does the bitcoin client send people coins, using only their bitcoin address? ...doesn't it need to have the public key in order to send coins?

This does open some interesting social engineering attacks. Alice should be really careful as to what she is signing, because if it is somehow a valid transaction she could accidentally give away all her coins :-)

As Will said, this is not as easy as it sounds.  A user's BTC address is not their public key, but the hash of their public key.  The only way to know their public key is if they have ever sent coins from that address before, because that's the only time their actual pubkey enters the network.  So you have to search the blockchain for any transaction they've ever signed with their key.  However, since their client permanently saves all their keys, there's no reason it couldn't be used, even if they only used it once.

As for the encryption aspect... I don't see why the ECDSA signature keys can't be used as encryption keys.  The BTC ECDSA is based on a NIST-blessed elliptic curve (secp256k1), and you have a public-key-point and private-key on that curve.  If it's secure for signing, it will be at least very secure for encryption. 

Despite being a mathematician and studied cryptography before, I'm not a black-hat kind of guy.  I know that this will be very secure, but I don't know if there's maybe weaknesses in using a recommende ECDSA curve for encryption.  I just know it's possible to use it, and the security of the signature process implies a high degree of security in the encryption process.

-Eto

the bitcoin address is also a hash of the public key, so you would have to obtain the actual public key by either getting it from the user, or searching the blockchain for the corresponding key, if you wanted to do any cryptographic operations using it.

Will

okay, well i would love to find out more about this... and i'll say why i'm so keen...

...I'm working on a new site which is basically going to be an online commenting/labeling service for bitcoin addresses/transactions/blocks.

I have the domain already set up (http://bitnot.es) and will have the very basics uploaded within 24 hours.

The first version of the site will only allow fully public notes (i.e. if you put a comment up there, anyone will be able to view it).

example: http://bitnot.es/a/13QTW27b3SgqrEjefB9PbiZ6hcrVCJAxfx should display a note that says "This is the donation address for PayB.TC".

What i'd like to do tho if possible in the future, is allow people to make notes only viewable to the person who holds the private key of an address.

don't know much about encryption programming yet, only know the basics of public key crypto from wikipedia and I definitely have no knowledge of 'ecdsa' yet.