Is this a safe thing to be doing with ECC addition? (Oracle protocol) [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2014-03-08T23:13:10+00:00


Summary:

The email thread discusses the security of public key exchange, specifically in the context of EC Diffie-Hellman. It is mentioned that EC point addition is insecure because it is invertible, while EC-scalar multiplication is not. This is why EC Diffie-Hellman is secure even with timing asymmetry. Alan Reiner suggests creating a new keypair and giving the other party minus the public key, which can only be detected after the private key has been abused. To avoid this situation, parties should exchange their public keys before combining them.The conversation also explores limitations of ECDSA and alternatives for creating a signature with a + b. It is noted that Schnorr signatures can achieve this, but the k^-1 term in ECDSA makes direct multiparty signatures difficult. The idea of using a hash of the other party's public key as a means of ensuring integrity is discussed, with Joel Kaartinen suggesting that both parties insist on seeing a hash of the other party's public key before sharing their own.In another thread on the Bitcoin-development mailing list, participants discuss the issue of ensuring public key integrity. One suggestion is for parties to insist on seeing a hash of the other party's public key before sharing their own. The use of multisig is also proposed as an alternative solution. Edmund Edgar recommends exchanging public keys before combining them to avoid potential abuse.On March 8, 2014, Alan Reiner mentions creating a new key pair and sharing only the minus version with others. He explains that even without knowing his private key, someone can still abuse it. Edmund Edgar suggests the exchange of public keys before combining them to prevent such situations. Edmund Edgar is associated with Social Minds Inc and Reality Keys.Edmund Edgar presents a scenario where he gives Odinn Cyberguerrilla an ECC public key and receives back a public key of Odinn's own devising. He then pays money to the address resulting from add_pubkeys(). Edgar asks if anyone can think of a way for Odinn to spend the money without having the private key. Alan Reiner responds by presenting a scenario where he sees Odinn's public key before creating and sending his own. He creates a new keypair with an arbitrary value for c_priv and gives Odinn c_pub = G * (c_priv - b_priv). Since Alan knows b_priv, he can calculate c_pub - b_pub = G * (c_priv - b_priv + a_priv), where a_priv is his secret key. He then spends the money using the private key for c_pub - b_pub. Odinn can only detect the fraud after it's too late.On March 4th, 2014, Odinn Cyberguerrilla states that "nothing is safe." Edmund Edgar poses a question about the safety of a transaction involving ECC public keys and asks if anyone can think of a way for Odinn to spend the money without having the necessary key. Edgar is associated with Social Minds Inc and Reality Keys.Edmund Edgar introduces a new m-of-n contract implementation based on Reality Keys. This implementation uses the Reality Keys service as an External State Oracle and allows registration of possible outcomes with public keys for "yes" and "no". The winner receives the appropriate private key from Reality Keys to release the funds. Peter Todd suggests an effective way to use these keys for m-of-n contracts. Edgar combines the public key of each party with the public key of the outcome they're representing into one address spendable by either Alice or Bob after the outcome occurs. However, he expresses concern that Bob could intentionally weaken the resulting public key to sign a transaction without needing to know the private key. The example script is available on GitHub and feedback on its safety is welcome.Edmund Edgar discusses a new way of using Reality Keys to make m-of-n contracts. Reality Keys acts as an External State Oracle and allows registration of possible outcomes with public keys for "yes" and "no". Edmund Edgar combines the public key of each party with the public key of the outcome they're representing to create a public key that goes into a 1/2 P2SH address. This address is spendable by one of Alice or Bob after the outcome occurs. He expresses concern about the security of this approach and welcomes feedback from those who understand it. The code for this approach is available on GitHub and Edmund Edgar believes it could have implications for other protocols.


Updated on: 2023-08-01T07:48:50.198458+00:00