3 ms·
Just to drive it home. Those who actually make their own encryption libraries know their stuff, and have been in the space for years. You should never, ever,
by cremp 8y ago
Just to drive it home.
Those who actually make their own encryption libraries know their stuff, and have been in the space for years.
You should never, ever, roll your own encryption.
If it's a requirement, then change your damn requirements, because just like consensus; it is not easy to get right, and the pros make mistakes.
- zzzcpan 8y agoConsensus is not crypto, it's ridiculously trivial in comparison and usually so useless, that nobody even bothers doing it correctly all the way to the end user.
- dlubarov 8y agoI think it's worth distinguishing a few cases here: 1. Reimplementing an existing cryptographic primitive, such as SHA-256. 2. Inventing a new cryptographic primitive, with a reduction to existing cryptographic assumptions, and implementing it. A recent example is SPHINCS-256, which was proven secure in the random oracle model. 3. Postulating a new cryptographic hardness assumption, inventing a new cryptographic primitive based on it, and implementing it. Recent examples are IOTA's Curl hash function and StarkWare's Jarvis cipher. #1 is risky, but at least the risk can be mitigated by having qualified peers review the implementation. #2 is riskier, but still, it can be mitigated by having qualified peers review the proof. #3 seems far more dangerous, since it involves conjecture. What the Tupelo team is doing is like #2 -- risky, yes, but not comparable to #3.