|
payb.tc (OP)
|
 |
August 06, 2011, 01:20:33 PM |
|
been trying to find details on how to do this for a couple of hours, but am not having luck with my searches...
Is it possible to encrypt any arbitrary string eg. "secret message for bob" using bob's bitcoin address (which is basically a public key, right?), and then have only bob be able to decrypt and read that text using his corresponding private key (which should be in his wallet.dat for example)?
How would you do this?
|
|
|
|
|
|
|
|
The forum strives to allow free discussion of any ideas. All policies are built around this principle. This doesn't mean you can post garbage, though: posts should actually contain ideas, and these ideas should be argued reasonably.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
|
|
|
Furyan
|
|
August 06, 2011, 01:27:22 PM |
|
been trying to find details on how to do this for a couple of hours, but am not having luck with my searches...
Is it possible to encrypt any arbitrary string eg. "secret message for bob" using bob's bitcoin address (which is basically a public key, right?), and then have only bob be able to decrypt and read that text using his corresponding private key (which should be in his wallet.dat for example)?
How would you do this?
This would actually be really cool and shouldn't actually be too hard to implement. |
|
|
|
|
|
martin
|
|
August 06, 2011, 01:33:16 PM |
|
The encryption algorithm used in bitcoin is ECDSA which does not encrypt text, it's just a signature algorithm. So, Alice could sign some text with her bitcoin address and Bob would know that it came from her (which would be a rather useful thing to be able to do with transactions). |
|
|
|
|
|
payb.tc (OP)
|
|
August 06, 2011, 01:56:32 PM
Last edit: August 07, 2011, 03:48:46 PM by payb.tc |
|
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. |
|
|
|
|
|
willphase
|
|
August 06, 2011, 04:26:38 PM |
|
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
|
|
|
|
etotheipi
Legendary
 Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
August 06, 2011, 04:47:29 PM |
|
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
|
|
|
|
|
wumpus
|
|
August 07, 2011, 01:43:35 AM |
|
So, Alice could sign some text with her bitcoin address and Bob would know that it came from her (which would be a rather useful thing to be able to do with transactions).
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 :-) |
Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through File → Backup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts. |
|
|
|
payb.tc (OP)
|
|
August 07, 2011, 02:17:07 AM |
|
A user's BTC address is not their public key, but the hash of their public key. 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? |
|
|
|
|
etotheipi
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
August 07, 2011, 02:42:10 AM |
|
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.
|
|
|
|
|
payb.tc (OP)
|
|
August 07, 2011, 03:09:22 AM |
|
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?
|
|
|
|
|
JoelKatz
Legendary
Offline
Activity: 1596
Merit: 1012
Democracy is vulnerable to a 51% attack.
|
|
August 07, 2011, 03:14:10 AM |
|
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?
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. |
I am an employee of Ripple. Follow me on Twitter @JoelKatz
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
|
|
|
|
payb.tc (OP)
|
|
August 07, 2011, 03:23:39 AM |
|
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?
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. 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. |
|
|
|
|
|
NothinG
|
|
August 07, 2011, 04:26:13 AM |
|
Why not just use the BTC Address as a salt?
|
|
|
|
|
payb.tc (OP)
|
|
August 07, 2011, 03:50:31 PM |
|
Why not just use the BTC Address as a salt?
you'll have to elaborate, as i really am new to cryptography and hashing. |
|
|
|
|
kokjo
Legendary
Offline
Activity: 1050
Merit: 1000
You are WRONG!
|
|
August 07, 2011, 04:05:04 PM |
|
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.
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. |
"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
|
|
|
JoelKatz
Legendary
Offline
Activity: 1596
Merit: 1012
Democracy is vulnerable to a 51% attack.
|
|
August 07, 2011, 04:54:34 PM |
|
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.
There is an algorithm very similar to ECDSA that performs encryption, ECIES. The algorithm is explained here: http://en.wikipedia.org/wiki/Integrated_Encryption_SchemeI'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.) |
I am an employee of Ripple. Follow me on Twitter @JoelKatz
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
|
|
|
kokjo
Legendary
Offline
Activity: 1050
Merit: 1000
You are WRONG!
|
|
August 07, 2011, 05:12:15 PM |
|
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.
There is an algorithm very similar to ECDSA that performs encryption, ECIES. The algorithm is explained here: http://en.wikipedia.org/wiki/Integrated_Encryption_SchemeI'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.) 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. |
"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
|
|
|
jtimon
Legendary
Offline
Activity: 1372
Merit: 1002
|
|
August 07, 2011, 09:11:01 PM |
|
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.
There is an algorithm very similar to ECDSA that performs encryption, ECIES. The algorithm is explained here: http://en.wikipedia.org/wiki/Integrated_Encryption_SchemeI'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.) 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. 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? |
|
|
|
jtimon
Legendary
Offline
Activity: 1372
Merit: 1002
|
|
August 07, 2011, 09:42:39 PM |
|
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.
|
|
|
|
etotheipi
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
August 07, 2011, 11:06:29 PM |
|
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
|
|
|
|
|
