www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - A security review of the D library Crypto

reply Cym13 <cpicard purrfect.fr> writes:
As some of you may know one of my hobbies is to review open 
source software for security issues. About a year ago I reviewed 
the RSA implementation of Crypto[1]: a native D library which, 
according to dub statistics, is fairly popular.

Issues were found and after discussion with the author I decided 
to wait for them to be fixed. A year later I would like to 
present the results of an updated review of the library:

https://breakpoint.purrfect.fr/article/review_crypto_d.html

Here's what you should know if you are a user:

RSA, as implemented in the library, is still very much broken. I 
do not recommend using it. The confidentiality and integrity of 
all messages exchanged using this library must be questionned: if 
you exchanged sensitive information such as passwords using it 
I recommend to change them since their security is not guaranteed.

“Is this really the place to have this discussion? Shouldn't this 
be between the author and you?“

The author was contacted a year ago and although our discussion 
was kind and productive I have not heard from him since. Most of 
the issues present today were already present in my first 
assessment. Some modifications were made, but most 
recommendations were ignored. After a year without action I feel 
that the users should know exactly what they are exposed to since 
they are the ones affected by these security issues. This follows 
standard vulnerability disclosure processes.

For all details and analysis I direct you to the blog post. It is 
a rather thorough and technical read so I would recommend 
grabbing a cup of tea first.

If you find any mistake or unclear parts I'll be glad to correct 
it so feel free to point it out. Furthermore if you would like 
someone to have a look at your project to identify issues I am 
always glad to help free and open source projects that can't 
afford security review through traditional means so feel free to 
reach out.

[1] https://code.dlang.org/packages/crypto
Jul 01
next sibling parent reply Arafel <er.krali gmail.com> writes:
On 1/7/20 9:19, Cym13 wrote:
 As some of you may know one of my hobbies is to review open source 
 software for security issues. About a year ago I reviewed the RSA 
 implementation of Crypto[1]: a native D library which, according to dub 
 statistics, is fairly popular.
 
 Issues were found and after discussion with the author I decided to wait 
 for them to be fixed. A year later I would like to present the results 
 of an updated review of the library:
 
 https://breakpoint.purrfect.fr/article/review_crypto_d.html
 
 Here's what you should know if you are a user:
 
 RSA, as implemented in the library, is still very much broken. I do not 
 recommend using it. The confidentiality and integrity of all messages 
 exchanged using this library must be questionned: if you exchanged 
 sensitive information such as passwords using it I recommend to change 
 them since their security is not guaranteed.
 
 “Is this really the place to have this discussion? Shouldn't this be 
 between the author and you?“
 
 The author was contacted a year ago and although our discussion was kind 
 and productive I have not heard from him since. Most of the issues 
 present today were already present in my first assessment. Some 
 modifications were made, but most recommendations were ignored. After a 
 year without action I feel that the users should know exactly what they 
 are exposed to since they are the ones affected by these security 
 issues. This follows standard vulnerability disclosure processes.
 
 For all details and analysis I direct you to the blog post. It is a 
 rather thorough and technical read so I would recommend grabbing a cup 
 of tea first.
 
 If you find any mistake or unclear parts I'll be glad to correct it so 
 feel free to point it out. Furthermore if you would like someone to have 
 a look at your project to identify issues I am always glad to help free 
 and open source projects that can't afford security review through 
 traditional means so feel free to reach out.
 
 [1] https://code.dlang.org/packages/crypto
As somebody who also was somewhat involved in infosec and cryptography in a previous life, I found your article really interesting. So, first of all, thanks for taking the time to do the review and for publishing the results! I see that you mostly focus on the algorithms, but did you also check for side-channel attacks (for instance, timing attacks), or given the flaws already found it would make little sense to go deeper? I find that following a well-known algorithm is just the easy part when implementing crypto... the hard one is ironing out those pesky "implementation details". That's one of the reasons why I would try to use one of the "big" libraries for cryptography instead of rolling out my own, even if it meant adding an external C/C++ dependency to my project.
Jul 01
parent Cym13 <cpicard purrfect.fr> writes:
On Wednesday, 1 July 2020 at 07:49:27 UTC, Arafel wrote:
 As somebody who also was somewhat involved in infosec and 
 cryptography in a previous life, I found your article really 
 interesting. So, first of all, thanks for taking the time to do 
 the review and for publishing the results!

 I see that you mostly focus on the algorithms, but did you also 
 check for side-channel attacks (for instance, timing attacks), 
 or given the flaws already found it would make little sense to 
 go deeper?
Fixing the issues from the article would require a huge amount of code changes, so I saw little point in timing the library as is. It must do the right thing before doing it the right way.
 I find that following a well-known algorithm is just the easy 
 part when implementing crypto... the hard one is ironing out 
 those pesky "implementation details". That's one of the reasons 
 why I would try to use one of the "big" libraries for 
 cryptography instead of rolling out my own, even if it meant 
 adding an external C/C++ dependency to my project.
I can definitely vouch for that.
Jul 01
prev sibling next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Wednesday, 1 July 2020 at 07:19:11 UTC, Cym13 wrote:
 Here's what you should know if you are a user:

 RSA, as implemented in the library, is still very much broken. 
 I do not recommend using it. The confidentiality and integrity 
 of all messages exchanged using this library must be 
 questionned: if you exchanged sensitive information such as 
 passwords using it I recommend to change them since their 
 security is not guaranteed.

 [snip]
Thanks for the article. IMO it was as clear for non-professionals as crypto can be: Even I (non-crypographer) understood what's the problem with padding with only one byte. It also illustrates what's the prolem with cryptography: it's like coding without ability to test. Who could even dream to get that right the first or even the second time? I think there a shortcoming in the "don't roll your own crypto" - advice: One could think it only applies to the algorithms, not the implementation. That's what I did when I first heard it. If one needs to use cryptography, would redundancy help? I mean, encode and decode the message with say three different algorithms from different libraries, so that the attacker would need to find a weakness in all of them?
Jul 01
parent reply Cym13 <cpicard purrfect.fr> writes:
On Wednesday, 1 July 2020 at 10:59:13 UTC, Dukc wrote:
 On Wednesday, 1 July 2020 at 07:19:11 UTC, Cym13 wrote:
 Here's what you should know if you are a user:

 RSA, as implemented in the library, is still very much broken. 
 I do not recommend using it. The confidentiality and integrity 
 of all messages exchanged using this library must be 
 questionned: if you exchanged sensitive information such as 
 passwords using it I recommend to change them since their 
 security is not guaranteed.

 [snip]
Thanks for the article. IMO it was as clear for non-professionals as crypto can be: Even I (non-crypographer) understood what's the problem with padding with only one byte.
Thank you for that feedback.
 It also illustrates what's the prolem with cryptography: it's 
 like coding without ability to test. Who could even dream to 
 get that right the first or even the second time? I think there 
 a shortcoming in the "don't roll your own crypto" - advice: One 
 could think it only applies to the algorithms, not the 
 implementation. That's what I did when I first heard it.
There's one more element missing here: the protocol. Cryptography isn't about encrypting stuff, it's about protecting secrets from start to finish and that includes the protocol used. To take an example, many people can think "Hey, I need encryption between my two servers, I'll use AES" and stop there. But use AES how? What mode (CBC,GCM,...)? Let's say CBC is used, what about message authentication? Can I just modify your stream? How is the key exchanged? How is the key generated? Etc. People tend to focus on encryption, be it algorithm or implementation, but once you've got bricks it's still a pain to put them together in a solid way. Things like TLS or SSH actually combine at least 3 completely different sets of bricks to establish the communication, authenticate it, secure it once established etc. So, in a way, "don't roll your own crypto" means "use TLS as much as possible" :)
 If one needs to use cryptography, would redundancy help? I 
 mean, encode and decode the message with say three different 
 algorithms from different libraries, so that the attacker would 
 need to find a weakness in all of them?
That's a good question. The general answer is: no. The more detail answer is: in some cases it can help (I know of one client for example that doesn't trust national standards and has layered US technology with Russian technology to make sure that at least one layer stands). However in the general case we can prove that the security of the combination is less than or equal to the security of the better of the elements of that combination. In some cases badly choosen algorithm actually counteract each other leading to easier attacks. My general advice is to stay true to well audited implementations of good standards. I like opiniated libraries in that context so I'd say "whatever libsodium implements".
Jul 01
parent sarn <sarn theartofmachinery.com> writes:
On Wednesday, 1 July 2020 at 11:54:54 UTC, Cym13 wrote:
 On Wednesday, 1 July 2020 at 10:59:13 UTC, Dukc wrote:
 It also illustrates what's the prolem with cryptography: it's 
 like coding without ability to test. Who could even dream to 
 get that right the first or even the second time? I think 
 there a shortcoming in the "don't roll your own crypto" - 
 advice: One could think it only applies to the algorithms, not 
 the implementation. That's what I did when I first heard it.
There's one more element missing here: the protocol. Cryptography isn't about encrypting stuff, it's about protecting secrets from start to finish and that includes the protocol used. To take an example, many people can think "Hey, I need encryption between my two servers, I'll use AES" and stop there. But use AES how? What mode (CBC,GCM,...)? Let's say CBC is used, what about message authentication? Can I just modify your stream? How is the key exchanged? How is the key generated? Etc. People tend to focus on encryption, be it algorithm or implementation, but once you've got bricks it's still a pain to put them together in a solid way. Things like TLS or SSH actually combine at least 3 completely different sets of bricks to establish the communication, authenticate it, secure it once established etc. So, in a way, "don't roll your own crypto" means "use TLS as much as possible" :)
Some people don't want to hear all that because implementing crypto is exciting. So I like to recommend this problem set instead: https://cryptopals.com/ It scratches the "I wanna write crypto" itch, and it makes the "custom crypto is easier to break than you might think" point really well. (By the way, your article had really good depth. I'm subscribing to your RSS :)
Jul 02
prev sibling next sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 7/1/20 3:19 AM, Cym13 wrote:
 As some of you may know one of my hobbies is to review open source 
 software for security issues. About a year ago I reviewed the RSA 
 implementation of Crypto[1]: a native D library which, according to dub 
 statistics, is fairly popular.
 
 Issues were found and after discussion with the author I decided to wait 
 for them to be fixed. A year later I would like to present the results 
 of an updated review of the library:
 
 https://breakpoint.purrfect.fr/article/review_crypto_d.html
 
 Here's what you should know if you are a user:
 
 RSA, as implemented in the library, is still very much broken. I do not 
 recommend using it. The confidentiality and integrity of all messages 
 exchanged using this library must be questionned: if you exchanged 
 sensitive information such as passwords using it I recommend to change 
 them since their security is not guaranteed.
 
 “Is this really the place to have this discussion? Shouldn't this be 
 between the author and you?“
 
 The author was contacted a year ago and although our discussion was kind 
 and productive I have not heard from him since. Most of the issues 
 present today were already present in my first assessment. Some 
 modifications were made, but most recommendations were ignored. After a 
 year without action I feel that the users should know exactly what they 
 are exposed to since they are the ones affected by these security 
 issues. This follows standard vulnerability disclosure processes.
 
 For all details and analysis I direct you to the blog post. It is a 
 rather thorough and technical read so I would recommend grabbing a cup 
 of tea first.
 
 If you find any mistake or unclear parts I'll be glad to correct it so 
 feel free to point it out. Furthermore if you would like someone to have 
 a look at your project to identify issues I am always glad to help free 
 and open source projects that can't afford security review through 
 traditional means so feel free to reach out.
 
 [1] https://code.dlang.org/packages/crypto
This is a fantastic writeup, and being someone who is naturally good at math, but never really cared for it at the advanced level, I find the level of detail perfect. Thanks for the post! -Steve
Jul 01
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jul 01, 2020 at 07:19:11AM +0000, Cym13 via Digitalmars-d-announce
wrote:
[...]
 https://breakpoint.purrfect.fr/article/review_crypto_d.html
[...] Very interesting writeup indeed, thanks!
 Furthermore if you would like someone to have a look at your project
 to identify issues I am always glad to help free and open source
 projects that can't afford security review through traditional means
 so feel free to reach out.
[...] I'm not the author, but I'm curious about the D implementation of Botan (https://code.dlang.org/packages/botan) -- how is its security level? I glanced at it before and it seemed OK, but it'd be really nice to have a 3rd party opinion, esp. from someone who's skilled with cryptanalysis. T -- In theory, there is no difference between theory and practice.
Jul 04
parent reply Cym13 <cpicard purrfect.fr> writes:
On Saturday, 4 July 2020 at 14:37:41 UTC, H. S. Teoh wrote:
 I'm not the author, but I'm curious about the D implementation 
 of Botan (https://code.dlang.org/packages/botan) -- how is its 
 security level?  I glanced at it before and it seemed OK, but 
 it'd be really nice to have a 3rd party opinion, esp. from 
 someone who's skilled with cryptanalysis.


 T
I can't say much at the moment. Botan is another beast altogether and lots of work is going to be required to get any certitude. What I can say is that it's a nice library, ported from a library that has been audited in the past and is still actively maintained. A cursory shows none of the issues found in Crypto. Everything seems really good. The main issue with Botan from a design standpont may be its completeness. It's great if you are building off an established project or protocol and need specific algorithms. If you're starting a new project from scratch though more options mean more ways to potentially chose a bad one. I mentionned libsodium in a previous answer; this is the kind of opiniated library that is well suited to that type of new projects. But really, it's hard to say anything bad when the project's wiki starts with a list of books and resources to learn cryptography prior to using the library [1]. I don't know the author but at least it seems like he knows what he's messing with. So, to conclude, based on that preliminary look alone I would feel confident about recommending Botan since I don't expect any major issue. But I'll still need to find the time to properly review it someday, be it only for my own peace of mind. [1]: https://github.com/etcimon/botan/wiki
Jul 04
parent aberba <karabutaworld gmail.com> writes:
On Saturday, 4 July 2020 at 15:49:25 UTC, Cym13 wrote:
 On Saturday, 4 July 2020 at 14:37:41 UTC, H. S. Teoh wrote:
 I'm not the author, but I'm curious about the D implementation 
 of Botan (https://code.dlang.org/packages/botan) -- how is its 
 security level?  I glanced at it before and it seemed OK, but 
 it'd be really nice to have a 3rd party opinion, esp. from 
 someone who's skilled with cryptanalysis.
[...] So, to conclude, based on that preliminary look alone I would feel confident about recommending Botan since I don't expect any major issue. But I'll still need to find the time to properly review it someday, be it only for my own peace of mind. [1]: https://github.com/etcimon/botan/wiki
The README also mentions one should submit algorithmic issues to the C++ tracker. Seems there's quite a number of reported bugs which may or may not affect the D side. https://github.com/randombit/botan/issues
Jul 04