Hi,

After writing my own version of the md5 algo, then discovering the std.md5 implementation, I thought I would ask peoples thoughts on which version they prefer and why. Mainly to discover what I have done right/wrong when I wrote it.

So if anyone is interested I am attaching my source.

Comments of all shapes and sizes are desired and most welcome, particularly...

- The fact that I have used a class and std.md5 uses a struct. - The naming of the functions.

std.md5 does have a 'sum' function which I do not, one could be added trivially.


I think I made some mistakes, for example:

- My functions take char[] whereas std.md5 takes void[]
- my digest is a char[] std.md5 uses a ubyte[]

..etc..

Anything you say, can and will be used.. to enable me to write better D code!

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

In article <opr872elh35a2sq9@digitalmars.com>, Regan Heath says...
>
>- My functions take char[] whereas std.md5 takes void[]
>- my digest is a char[] std.md5 uses a ubyte[]

char is most definitely the wrong type. A char stores a fragment of a UTF-8 encoded character stream. You need a ubyte.

But it's nice to find someone else interested in crypto things. If you craft any other hash functions (the rest of the MD- family, the SHA- family, the new Tiger algorithm, and so on) there will definitely be a place for them in the forthcoming etc.crypto heirarchy. (We might have to haggle over the API a little). :-)

Arcane Jill

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:ca1mnp$2p58$1@digitaldaemon.com...
> But it's nice to find someone else interested in crypto things. If you
craft any
> other hash functions (the rest of the MD- family, the SHA- family, the new
Tiger
> algorithm, and so on) there will definitely be a place for them in the
> forthcoming etc.crypto heirarchy. (We might have to haggle over the API a
> little). :-)

I haven't added the SHA (Secure Hash Algorithm) because the description of the algorithm says implementations need an export license. I don't know if this is obsolete or not, as there are SHA implementations all over the web, but I prefer that phobos not be encumbered with such problems.

In article <ca2brg$oaj$2@digitaldaemon.com>, Walter says...
>
>I haven't added the SHA (Secure Hash Algorithm) because the description of the algorithm says implementations need an export license.

Sensible, but as it happens your information is out of date. US export restrictions on cryptography were relaxed in September 1998, and dropped altogether in January 2000.

Put it like this. You know when you connect to an https:// web site, and you get all that malarky with security certificates, and maybe a little padlock icon in the corner of your browser if you're lucky? Well that's SSL, and the SSL protocol includes an implementation of SHA-1. If SHA is illegal in your country, then there must be an AWFUL lot of lawbreakers around, including Microsoft, Netscape, ....

Anyway, I don't live in the US, so those dumb rules never did apply to me. It always made me laugh that the US was not allowed to export to me that which I already had. (I could export it to them!)


>I don't know if
>this is obsolete or not, as there are SHA implementations all over the web,
>but I prefer that phobos not be encumbered with such problems.

Sounds like a job for Deimos then. The crypto community at large WANT easy-to-use implementations of TLS (that's the successor to SSL) out there, because apparently OpenSSL is just too damn hard to use. This is my goal, and I shall achieve it in D, and I will have to write an AWFUL lot of stuff to get there (big integers were just the start), but I will succeed.

Of more concern is the fact that Hans Dobbertin has demonstrated a weakness in MD5 which now makes it unsuitable for serious crypto. There is every possibility that it might be broken in the next few years. SHA-256 is the hashing algorithm of choice these days.

To be honest, it hadn't occured to me that you might have put SHA in Phobos but didn't. I largely figured I would be doing all the work myself anyway. But then, I guess I'm still hoping that (the forthcoming) etc.crypto may eventually become std.crypto...

:-)
Jill

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:ca2e0r$rmg$1@digitaldaemon.com...
> In article <ca2brg$oaj$2@digitaldaemon.com>, Walter says...
> >
> >I haven't added the SHA (Secure Hash Algorithm) because the description
of
> >the algorithm says implementations need an export license.
>
> Sensible, but as it happens your information is out of date. US export restrictions on cryptography were relaxed in September 1998, and dropped altogether in January 2000.

That's good news.

> Put it like this. You know when you connect to an https:// web site, and
you get
> all that malarky with security certificates, and maybe a little padlock
icon in
> the corner of your browser if you're lucky? Well that's SSL, and the SSL protocol includes an implementation of SHA-1. If SHA is illegal in your
country,
> then there must be an AWFUL lot of lawbreakers around, including
Microsoft,
> Netscape, ....

It was legal to use it, just not export it. That's why many software boxes got marked 'not for export'. Of course, it was absurd to think that this actually prevented anyone outside the country from getting it.

> Anyway, I don't live in the US, so those dumb rules never did apply to me.
It
> always made me laugh that the US was not allowed to export to me that
which I
> already had. (I could export it to them!)

It had the effect of forcing US software companies to have a separate export product that was cryptographically crippled, putting them at a serious disadvantage to foreign competitors who of course had strong encryption.

> >I don't know if
> >this is obsolete or not, as there are SHA implementations all over the
web,
> >but I prefer that phobos not be encumbered with such problems.
>
> Sounds like a job for Deimos then. The crypto community at large WANT easy-to-use implementations of TLS (that's the successor to SSL) out
there,
> because apparently OpenSSL is just too damn hard to use. This is my goal,
and I
> shall achieve it in D, and I will have to write an AWFUL lot of stuff to
get
> there (big integers were just the start), but I will succeed.
>
> Of more concern is the fact that Hans Dobbertin has demonstrated a
weakness in
> MD5 which now makes it unsuitable for serious crypto. There is every
possibility
> that it might be broken in the next few years. SHA-256 is the hashing
algorithm
> of choice these days.
>
> To be honest, it hadn't occured to me that you might have put SHA in
Phobos but
> didn't. I largely figured I would be doing all the work myself anyway. But
then,
> I guess I'm still hoping that (the forthcoming) etc.crypto may eventually
become
> std.crypto...

I hope so, too. Crypto is another of my interests, but generally not explored because I spend all my time with compilers <g>.

Maybe we will see a new break-through in cryptography if Walter has some  time for it ;-)
Something like the "Walter Hash"...

Walter wrote:
> 
> 
> I hope so, too. Crypto is another of my interests, but generally not
> explored because I spend all my time with compilers <g>.
> 
> 

Sadly, I don't have a good enough math background to pretend I can advance that field.

"Stephan Wienczny" <wienczny@web.de> wrote in message news:ca2i7u$126p$1@digitaldaemon.com...
> Maybe we will see a new break-through in cryptography if Walter has some
>   time for it ;-)
> Something like the "Walter Hash"...
>
> Walter wrote:
> >
> >
> > I hope so, too. Crypto is another of my interests, but generally not explored because I spend all my time with compilers <g>.
> >
> >

On Mon, 7 Jun 2004 12:23:21 +0000 (UTC), Arcane Jill <Arcane_member@pathlink.com> wrote:
> In article <opr872elh35a2sq9@digitalmars.com>, Regan Heath says...
>>
>> - My functions take char[] whereas std.md5 takes void[]
>> - my digest is a char[] std.md5 uses a ubyte[]
>
> char is most definitely the wrong type. A char stores a fragment of a UTF-8
> encoded character stream. You need a ubyte.

Yep... I realise that now :)

> But it's nice to find someone else interested in crypto things. If you craft any
> other hash functions (the rest of the MD- family, the SHA- family, the new Tiger
> algorithm, and so on) there will definitely be a place for them in the
> forthcoming etc.crypto heirarchy. (We might have to haggle over the API a
> little). :-)

I am such a newbie at crypto that I doubt I'll be much use, that won't stop me from having a go of course! (when I find the time)

I'll let you know what I'm gonna try next, when I decide what that is.

Regan.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/