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

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.

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.

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?

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".

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

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 :)

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.

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

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