Quote from: e4xit on October 31, 2014, 03:12:47 PM

In this situation the sender would have by default had to already reveal (to the network) their public key, so i could encrypt the data (likely a hash) I want to return to them, and store it in the tx (somewhere) which is returned to the sending address (I know I know, bad bitcoin practice and LukeJR will probably have a field day with my terminology if he sees this), but hopefully you can understand some light on what I am thinking of doing here and let me know if it might be possible?

Well, there is no "sending address" in the Bitcoin protocol, so this data would need to be passed out-of-band. This is not a "terminology problem" nor is it an opinion of Luke-Jr's. It's a fact about Bitcoin.

Then there is a general problem with using same keys for signing and encryption. To the best of my knowledge there is no attack based on simultaneous key use in ECDSA and ECIES, but I'm also not aware of any security proof that this is a safe combination. It is routinely true that the algebraic structure of two unrelated cryptosystems can be combined to produce an attack. For example, in the CryptoNote whitepaper a ring signature scheme is proposed which has two hash functions. It turns out you can remove one of these hash functions and replace by the identity function, and still prove security of the ring signatures --- and in fact I did this, thinking that this hash function was only there for historical reasons (in the ring signature scheme that CryptoNote's scheme is based on, this hash function provides compression, which isn't needed any longer in CryptoNote). But in fact, I'd have been wrong to remove this hash, because as they observe at the bottom of page 17, without the hash function their ring signature scheme interacts very badly with their stealth address scheme. I'm glad they mentioned this because I certainly wouldn't have caught this. (You can argue in this case that I'm just not very smart

but imagine that the stealth addresses and ring signatures had been proposed by separate parties, and were combined by a non-cryptographer who was treating them as black boxes. You can see that "don't mix cryptosystems!" would have been very productive advice.)

Another general concern I have about the postings in this thread are comments along the lines of "wellll, I think I can make this secure, as long as the user doesn't do X or Y or Z". The problem with this line of thinking is that leads to very finicky and non-standard security properties, which means that anyone using the cryptosystem will need to think very carefully about exactly how the scheme is used. In professional cryptography, there are a variety of "standard security properties" which are very general and that cryptosystems are required to adhere to. For example, signature schemes should be EUF-CMA secure "existentially unforgeable under chosen message attack", meaning that even an attacker who is allowed to request signatures on arbitrary messages cannot forge one. Note that there is no dependence here on what messages are allowed to be signed, what the attacker is allowed to do, etc.

There are a couple of security properties that public-key encryption schemes ought to satisfy, which are similarly general. These properties are familiar to cryptographers and (relatively) easy for them to reason about. (Note that they do not cover side-channel attacks, and prove security only when their assumptions are satisfied --- e.g. that all random number generators are producing values that are truly indistinguishable from uniformly random ones.) Having a mathematical proof that a cryptosystem satisfies one of these properties is a prerequisite to the system even being worth analysing. Then we can consider the context that it will be used in, whether this security property is applicable, protection against side-channels, how to obtain any required randomness, who has access to what secret data, how secret data is stored or transferred, etc., etc.

There is a lot to this and if you can't get the basic provable security of the primitives down your system is hopeless. And it's simply impossible to do this with ad-hoc arguments or by layering nonstandard assumptions about how the cryptosystem will be used.

Quote from: dabura667 on October 31, 2014, 04:26:19 PM

https://github.com/bitpay/bitcore/blob/master/lib/common/ECIES.js

Is this insecure?

I don't have the time to audit the code (at least, not well enough to publicly give my blessing), but it's worth considering that Javascript cryptography is nearly impossible to do securely.