Bitcoin Forum

https://github.com/yann2192/pyelliptic

https://bitcointalk.org/index.php?topic=145098

Also look at bitgen:

http://bitcoin-gen.org/

The latest version supports public key encryption.

Regarding the security when using the public key for message encryption:

The security of the ECIES encryption is equally strong as the ECDSA that bitcoin use.

It is possible to estimate the strength of the encryption in monetary terms.

This is an address that contains 92 000 bitcoins:
https://blockchain.info/address/3A1KUd5H4hBEHk4bZB4C3hGgvuXuVX7p7t

The address is reused, money has been sent repeatedly from that address.
This means that the only thing that protects these 92 000 bitcoins is the Elliptic curve.
(When a message is signed the ECC public key is revealed)

The ECC is in this case able to protect 92 000 bitcoins.

If your encrypted data is worth less than 92 000 bitcoins it is safe.

This is simply untrue, and I believe I've corrected it elsewhere.  Please stop repeating it.

How do you compare the security of two algorithms that are entirely different? ECIES is encryption while ECDSA is a signature algorithm, two different things. Bitcoin doesn't use encryption at all.

If you have more information, I am interested in that.

The reasoning is simple: In order to break ECC, you would have to perform the "discrete logarithm"
in both cases, both for ECIES and ECDSA.

Use of ECIES also use conventional encryption such as AES which should also be cryptographically strong.
But the assumption is that the conventional crypto is sufficiently strong.

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

The elliptic curve is used to make the sender and the receiver agree on an encryption key.

From http://www.johannes-bauer.com/compsci/ecc/

================================
Performing encryption using ECIES is then relatively easy. Let's assume we want to encrypt data with the public key Q that we just generated.
Again, first choose a random number r so that
0 < r < n

Then, calculate the appropriate point R by multiplying r with the generator point of the curve:

R = r * G
Also multiply the secret random number r with the public key point of the recipient of the message:

S = r * Q
Now, R is publicly transmitted with the message and from the point S a symmetric key is derived with which the message is encrypted.
A HMAC will also be appended, but we'll skip that part here and just show the basic functionality.
================================

The only thing that is done with the elliptic curve is two multiplications.

The point S is used as a symmetric key, and is known by the sender and recipient but no one else.

The point R is transferred over a public network, seen by anyone.

The receiver can then compute S by using his private key.


Note the extreme simplicity in the scheme: Only EC multiplication is used.

I know its a technical discussion forum but my question is that if given bitmessage algo for text encryption is cryptografically safe?

It takes a while to go through all the code, I just had a quick look at the main encryption function.

You use ECIES with the curve sect283r1 for public key encryption and aes-256-cbc for the symmetric encryption.

It seems like you send iv directly over the network.
That should be ok, but giving an attacker as little information as possible is a good thing,
so another possibility is to compute the iv from the shared secret, as is done in the Electrum ECIES.
But that is probably not a problem.

Here is the encrypt function:

==============================
    @staticmethod
    def raw_encrypt(data, pubkey_x, pubkey_y, curve='sect283r1',
                    ephemcurve=None, ciphername='aes-256-cbc'):
        if ephemcurve is None:
            ephemcurve = curve
        ephem = ECC(curve=ephemcurve)
        key = sha512(ephem.raw_get_ecdh_key(pubkey_x, pubkey_y)).digest()
        key_e, key_m = key[:32], key[32:]
        pubkey = ephem.get_pubkey()
        iv = Cipher.gen_IV(ciphername)
        ctx = Cipher(key_e, iv, 1, ciphername)
        ciphertext = iv + pubkey + ctx.ciphering(data)
        mac = hmac_sha256(key_m, ciphertext)
        return ciphertext + mac
==============================

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.

Message encryption is important for maintaining security and privacy.
But securing it with your private public key is still not that secure I guess.
First, your key is too long, and its almost impossible to remember it, you'll have to write it somewhere, in which you have danger of getting stolen and ultimately getting thefted.
Secondly, hackers are getting more and more intelligent and it's obvious that they have developed more ways of knowing your private public key. And any hacker who will try to get into your messages will try your key as password first.
So, its secure.. But more insecure.

Actually the basic though is for making zeronets encrypted messaging

https://www.reddit.com/r/crypto/comments/3t6vnm/need_guidelines_for_ecc_based_messaging/

Guidelines needed

Thanks!

Earlier discussion here: https://bitcointalk.org/index.php?topic=128230.msg1621711#msg1621711 and https://bitmessage.org/forum/index.php?topic=4170.0

It all boils down to: Using the same key for signing and encryption seems to work in theory but might cause security issues in practical use. At the very least it is even more difficult to get right so better avoid it.