Document why the sender pub key is needed about bitcore-ecies HOT 11 CLOSED

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?

from bitcore-ecies.

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

from bitcore-ecies.

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?

from bitcore-ecies.

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

from bitcore-ecies.

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.

from bitcore-ecies.

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

from bitcore-ecies.

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

No, that's part of the ECIES standard.

from bitcore-ecies.

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.

from bitcore-ecies.

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: #25

from bitcore-ecies.

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.

from bitcore-ecies.

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

from bitcore-ecies.