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.

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.