21–30 of 206 posts
> written in C Stopped reading there.
Why? Crypto in a memory-managed language is not just a bad idea but a horrifically bad idea because you expose yourself to every single bug in the runtime's memory management.
One of the cliches about crypto is that you should not implement your own crypto. Not to suggest that the authors don't know what they are doing, but they mention 'alpha' quality themselves on the site. I wonder, how long does it take until a new library is deemed secure? What does the process look like? Trial and error? Or do they compare notes with vulnerabilities found in e.g. openssl?
Generally the cliche is about not implementing your own cryptographic algorithms. As long as they only implement existing algorithms and don't generate new ones, I don't think this applies.
Use proven and battle tested library. You won't do any better on your own.
Earlier quoted context omitted.
Why? Crypto in a memory-managed language is not just a bad idea but a horrifically bad idea because you expose yourself to every single bug in the runtime's memory management.
A lot of people are arguing that new projects like this should use Rust. Like https://github.com/ctz/rustls .
Earlier quoted context omitted.
Generally the cliche is about not implementing your own cryptographic algorithms. As long as they only implement existing algorithms and don't generate new ones, I don't think this applies.
I used to think that; but I'm following Dan Boneh's crypto course on Coursera at the moment, and he specifically notes that you should not even try to implement known algorithms yourself (for production; you could do it ofcourse for the learning experience). The reason is that there are subtle attacks on the implementation, such as timing attacks, which can leak information.
I'm not advocating everyone and their mother implement their own crypto. But some software diversity is a good thing. These algorithms aren't quite as scary or fickle as the documentation and existing implementations make them seem. Especially if you stick to good software like DJB's stuff.
For instance, using montgomery/edwards curves instead of weierstrass curves eliminates a lot of the difficulty in writing a constant-time implementation of ECC. And the 25519 implementation comes with a fast, constant-time implementation of a prime field type.
Yet even DJB's stuff can be simplified. You can knock off a good 80% of the scary code at a cost of a mere 10% of performance. To Google or Facebook, that may be unacceptable. But to me, that's entirely worth it. Now you have a tiny library that is easy to understand, and easy to audit.
One of the cliches about crypto is that you should not implement your own crypto. Not to suggest that the authors don't know what they are doing, but they mention 'alpha' quality themselves on the site. I wonder, how long does it take until a new library is deemed secure? What does the process look like? Trial and error? Or do they compare notes with vulnerabilities found in e.g. openssl?
author Thomas Pornin
> written in C Stopped reading there.
Edit: http://www.bolet.org/~pornin/cv-en.html Disregard me.
Says who? Maybe the cruft of the old ones means its impractical to fix. Maybe the leadership of the old ones means it can't be fixed due to incompetence or toxic politics. Sometimes rolling your own or forking is the smart move. There's a reason you use x.org and not xfree86 for example. The idea that no one should ever roll their own cryptography is a cutesey warning for amateurs, but not an absolute rule. If no one…
Earlier quoted context omitted.
Why? Crypto in a memory-managed language is not just a bad idea but a horrifically bad idea because you expose yourself to every single bug in the runtime's memory management.
A lot of people are arguing that new projects like this should use Rust. Like https://github.com/ctz/rustls .
One of the cliches about crypto is that you should not implement your own crypto. Not to suggest that the authors don't know what they are doing, but they mention 'alpha' quality themselves on the site. I wonder, how long does it take until a new library is deemed secure? What does the process look like? Trial and error? Or do they compare notes with vulnerabilities found in e.g. openssl?
One of the cliches about crypto is that you should not implement your own crypto. Not to suggest that the authors don't know what they are doing, but they mention 'alpha' quality themselves on the site. I wonder, how long does it take until a new library is deemed secure? What does the process look like? Trial and error? Or do they compare notes with vulnerabilities found in e.g. openssl?
I was skeptical, but then saw: author Thomas Pornin Yeah, "should not implement your own crypto" doesn't apply to him.
AES (Advanced Encryption Standard, 1997 to 2000): co-author of the block cipher DFC
eSTREAM (ECRYPT Stream Cipher Project, 2004 to 2008): co-author of the stream cipher SOSEMANUK (admitted in the final portfolio)
SHA-3 (2007 to 2012): co-author of the cryptographic hash function Shabal (selected for second round)
PHC (Password Hashing Competition, 2013 to 2015): author of the password hashing function Makwa (finalist, was awarded a "special recognition")
Author of the sphlib library: optimized implementations of many cryptographic hash functions, both in C and Java.
Author of RFC 6979: Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA).