Bitcoin Forum
May 02, 2024, 02:30:36 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Encrypting Messages to Bitcoin Addresses  (Read 1523 times)
arbarian (OP)
Newbie
*
Offline Offline

Activity: 4
Merit: 0


View Profile
December 22, 2014, 05:27:01 AM
 #1

Hi all,

I've written this python library that encrypts messages for a particular Bitcoin public key from a particular public key.  The message content is provably from the sender's Bitcoin address.  It is also hidden as ciphertext en route.  Only the recipient Bitcoin address can decrypt the contents.

Here's how it works.

a secret shared key between sender and receiver is created in the following way:

  - the sender scrapes the Blockchain (or some other source) for the recipient's public key.  Any transaction signed with pay_to_pubkey hash reveals the address's public key.  I wrote a small utility that scrapes this key, if available from transaction scripts, using the Blockchain.info API (although any other source would suffice).

 - Using the recipient's public key, the sender multiplies that point on the elliptic curve by his private key (ie the integer it represents).  A new point is created.

 - The new created point's coordinates map to a 32 byte string that is the shared secret key.

 - Meanwhile the sender broadcasts his public key as part of the encrypted message.  The recipient uses his private key to mulitply by the public point of the sender.  He should arrive at the same point calculated by the sender.  This maps again to the shared secret key.

Then I use AES-CBC to symmetrically encrypt the message contents using the shared secret key.

Finally, a timestamp is included in the encrypted message.  Received messages are only valid within X seconds of their creation by the sender.  This is a simple method to limit reply attacks to a brief window. 

This was my first foray into crypto, so I'd appreciate feedback and corrections.  Don't use this library as a finished product, as it has not been reviewed.  There could well be glaring errors I've missed.  I'm not a professional cryptographer so... take it with a grain of salt.


1714660236
Hero Member
*
Offline Offline

Posts: 1714660236

View Profile Personal Message (Offline)

Ignore
1714660236
Reply with quote  #2

1714660236
Report to moderator
1714660236
Hero Member
*
Offline Offline

Posts: 1714660236

View Profile Personal Message (Offline)

Ignore
1714660236
Reply with quote  #2

1714660236
Report to moderator
1714660236
Hero Member
*
Offline Offline

Posts: 1714660236

View Profile Personal Message (Offline)

Ignore
1714660236
Reply with quote  #2

1714660236
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714660236
Hero Member
*
Offline Offline

Posts: 1714660236

View Profile Personal Message (Offline)

Ignore
1714660236
Reply with quote  #2

1714660236
Report to moderator
hhanh00
Sr. Member
****
Offline Offline

Activity: 467
Merit: 266


View Profile
December 22, 2014, 07:04:17 AM
 #2

It's not safe to do this, you'd better use EC IES. First of all, there is no reason to use your private key. Secondly, AES CBC is not authenticated encryption and subject to chosen ciphertext attacks.

hashman
Legendary
*
Offline Offline

Activity: 1264
Merit: 1008


View Profile
December 22, 2014, 08:32:58 AM
 #3

I think there is a need for this kind of encryption.  It also adds a layer of authentication, assuming that you somehow know an address is associated with an individual.   

Why can't you use ECC instead of AES?  Keypairs are already held by participants, shouldn't we be able to leverage this? 
RiverBoatBTC
Full Member
***
Offline Offline

Activity: 224
Merit: 100


View Profile WWW
December 22, 2014, 08:35:50 AM
 #4

Never roll your own crypto no matter how convenient.

sed
Hero Member
*****
Offline Offline

Activity: 532
Merit: 500


View Profile
December 22, 2014, 08:50:15 AM
 #5

Never roll your own crypto no matter how convenient.

Wait a minute, I support fully what OP is doing here.  He seems to be taking an opportunity to dig into the technology and learn about it.  Rolling your own __ is the best way to learn about __, imo.  Of course, if you're new, you need to be careful, but that's what OP seems to be doing. 

I wish I was savvy enough to comment on the particulars of this method/library, but alas...
RiverBoatBTC
Full Member
***
Offline Offline

Activity: 224
Merit: 100


View Profile WWW
December 22, 2014, 09:09:02 AM
 #6

Never roll your own crypto no matter how convenient.

Wait a minute, I support fully what OP is doing here.  He seems to be taking an opportunity to dig into the technology and learn about it.  Rolling your own __ is the best way to learn about __, imo.  Of course, if you're new, you need to be careful, but that's what OP seems to be doing. 

I wish I was savvy enough to comment on the particulars of this method/library, but alas...

For learning, yes, but it's easy to introduce a bug into crypto take a look at what happened to blockchain.info. So you shouldn't use stuff you wrote yourself for important purposes unless it's been analyzed and tested by millions of people.

sed
Hero Member
*****
Offline Offline

Activity: 532
Merit: 500


View Profile
December 22, 2014, 07:55:25 PM
 #7

I think the OP pretty specifically warns about just that---that this is an experimental, untested library that shouldn't be used for high-stakes purposes.
tacotime
Legendary
*
Offline Offline

Activity: 1484
Merit: 1005



View Profile
December 22, 2014, 10:55:28 PM
 #8

You can already do this with BitMessage I believe -- it uses secp256k1 for signing and symmetric cipher key exchange.

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
bcearl
Full Member
***
Offline Offline

Activity: 168
Merit: 103



View Profile
December 23, 2014, 02:49:57 PM
 #9

You just use ElGamal with elliptic curves. Classic ElGamal has been used by GPG for decades now.

Misspelling protects against dictionary attacks NOT
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!