View previous topic :: View next topic |
Author |
Message |
reikon
Joined: 31 Jul 2008 Posts: 7
|
Posted: Mon Feb 23, 2009 4:35 pm Post subject: Should I add an 'insecure' or 'weak' package? |
|
|
What are your thoughts on adding a package to label primitives considered to be weak or broken?
Perhaps something like:
Code: |
dcrypt.crypto.hashes.insecure.MD5
|
or
Code: |
dcrypt.crypto.hashes.weak.MD5
|
or
Code: |
dcrypt.crypto.hashes.broken.MD5
|
Would this help any of you determine which primitives are recommended for use? Feel free to also suggest alternative package names. |
|
Back to top |
|
|
glennh
Joined: 08 May 2009 Posts: 7
|
Posted: Fri May 08, 2009 4:11 pm Post subject: |
|
|
It's a shame more people aren't participating in this project. I was about to embark on coding AES in D, when to my delight, I discovered you have already done a lot of the grunt work. Thank you.
In answer to your question:
Rather than fragmenting the package further, I think it would be more helpful to add a new property to the Cipher and Hash classes and then expose it in each derived classes as a read-only property.
You could go with a bool propery, such as isSecure, but that a bit too black and white for my taste. I would prefer (since you're asking ) a ubyte property that returns trustLevel. Then you could return a more meaningful ranking, say from 0 to 5, 5 being the highest trust and 0 signaling "Do Not Use!". Another advantage of a property over moving it around in the package is that future downgrades in trusLevel would be as simple as changing the value returned on a derived class.
The reason I'm suggesting a trustLevel range over a boolean value is due in part to my feelings about MD5. IMHO, the much-published "weakness" of MD5 is more of an ivory-tower, theoretical criticism than a serious "danger" to practical day-to-day use. But assigning it a trustLevel of 4 (or 3) to satisfy the scardycats could be useful. Saying it's "week" or "insecure" is extreme, because it implies it's no better than a primitive checksum - which clearly is not even close to the reality.
Today I started playing with your MD5 and AES code in DMD 2.029 / phobos2 on linux. I didn't have to make too many changes to get it to compile - mostly some casts to satisfy the understandably missing implicit conversion from char[] from const (or immutable) char[]. I'm cherry-picking source files, not compiling the library. I'll send an email and a diff so you can see the affected areas I found. Hope it's helpful.
Thanks again for you hard work and for sharing it freely. People who haven't done this sort of thing have no idea how much sweat and time is required or how truly generous it is to give it away. |
|
Back to top |
|
|
glennh
Joined: 08 May 2009 Posts: 7
|
Posted: Fri May 08, 2009 4:19 pm Post subject: |
|
|
glennh wrote: | ... missing implicit conversion from char[] from const (or immutable) char[]. |
I meant,
missing implicit conversion from char[] to const (or immutable) char[].
but you're a sharp guy - you probably knew that. |
|
Back to top |
|
|
reikon
Joined: 31 Jul 2008 Posts: 7
|
Posted: Sat May 09, 2009 1:32 am Post subject: |
|
|
glennh wrote: | It's a shame more people aren't participating in this project. I was about to embark on coding AES in D, when to my delight, I discovered you have already done a lot of the grunt work. Thank you.
|
You're welcome
glennh wrote: |
In answer to your question:
Rather than fragmenting the package further, I think it would be more helpful to add a new property to the Cipher and Hash classes and then expose it in each derived classes as a read-only property.
You could go with a bool propery, such as isSecure, but that a bit too black and white for my taste. I would prefer (since you're asking ) a ubyte property that returns trustLevel. Then you could return a more meaningful ranking, say from 0 to 5, 5 being the highest trust and 0 signaling "Do Not Use!". Another advantage of a property over moving it around in the package is that future downgrades in trusLevel would be as simple as changing the value returned on a derived class.
|
That's an excellent idea.
glennh wrote: |
The reason I'm suggesting a trustLevel range over a boolean value is due in part to my feelings about MD5. IMHO, the much-published "weakness" of MD5 is more of an ivory-tower, theoretical criticism than a serious "danger" to practical day-to-day use. But assigning it a trustLevel of 4 (or 3) to satisfy the scardycats could be useful. Saying it's "week" or "insecure" is extreme, because it implies it's no better than a primitive checksum - which clearly is not even close to the reality.
|
Unfortunately, MD5's weaknesses have been demonstrated to be exploitable in a practical attack and were successfully used to forge an SSL certificate: http://www.win.tue.nl/hashclash/rogue-ca/
glennh wrote: |
I'll send an email and a diff so you can see the affected areas I found. Hope it's helpful.
|
Thanks. I updated my email recently, so it might be worth double checking to make sure it's sent to the correct address.
glennh wrote: |
Thanks again for you hard work and for sharing it freely. People who haven't done this sort of thing have no idea how much sweat and time is required or how truly generous it is to give it away. |
Your support is very much appreciated. |
|
Back to top |
|
|
glennh
Joined: 08 May 2009 Posts: 7
|
Posted: Sat May 09, 2009 3:03 am Post subject: md5 article |
|
|
Thank you for the link referencing the successful exploitation of md5. That definitely changes my mind regarding use of it. |
|
Back to top |
|
|
reikon
Joined: 31 Jul 2008 Posts: 7
|
Posted: Sat May 09, 2009 11:51 am Post subject: Re: md5 article |
|
|
glennh wrote: | Thank you for the link referencing the successful exploitation of md5. That definitely changes my mind regarding use of it. |
Some of the SHA-3 candidates look very promising though. |
|
Back to top |
|
|
|