• Cym13 (34/34) Jul 01 2020 As some of you may know one of my hobbies is to review open
• Arafel (13/54) Jul 01 2020 As somebody who also was somewhat involved in infosec and cryptography
• Cym13 (5/19) Jul 01 2020 Fixing the issues from the article would require a huge amount of
• Dukc (14/22) Jul 01 2020 Thanks for the article. IMO it was as clear for non-professionals
• Cym13 (31/55) Jul 01 2020 There's one more element missing here: the protocol. Cryptography
• sarn (10/34) Jul 02 2020 Some people don't want to hear all that because implementing
• Steven Schveighoffer (6/47) Jul 01 2020 This is a fantastic writeup, and being someone who is naturally good at
• H. S. Teoh (12/17) Jul 04 2020 [...]
• Cym13 (23/29) Jul 04 2020 I can't say much at the moment. Botan is another beast altogether
• aberba (5/17) Jul 04 2020 The README also mentions one should submit algorithmic issues to

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

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.

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.

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?

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

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

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

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

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

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