4 ms·

> Don’t roll your own crypto This motto should be read in the same vein as: If part of your software product is developing a new database, your product is now

by __s 6y ago

> Don’t roll your own crypto This motto should be read in the same vein as: If part of your software product is developing a new database, your product is now a database Or, if part of your astrophysics experiment involves developing a new launch vehicle, you're now a launch vehicle project (forget what I'm poorly paraphrasing here, maybe https://spacecraft.ssl.umd.edu/akins_laws.html https://spacecraft.ssl.umd.edu/akins_laws.html )

nullc 6y ago
Right. Also, people misunderstand the scope of it. So for example, they'll feel they are abiding by that rule by not implementing SHA256 themselves while also creating a novel cryptographic high level protocol (like TLS or SSH). The advice was more originally meant for people cooking up their on novel ciphers, but its applied more often today against reimplementing standard ones. Though it's still best to not implement SHA256 yourself-- and generally pointless, it's extremely unlikely that someone who does would get it substantially wrong with even a normal amount of effort... you're still way better off implementing SHA256 and AES (which is difficult to make sidechannel free) and whatever yourself than constructing some a novel high level protocol. If there is cryptography in your product the boundary probably doesn't just magically stop at the functional call into AES. Your entire product is to some degree "cryptography"-- though how much depends on the details. And this is where "abstinence only" cryptographic education really fails: By saying _never do it_ we encourage an extremely narrow definition of "it" that often gets limited to "don't implement your own standard blockcipher" or "don't cook up your own blockcipher" and ignores all the higher layer stuff, where you often can't avoid engaging in a bit of crypto development. ... and, of course, most of the meaningful vulnerabilities end up in those higher layers. The implementations you might find are also not always very good but unfortunately it can be hard to tell which are and which aren't. More of my thoughts on this subject: https://youtu.be/Gs9lJTRZCDc?t=2244 https://youtu.be/Gs9lJTRZCDc?t=2244
m463 6y ago
It seems that development of a many new games leads to development of new game engines. With Valve it got even more out of hand with Steam.

by __s 6y ago

nullc 6y ago

Right. Also, people misunderstand the scope of it. So for example, they'll feel they are abiding by that rule by not implementing SHA256 themselves while also creating a novel cryptographic high level protocol (like TLS or SSH). The advice was more originally meant for people cooking up their on novel ciphers, but its applied more often today against reimplementing standard ones. Though it's still best to not implement SHA256 yourself-- and generally pointless, it's extremely unlikely that someone who does would get it substantially wrong with even a normal amount of effort... you're still way better off implementing SHA256 and AES (which is difficult to make sidechannel free) and whatever yourself than constructing some a novel high level protocol. If there is cryptography in your product the boundary probably doesn't just magically stop at the functional call into AES. Your entire product is to some degree "cryptography"-- though how much depends on the details. And this is where "abstinence only" cryptographic education really fails: By saying _never do it_ we encourage an extremely narrow definition of "it" that often gets limited to "don't implement your own standard blockcipher" or "don't cook up your own blockcipher" and ignores all the higher layer stuff, where you often can't avoid engaging in a bit of crypto development. ... and, of course, most of the meaningful vulnerabilities end up in those higher layers. The implementations you might find are also not always very good but unfortunately it can be hard to tell which are and which aren't. More of my thoughts on this subject: https://youtu.be/Gs9lJTRZCDc?t=2244 https://youtu.be/Gs9lJTRZCDc?t=2244

m463 6y ago

It seems that development of a many new games leads to development of new game engines. With Valve it got even more out of hand with Steam.