Steem & BitShares Cryptographic Security Update

It just came to my attention that the community has been discussing "quirks" in our usage of canonical signatures. Hive account@faddat and others is ready to burn us at the stake for our incompetence. I want to clear things up because all accusations are coming from a point of ignorance of the history of the code, crypto, and signatures.

Signature Malleability

Bitcoin exchanges suffered great losses due to transaction malleability, the ability for someone to modify a transaction into another equally valid transaction without invalidating the signature. It turns out that anyone can take your signed transaction and create 4 different perfectly valid signatures without knowing your private key. If these signatures produce a different transaction ID then it makes it impossible to track / check for the inclusion of your transaction with single canonical identifier.

At one point in time this malleability issue allowed the replay of transactions up to 4 times because each transaction had a unique ID. We fixed this by requiring canonical signatures AND by identifying transactions by their digest which is independent of the transaction signatures.

Here is the relevant information from the Bitcoin WIki

The first form of malleability is in the signatures themselves. Each signature has exactly one DER-encoded ASN.1 octet representation, but OpenSSL does not enforce this, and as long as a signature isn't horribly malformed, it will be accepted.[1] In addition for every ECDSA signature (r,s), the signature (r, -s (mod N)) is a valid signature of the same message.[2]

As of block 363724[3], the BIP66 soft fork has made it mandatory for all new transactions in the block chain to strictly follow the DER-encoded ASN.1 standard. Further efforts are still under way to close other possible malleability within DER signatures.

Canonical Signatures

Given that every time you sign something anyone can create 4 variations on the signature, we simply require that all signatures be in 1 of the 4 forms and reject signatures that are valid but in the wrong form. This means we have a stricter signature requirement than is mathematically required by elliptic curves.

Implementation Options

We had two possible implementation approaches: convert the generated signature into canonical form or generate a new signature and check to see if it is in canonical form. 1 in 4 signatures are randomly canonical in the first place, so it doesn't take many attempts to find a canonical signature.

On the signature checking / validation side of things it is identical. Every signature that is "canonical" also passes under the looser terms.

Conclusion

The take away from this is that people need to be slow to throw stones and that Hive account@faddat is picking on a straw man. It shows that if the things he is working on isn't careful, then they will be vulnerable to signature malleability just like Bitcoin and BitShares once were.

Here is a useful info graphic generated to describe how Bitcoin and/or BitShares were once attacked due to lack of canonical signature enforcement.