4 ms·

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 menti

by rdeboo 10y ago

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?

lexman0 10y ago
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.
- rdeboo 10y ago
  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.
  - pornin 10y ago
    One of the point of the exercise is to provide constant-time implementations that provably do not leak such information. The hash functions, two AES, one DES/3DES, RSA and elliptic curve implementations in BearSSL have been written to be constant-time. I still have to write some document that explains how such things are done.
  - mSparks 10y ago
    cant be any worse than openssl. they have all code running in constant time from the alpha version. Next comes making sure there are no buffer overflows. the code is stable and compatible. If everyone leaves it to someone else who does it exactly? Obviously not ready for use in production until its been audited. Remind me again where i can download an audited ssl implimentation?
    - BillinghamJ 10y ago
      > cant be any worse than openssl. Not sure I'd agree with that. OpenSSL is very far from perfect and obviously contains many many security bugs, but it also has a very long history of fixes, knowledge, etc. and has a large number of eyes on it. It's more of a known quantity than something new.
      - mSparks 10y ago
        well. actually looks better from the start: There is not a single malloc() call in all the library. In fact, the whole of BearSSL requires only memcpy(), memmove(), memcmp() and strlen() from the underlying C library. This makes it utterly portable even in the most special, OS-less situations. (On “big” systems, BearSSL will automatically use a couple more system calls to access the OS-provided clock and random number generator.) On big desktop and server OS, this feature still offers an interesting characteristic: immunity to memory leaks and memory-based DoS attacks. Outsiders cannot make BearSSL allocate megabytes of RAM since BearSSL does not actually know how to allocate RAM at all.
      - wbl 10y ago
        OpenSSL does not have half the fixes people think it does. Generally what gets fixed is the ciphersuites some people happen to use, and the rest remain broken. For example, the constant time ECDSA signing only works with some curves, not all. It still supports horrific hacks for random number generation, instead of using OS provided interfaces. NSS is not much better on this front, but does a far better job of parsing TLS records in a sane way.
    - deleted 10y ago
      [deleted]
  - byuu 10y ago
    This thinking is why Heartbleed was such a disaster. Everyone left it to someone else, and the end result was OpenSSL being the only serious choice. Yet even the 'experts' got it wrong -- way wrong. 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.
    - oconnor663 10y ago
      > 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. Wouldn't you say DJB (et al) did that themselves? https://tweetnacl.cr.yp.to/ https://tweetnacl.cr.yp.to/
      - byuu 10y ago
        I haven't benchmarked TweetNaCl's performance yet, but I think that goes way too far into making the code completely unreadable. The 80%/10% number I gave is against the ref10 implementation. Compare theirs: https://tweetnacl.cr.yp.to/20140427/tweetnacl.c https://tweetnacl.cr.yp.to/20140427/tweetnacl.c To mine: https://gitlab.com/higan/higan/blob/master/nall/elliptic-curve/curve25519.hpp https://gitlab.com/higan/higan/blob/master/nall/elliptic-cur... https://gitlab.com/higan/higan/blob/master/nall/elliptic-curve/ed25519.hpp https://gitlab.com/higan/higan/blob/master/nall/elliptic-cur... https://gitlab.com/higan/higan/blob/master/nall/cipher/chacha20.hpp https://gitlab.com/higan/higan/blob/master/nall/cipher/chach... https://gitlab.com/higan/higan/blob/master/nall/mac/poly1305.hpp https://gitlab.com/higan/higan/blob/master/nall/mac/poly1305... https://gitlab.com/higan/higan/blob/master/nall/hash/sha256.hpp https://gitlab.com/higan/higan/blob/master/nall/hash/sha256.... Please note that like BearSSL, my implementations are alpha-quality. Further, I'm not suggesting anyone use these in production. If I do so myself and it blows up in my face, it'll only have harmed me, and I'll only have myself to blame. (Also, I'm really bad when it comes to source code comments, sorry. The why really needs you to read the research papers; the how is mostly self-evident. The remaining one-letter variable names were used to match the papers, and because I couldn't think of more descriptive terms.)
  - deleted 10y ago
    [deleted]
- akie 10y ago
  I still think it applies.
- keymone 10y ago
  this might give people false sense of security. implementing own crypto exposes you and those few souls that bought into your story. implementing bug-free "proven crypto" is near impossible task, but "proven crypto" part sells much better and so exposes many more un-expecting victims.
  - throwawayReply 10y ago
    Nobody gets fired for linking openssl.
    - nine_k 10y ago
      ...yet. Not sure about 10 years from now.
- user5994461 10y ago
  Your own implementation of an algorithm is also a cliche. Use proven and battle tested library. You won't do any better on your own.
- tptacek 10y ago
  Whoah, no. It's about building crypto code at all. Given a choice between building something with Nacl and a bespoke stream cipher and building something with a bespoke cryptosystem and AES, I would have a hard time picking, but I'd lean towards Nacl.
pornin 10y ago
It is a combination of "many eyes" and "good documentation". What is needed is some good text that describes the design choice, the rationale, and all the tricky details; and then people who read it and think about it. I'll write and publish such text within the next few months.
- xdej 10y ago
  You could use some of your 233,693 reputation points as bounties on security.SE to attract people to read and think about bearssl.
- rdeboo 10y ago
  So I guess it is going to take years. Generally, open source software benefits from more users. But having a huge amount of users makes it more difficult to improve and cleanup because you can't just deprecate stuff easily. (like SSL2/3). Also, having 100% of the internet using openssl makes the impact of a vulnerability in that library huge. Some diversity is probably a good thing. I appreciate the time and effort that you are putting into it, good luck.
- baby 10y ago
  any RSS feed to be able to catch that?
mpettitt 10y ago
This is a very important point. When it comes to implementing new software, especially in a critical field like crypto, it takes a long time for acceptance to build. As alpha software, I'd be shocked if anyone was using it in a production capacity, but it could be useful for early investigations into issues like timing attacks - clearly, it's better to get them sorted before a "final" release. I'd hope that any project planning to adopt this or any) crypto code was first getting it analysed carefully. On the other hand, quite a bit of existing crypto is there because it was the first implementation on a given platform, despite potentially having issues - think about heartbleed, which was missed for quite a while in very heavily used software. It's not always bad to have fresh alternatives, as long as they are approached cautiously.
dchest 10y ago
I was skeptical, but then saw: author Thomas Pornin Yeah, "should not implement your own crypto" doesn't apply to him.
- btown 10y ago
  From his CV http://www.bolet.org/~pornin/cv-en.html http://www.bolet.org/~pornin/cv-en.html : 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). Yeah, doesn't apply to him.
- mythz 10y ago
  Definitely, most of my crypto searches ends up landing on one of his answers :)
- avhon1 10y ago
  After a little bit of looking around on the internet, I think I agree.
- hbbio 10y ago
  And you are Dmitry! We use your TweetNacl-js implementation for https://github.com/wallix/PEPS https://github.com/wallix/PEPS!
stonemetal 10y ago
My understanding is it generally takes years. First it is reviewed by multiple security professionals who look for known attacks. Once it is generally thought to be ok it sees limited real world use. There it generally just takes trial and error time.

by rdeboo 10y ago

lexman0 10y ago

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.

rdeboo 10y ago
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.
- pornin 10y ago
  One of the point of the exercise is to provide constant-time implementations that provably do not leak such information. The hash functions, two AES, one DES/3DES, RSA and elliptic curve implementations in BearSSL have been written to be constant-time. I still have to write some document that explains how such things are done.
- mSparks 10y ago
  cant be any worse than openssl. they have all code running in constant time from the alpha version. Next comes making sure there are no buffer overflows. the code is stable and compatible. If everyone leaves it to someone else who does it exactly? Obviously not ready for use in production until its been audited. Remind me again where i can download an audited ssl implimentation?
  - BillinghamJ 10y ago
    > cant be any worse than openssl. Not sure I'd agree with that. OpenSSL is very far from perfect and obviously contains many many security bugs, but it also has a very long history of fixes, knowledge, etc. and has a large number of eyes on it. It's more of a known quantity than something new.
    - mSparks 10y ago
      well. actually looks better from the start: There is not a single malloc() call in all the library. In fact, the whole of BearSSL requires only memcpy(), memmove(), memcmp() and strlen() from the underlying C library. This makes it utterly portable even in the most special, OS-less situations. (On “big” systems, BearSSL will automatically use a couple more system calls to access the OS-provided clock and random number generator.) On big desktop and server OS, this feature still offers an interesting characteristic: immunity to memory leaks and memory-based DoS attacks. Outsiders cannot make BearSSL allocate megabytes of RAM since BearSSL does not actually know how to allocate RAM at all.
    - wbl 10y ago
      OpenSSL does not have half the fixes people think it does. Generally what gets fixed is the ciphersuites some people happen to use, and the rest remain broken. For example, the constant time ECDSA signing only works with some curves, not all. It still supports horrific hacks for random number generation, instead of using OS provided interfaces. NSS is not much better on this front, but does a far better job of parsing TLS records in a sane way.
  - deleted 10y ago
    [deleted]
- byuu 10y ago
  This thinking is why Heartbleed was such a disaster. Everyone left it to someone else, and the end result was OpenSSL being the only serious choice. Yet even the 'experts' got it wrong -- way wrong. 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.
  - oconnor663 10y ago
    > 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. Wouldn't you say DJB (et al) did that themselves? https://tweetnacl.cr.yp.to/ https://tweetnacl.cr.yp.to/
    - byuu 10y ago
      I haven't benchmarked TweetNaCl's performance yet, but I think that goes way too far into making the code completely unreadable. The 80%/10% number I gave is against the ref10 implementation. Compare theirs: https://tweetnacl.cr.yp.to/20140427/tweetnacl.c https://tweetnacl.cr.yp.to/20140427/tweetnacl.c To mine: https://gitlab.com/higan/higan/blob/master/nall/elliptic-curve/curve25519.hpp https://gitlab.com/higan/higan/blob/master/nall/elliptic-cur... https://gitlab.com/higan/higan/blob/master/nall/elliptic-curve/ed25519.hpp https://gitlab.com/higan/higan/blob/master/nall/elliptic-cur... https://gitlab.com/higan/higan/blob/master/nall/cipher/chacha20.hpp https://gitlab.com/higan/higan/blob/master/nall/cipher/chach... https://gitlab.com/higan/higan/blob/master/nall/mac/poly1305.hpp https://gitlab.com/higan/higan/blob/master/nall/mac/poly1305... https://gitlab.com/higan/higan/blob/master/nall/hash/sha256.hpp https://gitlab.com/higan/higan/blob/master/nall/hash/sha256.... Please note that like BearSSL, my implementations are alpha-quality. Further, I'm not suggesting anyone use these in production. If I do so myself and it blows up in my face, it'll only have harmed me, and I'll only have myself to blame. (Also, I'm really bad when it comes to source code comments, sorry. The why really needs you to read the research papers; the how is mostly self-evident. The remaining one-letter variable names were used to match the papers, and because I couldn't think of more descriptive terms.)
- deleted 10y ago
  [deleted]
akie 10y ago
I still think it applies.
keymone 10y ago
this might give people false sense of security. implementing own crypto exposes you and those few souls that bought into your story. implementing bug-free "proven crypto" is near impossible task, but "proven crypto" part sells much better and so exposes many more un-expecting victims.
- throwawayReply 10y ago
  Nobody gets fired for linking openssl.
  - nine_k 10y ago
    ...yet. Not sure about 10 years from now.
user5994461 10y ago
Your own implementation of an algorithm is also a cliche. Use proven and battle tested library. You won't do any better on your own.
tptacek 10y ago
Whoah, no. It's about building crypto code at all. Given a choice between building something with Nacl and a bespoke stream cipher and building something with a bespoke cryptosystem and AES, I would have a hard time picking, but I'd lean towards Nacl.

pornin 10y ago

It is a combination of "many eyes" and "good documentation". What is needed is some good text that describes the design choice, the rationale, and all the tricky details; and then people who read it and think about it. I'll write and publish such text within the next few months.

xdej 10y ago
You could use some of your 233,693 reputation points as bounties on security.SE to attract people to read and think about bearssl.
rdeboo 10y ago
So I guess it is going to take years. Generally, open source software benefits from more users. But having a huge amount of users makes it more difficult to improve and cleanup because you can't just deprecate stuff easily. (like SSL2/3). Also, having 100% of the internet using openssl makes the impact of a vulnerability in that library huge. Some diversity is probably a good thing. I appreciate the time and effort that you are putting into it, good luck.
baby 10y ago
any RSS feed to be able to catch that?

mpettitt 10y ago

This is a very important point. When it comes to implementing new software, especially in a critical field like crypto, it takes a long time for acceptance to build. As alpha software, I'd be shocked if anyone was using it in a production capacity, but it could be useful for early investigations into issues like timing attacks - clearly, it's better to get them sorted before a "final" release. I'd hope that any project planning to adopt this or any) crypto code was first getting it analysed carefully. On the other hand, quite a bit of existing crypto is there because it was the first implementation on a given platform, despite potentially having issues - think about heartbleed, which was missed for quite a while in very heavily used software. It's not always bad to have fresh alternatives, as long as they are approached cautiously.

dchest 10y ago

I was skeptical, but then saw: author Thomas Pornin Yeah, "should not implement your own crypto" doesn't apply to him.

btown 10y ago
From his CV http://www.bolet.org/~pornin/cv-en.html http://www.bolet.org/~pornin/cv-en.html : 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). Yeah, doesn't apply to him.
mythz 10y ago
Definitely, most of my crypto searches ends up landing on one of his answers :)
avhon1 10y ago
After a little bit of looking around on the internet, I think I agree.
hbbio 10y ago
And you are Dmitry! We use your TweetNacl-js implementation for https://github.com/wallix/PEPS https://github.com/wallix/PEPS!

stonemetal 10y ago

My understanding is it generally takes years. First it is reviewed by multiple security professionals who look for known attacks. Once it is generally thought to be ok it sees limited real world use. There it generally just takes trial and error time.