[ANN] CoinMessage: Secure Messaging with Bitcoin Addresses

[Luke-Jr]

Addresses aren't identities.

Let's not get pedantic. An address is something that can be used to identify an account, which could be used as an identity. That's how social security numbers, driver's licenses and the like work.

No.
An address does not identify an account.

Side note: social security numbers are also not to be used for identity purposes.

Of course an address identifies an account. That's what the whole blockchain is, a list of accounts and who owns what.

If you're just going to troll, I'd rather you not do this on this thread.

No, perhaps you should learn how bitcoin works before trying to extend it with functionality that mostly already exists anyway... sigh

[andytoshi]

Of course an address identifies an account. That's what the whole blockchain is, a list of accounts and who owns what.

If you're just going to troll, I'd rather you not do this on this thread.

http://download.wpsoftware.net/bitcoin/bitcoin-faq.pdf

Also accusing Luke-Jr of trolling is quite rich..

[altoz]

Of course an address identifies an account. That's what the whole blockchain is, a list of accounts and who owns what.

If you're just going to troll, I'd rather you not do this on this thread.

http://download.wpsoftware.net/bitcoin/bitcoin-faq.pdf

Also accusing Luke-Jr of trolling is quite rich..

A user that just got out of newbie jail calling me anything is quite rich. One may suspect this could be Luke-Jr sock puppet.

[phelix]

The point of them using secp256k1 was so that people could use the same keys from bitcoin.

This is a useful thing? How?

Not sure, you'd have to ask them, but I'd imagine it's because your identity is the same in both blockchains and some applications that use both can be made.

Bitmessage keys are only used for encryption, not for signing. I tried talking atheros into it but to no avail 

Btw:Bitmessage does not have a blockchain.


IMHO the point is: Getting encryption right is difficult so don't complicate things any more than absolutely necessary.

[chriswilmer]

Of course an address identifies an account. That's what the whole blockchain is, a list of accounts and who owns what.

If you're just going to troll, I'd rather you not do this on this thread.

http://download.wpsoftware.net/bitcoin/bitcoin-faq.pdf

Also accusing Luke-Jr of trolling is quite rich..

A user that just got out of newbie jail calling me anything is quite rich. One may suspect this could be Luke-Jr sock puppet.

altoz, I think your idea is great, and in general I am very supportive of developers and trying out new projects (even if they don't end up taking off for whatever reason)

I think luke-jr is being unnecessarily mean... I wouldn't take it personally

[altoz]

Bitmessage keys are only used for encryption, not for signing. I tried talking atheros into it but to no avail 

Btw:Bitmessage does not have a blockchain.


IMHO the point is: Getting encryption right is difficult so don't complicate things any more than absolutely necessary.

Interesting, I didn't know they don't have a blockchain. Isn't there some large block of data that stores the encrypted messages there in some way, though?

I guess what I'm asking is, my project seems about as secure as bitmessage, just from what we're both doing with the secp256k1 curve. So if coinmessage is not considered secure, can bitmessage? If not, what am I missing?

[altoz]

altoz, I think your idea is great, and in general I am very supportive of developers and trying out new projects (even if they don't end up taking off for whatever reason)

I think luke-jr is being unnecessarily mean... I wouldn't take it personally

Thanks for the support. Thanks to the pointless exchange with Luke-Jr, I discovered what the "ignore" button is for!

Have you had a chance to look at the message I sent you?

[chriswilmer]

altoz, I think your idea is great, and in general I am very supportive of developers and trying out new projects (even if they don't end up taking off for whatever reason)

I think luke-jr is being unnecessarily mean... I wouldn't take it personally

Thanks for the support. Thanks to the pointless exchange with Luke-Jr, I discovered what the "ignore" button is for!

Have you had a chance to look at the message I sent you?

Works like a charm! Cool!

Thanks chriswilmer, for trying out coinmessage! Let me know if you have any suggestions to improve this library or to get others to incorporate it into their products. ~Jimmy

[chriswilmer]

I'm a big fan of Bitmessage too... I haven't followed up on the latest developments. It seems like there is certainly a need for an easy-to-use, decentralized, encrypted messaging service. Last I heard the jury was still out on whether Bitmessage was really scalable.

[altoz]

Works like a charm! Cool!

Thanks chriswilmer, for trying out coinmessage! Let me know if you have any suggestions to improve this library or to get others to incorporate it into their products. ~Jimmy

Awesome! Thanks for trying this!

[phelix]

Bitmessage keys are only used for encryption, not for signing. I tried talking atheros into it but to no avail 

Btw:Bitmessage does not have a blockchain.


IMHO the point is: Getting encryption right is difficult so don't complicate things any more than absolutely necessary.

Interesting, I didn't know they don't have a blockchain. Isn't there some large block of data that stores the encrypted messages there in some way, though?

Unfortunately I did not yet find the time to dive into Bitmessage but from the little I know clients store the messages for some days, I guess in a normal database.

I guess what I'm asking is, my project seems about as secure as bitmessage, just from what we're both doing with the secp256k1 curve. So if coinmessage is not considered secure, can bitmessage? If not, what am I missing?

The problem is that you use the same private key for both signing and encryption. Bitmessage does not do this.

By using the same key for both signing and encryption and you being able to influence the input / read output there are certainly additional attack vectors. For example you could create an unsigned transaction and try tricking the other party into signing it like a normal message.

[altoz]

The problem is that you use the same private key for both signing and encryption. Bitmessage does not do this.

By using the same key for both signing and encryption and you being able to influence the input / read output there are certainly additional attack vectors. For example you could create an unsigned transaction and try tricking the other party into signing it like a normal message.

In the example you gave, wouldn't that be an attack vector that is available without any encryption? For example, using the challenge-verify mechanism that Luke-Jr showed above, you can use an unsigned transaction as the challenge and the user would sign it and send the signature to the malicious attacker. At what step does the attacker need the encrypt/decrypt part?

[Luke-Jr]

For example, using the challenge-verify mechanism that Luke-Jr showed above, you can use an unsigned transaction as the challenge and the user would sign it and send the signature to the malicious attacker.

No, you can't.
First, the challenge must be an understandable message, not just random-looking data.
Second, the message is internally prepended with a prefix before signing, to ensure this very thing doesn't happen.
Finally, it is not valid to sign a message with a key that has been used as an address in a transaction already, only unused addresses.

[andytoshi]

A user that just got out of newbie jail calling me anything is quite rich. One may suspect this could be Luke-Jr sock puppet.

1. I am not a sockpuppet of Luke-Jr's.
2. Accusing core developers of having sock puppets and trolling is a stupid way to get anyone to take you seriously.
3. Putting core developers on your ignore list is a stupid way to learn anything.
4. My activity on bitcointroll says absolutely nothing about my knowledge or experience with bitcoin, its community or cryptography in general.
5. I didn't call you anything. I provided a link to the "accounts are not addresses" FAQ. I'll give you the benefit of the doubt and assume you read it, since my server logs show several accesses between the time I posted the link and the time of your "sock puppet" comment.

If you want to develop usable software with bitcoin, you need to listen to the experts in the community. You need to understand how bitcoin works. You need to be aware of existing tools (especially those built into the reference client!), and follow the current development and research. You need to understand the cryptography involved and common pitfalls surrounding it.

Instead, you published cryptographic software which abuses bitcoin primitives to obtain cryptographic keys (using some random centralized service no less!), which you then use for purposes they weren't designed for, to do something which has already been done. You then admitted that you weren't familiar with ECC and didn't understand what bitcoin addresses were for, and despite this you personally attacked Luke and myself. This is not the behaviour of a responsible person, or someone who can be trusted to properly develop cryptographic software.

[chriswilmer]

How is it a centralized service... it's just code anyone can use?

Also, there is no reason why we can't provide critical feedback while also being nice and supportive.

[andytoshi]

How is it a centralized service... it's just code anyone can use?

My bad. I misread that he was using blockchain.info to obtain blockchain data.

Edit: I take this back. He is using bc.i: https://github.com/coinmessage/coinmessage/blob/master/coinmessage/services.py

[altoz]

Andytoshi and luke-jr. Please leave this thread. I'm currently ignoring both of you and as far as I can tell you have nothing of substance to your remarks beyond Luke's first.

[gmaxwell]

If I'm not mistaken, this is an attack that can be performed on any elliptical curve, not just secp256k1.

Not so, there are twist-secure curves like the one used by curve25519 where the points on the twist are equally secure.

Is the fact that the private exponent is also used to sign messages somehow related to this attack?

The general statement cautioning against using the same keys for encryption and signing is because the parallel composition of signing and encryption is an unanalyzed construct. I might be able to take some signatures, combine them algebraically, ask for a decryption, and learn something about the private key as a result. Providing parallel access to the private key material, even if its via constructs which are separately accepted as cryptographically strong, voids the security proofs and deployment confidences, and surprising weaknesses have shown up in the past as a result of it. ... so it's generally considered a good practice to avoid it where possible.

I'm disappointed to see that the conversation with Luke went unproductive there, he is responsible— AFAIK— the largest and longest standing use of bitcoin keys for identification/authentication purposes; which were one of your enumerated use cases.  I actually asked him to come here and respond specifically to those use cases.

Likewise, andytoshi has been active in the Bitcoin wizards channel where a lot of advanced cryptography is discussed for some time. He's not a sock of anyone, and negative tone is just going to discourage people from evaluating your system.

[altoz]

If I'm not mistaken, this is an attack that can be performed on any elliptical curve, not just secp256k1.

Not so, there are twist-secure curves like the one used by curve25519 where the points on the twist are equally secure.

This might be true, but I still don't understand how useful such an attack would be. If the attack relies on sweeping the checksum, then having an impractically large checksum (2^128?) simply stops the attack.

The general statement cautioning against using the same keys for encryption and signing is because the parallel composition of signing and encryption is an unanalyzed construct. I might be able to take some signatures, combine them algebraically, ask for a decryption, and learn something about the private key as a result. Providing parallel access to the private key material, even if its via constructs which are separately accepted as cryptographically strong, voids the security proofs and deployment confidences, and surprising weaknesses have shown up in the past as a result of it. ... so it's generally considered a good practice to avoid it where possible.

This is the more valid objection. There's the possibility of a vulnerability yet undiscovered. Obviously, RSA has had this vulnerability so it makes sense that caution is being taken with ECC.

That said, a good, deliberately slow key derivation function should be able to make the attack very expensive. 50000 rounds of sha512, for example (to make it future-proof, we could make the rounds of sha512 necessary some fraction of the network difficulty and provide a timestamp of when it occurred). Would something like that make this more viable?

Also, you mention that it's good practice to avoid it where possible. does that mean there are cases where it isn't avoidable and this does take place?

I'm disappointed to see that the conversation with Luke went unproductive there, he is responsible— AFAIK— the largest and longest standing use of bitcoin keys for identification/authentication purposes; which were one of your enumerated use cases.  I actually asked him to come here and respond specifically to those use cases.

Honestly, I'm finding your comments far more helpful than his. He could be a genius for all I know, but I'm not interested in pedantic arguments about what "account" means.

Likewise, andytoshi has been active in the Bitcoin wizards channel where a lot of advanced cryptography is discussed for some time. He's not a sock of anyone, and negative tone is just going to discourage people from evaluating your system.

Sadly, I agree with you. Of course I have some share in that responsibility. Unfortunately, other than that first comment, I don't see anything of value in their other comments and I don't see much likelihood in there being any from them at this point. Life is too short to deal rudeness like that unless absolutely necessary.

Obviously, people are free to not evaluate the system. I think given the potential of the whole thing, I would be pretty disappointed if the only technical commentary I got was from you.

That said, thank you for your thoughts so far.

[Crowex]

This seems along the lines of ECIES
http://en.wikipedia.org/wiki/Integrated_Encryption_Scheme

I'm not sure exactly how your system works but I would have thought it should be possible to use ECDH to create a shared secret without compromising your secret key and use this in a symmetric encryption scheme (AES) without compromising the shared secret? Isn't this basically what is done in ECIES?
The private key is used in the creation of the shared secret but if this is done ok then using the shared secret in a secure symmetric system shouldn't compromise it in any way.

I may have misunderstood things but I don't see how the same private key is used for signing and encrypting - the shared secret used for encrypting isn't the private key of the bitcoin address is it??