Quote from: prezbo on November 15, 2015, 11:12:14 AM

Quote from: bit22gen on November 15, 2015, 12:22:52 AM

The message encryption is not done by the elliptic curve when using ECIES,
conventional encryption such as AES is used for message encryption.

This is probably what gmaxwell is referring to. If AES is broken so is ECIES. In other words, the security of ECIES is dependent on the security of EC discrete logarithm problem as well as AES.

Right, also secure as the message hash; the cryptographic assumptions are stronger: all of AES, the HMAC, and the discrete log must upload their security properties. Also as secure as the ECIES implementation (which has been widely implemented incorrectly in the past; e.g. electrum once shipped a broken 'ecies').

The way ECC is used for ECIES is also very different than the way ECC is used for signing; and so it has different avenues for implementation vulnerabilities.

For ECIES, the decrypting side does a variable base multiply with their secret and a point specified by the attacker (As opposed to the fixed base multiply with a secret generated by the signer, in signing). This means that its more vulnerable to various implementation flaw and side-channel attacks. For example, if an implementation doesn't verify the curve equation, and will print out error-ed decryptions (or any distinguisher between a small number of possible wrong decryptions) I can send in ephemeral keys which are not on the curve but are instead in a small subgroup, and with a small number of queries recover your private key. No analogous attack can exist for signing. Now, it's stupid for an implementation to have this kind of bug (not checking curve membership), but many real ones produced by professional have had it (including things like the Java ECC code); and especially around the bitcoin space we see a _lot_ of ECC code written by single authors as their first cryptography project being published for third party use without any meaningful peer review.

I bet that most people reading this would be surprised to learn that given a minor buggy decryption implementation if I can learn a few bits from a relatively small number of failed decryptions with select bad ephemeral keys that I could recover the private key... and because of that many people won't think to avoid having those kinds of implementation bugs or avoid leaking any information about the session key in the case of failure.

Beyond that, just ECIES alone doesn't result in good encryption software. What happens when the message is bigger than comfortably fits in ram? Applying a HMAC naively results in having to decrypt the whole thing in ram before you can output any of it. yadda yadda,

Finally, no matter how expert the construction of the cryptosystem or it's implementation mistakes are made, new things are discovered. One could instead keep your bitcoin keys for bitcoins, and sign a separate public key if you want to show that things are related. Doing so is strictly safer, also happens to not hurt bitcoin fungibility (by forcing people into reusing addresses), and leaves you with the option to use widely reviewed cryptographic tools for message encryption that were specifically designed for that purpose.