search

bitpay / bitcore-ecies

A module for bitcore that implements the Elliptic Curve Integrated Encryption Scheme (ECIES).
MIT License
58 stars 70 forks source link

Document why the sender pub key is needed #17

Closed Giszmo closed 9 years ago

Giszmo commented 9 years ago

I'm searching for a way to encrypt and sign messages with bitcoin keys. The sender pub key seams to do something like signing but I don't see a signature check or some ´throw Error(bad sig)´. Please elaborate.

Can signing (sender pub key) be left out?

Giszmo commented 9 years ago

To my understanding of https://en.wikipedia.org/wiki/Integrated_Encryption_Scheme the scheme implicitly signs the message as the pub key is used in the encryption? So to send data, a sender/second pub key is always needed?

eordano commented 9 years ago

This line does that check I think:

https://github.com/bitpay/bitcore-ecies/blob/master/lib/ECIES.js#L79

It's a problematic line, see #14

Giszmo commented 9 years ago

I don't understand enough to neither see how this is an explicit signature check and whether it could be left out, nor how a timing attack would be relevant here. As I would use it, the pubKeyA, pubKeyB and the encrypted message would be sent over an unsecure network while the pirvKeys never leave their respective machines. Any issue there, apart from attackers learning who is talking to whom?

maraoz commented 9 years ago

With ECIES you're not technically signing the messages with bitcoin keys. The bitcoin private key (ECDSA key) is used to derive an encryption and MAC key. See: https://github.com/bitpay/bitcore-ecies/blob/master/lib/ECIES.js#L39-50

kE is the CBC encryption key (secrecy), and kM is the MAC signing key (integrity). For more info, check: http://en.wikipedia.org/wiki/Integrated_Encryption_Scheme

Giszmo commented 9 years ago

Sorry for using this issue to educate myself. I guess, a library should describe, what it is for and what it is not for and I have serious doubts here, so if you could be so kind and enlighten me. I guess I'm fine but if not, people might be more angry at me than you for having to answer a noob question ;)

I studied math and know somewhat about crypto but the wiki article is not answering my doubts here.

I plan to have users share public keys among them for subsequent secure communication via a public message box. (If you know the recipient pub key, you can get his encrypted messages.)

I assumed this would at max reveal, who is talking but not the content. People scraping the inboxes might force me to require authentication but I don't see how the messages would be at risk.

As I wouldn't ask the recipient to try and decrypt messages and tell me asap if he succeeded, I neither see where a timing attack would be relevant in my scenario but as I clearly don't understand the details of ECIES, I might have missed something.

Thank you for your time.

maraoz commented 9 years ago

That sounds reasonable. You might want to check insight-api's mailbox plugin, which implement something similar, using ECIES encryption, and storage of messages. https://github.com/bitpay/insight-api/blob/master/plugins/mailbox.js

maraoz commented 9 years ago

To answer your original question: "Can signing (sender pub key) be left out?"

No, that's part of the ECIES standard.

Giszmo commented 9 years ago

Thank you @maraoz. I guess, this plugin does not run on the public api? As far as I understand, it does exactly what I wanted to do. I don't see ECIES being used there though. It's just buffering and broadcasting messages without auth or looking into stuff, right? I had planned that and was considering to add some nonce signing security, so it wasn't possible to download messages for others even if you know their receiving pub keys.

I will definitely consider using mailbox.js. We already use insight API, so it might be a good fit.

Also I would be fine with closing this issue.

braydonf commented 9 years ago

The sender's public key is included in DER format in the first 33 bytes of the encrypted buffer, thus it doesn't need to be specified prior to decrypting a message. This can be fixed with: https://github.com/bitpay/bitcore-ecies/pull/25

Giszmo commented 9 years ago

Sorry for reviving this issue but further discussion of my doubts brought up some rather harsh criticism of bitcore-ecies that I'm not qualified (yet) to comment on.

The quote is taken from this post:

I'll reply again and point out that the package you linked doesn't even provide meaningful ciphertext integrity: it doesn't include the IV in the MAC input. Do not use this library or anything by the same author. They don't know what they're doing.

You might want to comment if not here, then there. I have only the best impression of bitpay so far and assume you can put ctz99 right.

Giszmo commented 9 years ago

@maraoz and @braydonf any chance you could comment on this devastating comments about bitcore-ecies?