Topic: [ANN] CoinMessage: Secure Messaging with Bitcoin Addresses (Read 7046 times)

No. The use of any particular encryption scheme does not answer the very minor and very abstract concern I raised about parallel use of the private keying material. I'm getting a very concerning sense of the blind leading the blind here, and the incivility is really out of line.

The "new tech" encryption based "two factor" authentication protocol described above is insecure against a malware infected host. Because it operates in-band and the authentication credential is unauthenticated and the malware can just steal the response. Presumably the purpose of having a two factor in the first place was to be secure against that. The sign-message mechanism— which could be given an exactly equivalent workflow, and which doesn't have the same additional security considerations to consider can be free of this weakness if used to specifically authenticate the action requested.

This has gone offtopic for this subforum.

[Edit: For historical interest sake, I should publish the weaknesses I reported privately:

I found a weakness for this cryptosystem which allows me to compromise it for a single message with 2^64 known-ciphertext queries to a decryption oracle.  E.g. the key-holders run a server (the oracle) that decrypts messages and returns the results and I obtain the ciphertext of a message someone else created (which the oracle refuses to decrypt for me, otherwise this would be trivial), and after making 2^64 queries to the decryption oracle I can decrypt the unknown message.

To accomplish this I take the nonce from the message to be decrypted, and combine it with the all zeros ciphertext (or any other known ciphertext for that matter) and sweep the 64-bit MAC space until it passes. I xor the resulting garbage decryption of zeros with the message thus recovering the plaintext.  This attack is a result of compromising the ECIES security claims by the reduction of the MAC size, though it only results in a complete break because of the use of counter mode AES.

Less cryptographically,

Using a centralized service to look up public keys creates weaknesses worse than just the 'obvious' privacy and availability ones because the implementation here doesn't check that the pubkey returned matches the address, though it trivially could.

This weakness is made exponentially worse because the public key is fetched over https using urllib2 which, as far as I can tell, doesn't do any certificate validation, so any MITM could substitute the public key.

Altoz has subsequently opened up issues for all these items: https://github.com/coinmessage/coinmessage/issues

I still have the general reservations with using encryption for authentication, especially in-band auth— and for reusing a single private key for signing and encryption, both are generally inadvisable practices though I'm not aware of any specific weakness they create here. Likewise, any usage that needlessly ties a user's identity to their finances could result in surprising losses of privacy, so I hope this approach isn't widely adopted even once the cryptographic weaknesses are fixed. If people want you to send them encrypted messages, get pubkeys from them!

]

Luke-Jr, I've put you on my ignore list. I literally don't see anything you write. Please just leave and stop crapping my thread.

If you want to discuss things mano-a-mano, PM me.

No, you don't get to demand this while continuing to slander me.

Luke-Jr, I can't see what you wrote, but please respect my wishes and stay away.

Continuing to troll does not help your case.
I said nothing of the sort.

My impression is that Luke-Jr isn't really interested in a new tech, more convenient though it may be.

Here is example walkthrought how it could be:
1) Go to website
2) Read a QR code on the main page with your smart phone application

After that, you are logged in with your bitcoin keys and username you chose when registered.

Registering:
1) Go to website
2) Click 'register'
3) Type in the username you want
4) Read a QR code on the main page with your smart phone application

After that, you are registered with bitcoin keys and username you chose.

Try it at http://cave.dy.fi. You can download an android application or simulate it with www-browser / copypaste.

This could be usefull to implement for loggin in to eligius?

I am using ECIES, I think. I would need a more experienced cryptographer to examine the code to make sure, but it's fairly straightforward. The shared secret gets exchanged securely using the same discrete logarithm problem. The shared secret then is plugged into a key derivation function which is used to make a cipher and an hmac for evaluating the checksum. The cipher then is used for encrypting and decrypting the message. And the checksum is checked to make sure the message arrived un-modified. That's how ECIES works, I think. That's at least what I tried to implement.

II think bit message uses ECIES. I believe it's secure as long as you perform your key exchange ok and you're using a secure symmetric cryptography (I might be wrong). and I think ( but I don't know exactly what your program does) that you are using the same sort of ideas. You would probably be better off just implementing ECIES though.
 I don't think your OP explained your system in enough detail so it may have been misunderstood. Also bear in mind that I'm quite often wrong about stuff.
 
 

So are you saying gmaxwell's main objection doesn't apply? That by having a shared secret with symmetric encryption inside, the attacks don't reveal anything about the private key?

Yes, that's the way I thought you were doing it?
I don't understand the problem. I think they might have not understood that you were using the shared secret for symmetric encryption.

It is very much along those lines, yes.


Can you elaborate on this? The shared secret is rP where r is a random nonce in the prime field F/p and P is the public key point. This is never transmitted, rG is. I'm not sure I understand how this compromises the secret key?


The private key is not used in the creation of the shared secret since the person encrypting has only the public key and computes the shared secret through a nonce.

No, the shared secret used for encryption is not the same as the private key used to sign the bitcoin address.

I may not have understood gmaxwell correctly, but I thought this was still a potential vulnerability as the private key is still used for decryption?

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??

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.


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?


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.


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.

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

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.

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.

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

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.

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.

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.