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/issuesI 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!
]
