On Tue, 6 Jul 2004 20:14:12 +0000 (UTC), Arcane Jill <Arcane_member@pathlink.com> wrote:

> In article <ccercg$rgi$1@digitaldaemon.com>, Walter says...
>>
>> "Regan Heath" <regan@netwin.co.nz> wrote in message
>> news:opsaouhdrl5a2sq9@digitalmars.com...
>>> I have completed SHA0, SHA1, MD4, and MD5 in addition to the existing
>>> Tiger implementation.
>>> I plan to do MD2 next, for completeness if nothing else.
>>
>> Great! But why do MD5, since it is already in Phobos?
>
> Actually, when it eventually arrives, my crypto library will need to use the
> hashing algorithms in a slightly more plug-innable form than that in which they
> exist at present. Basically, they will all need to share a common
> (to-be-defined) architecture, so having them all in the same place where I can
> get at the source code is a big plus from my point of view.
>
> For example, std.md5 doesn't allow you to manually set the initialization vector
> to arbitrary contents. Okay, that's reasonable since most people wouldn't need
> to do that, but for things like stirring entropy pools it comes in dead handy.
> To make that small change, I'd need write-access to the internals.
>
> I haven't looked at Regan's MD5 implementation (sorry - just too busy), but it's
> possible it's just a wrapper which calls std.md5. (That's what I would have
> done).

Nope.

> But I do agree that we don't actually need two separate implementations.

As do I. I did it for completeness and consistency, also it reuses a lot of existing code so it was dead simple.

Regan

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

On Tue, 6 Jul 2004 20:14:12 +0000 (UTC), Arcane Jill <Arcane_member@pathlink.com> wrote:

> In article <ccercg$rgi$1@digitaldaemon.com>, Walter says...
>>
>> "Regan Heath" <regan@netwin.co.nz> wrote in message
>> news:opsaouhdrl5a2sq9@digitalmars.com...
>>> I have completed SHA0, SHA1, MD4, and MD5 in addition to the existing
>>> Tiger implementation.
>>> I plan to do MD2 next, for completeness if nothing else.
>>
>> Great! But why do MD5, since it is already in Phobos?
>
> Actually, when it eventually arrives, my crypto library will need to use the
> hashing algorithms in a slightly more plug-innable form than that in which they
> exist at present. Basically, they will all need to share a common
> (to-be-defined) architecture

When/If you give me this I'll re-arrange the existing code into it.

> , so having them all in the same place where I can
> get at the source code is a big plus from my point of view.

This is the main reason I did it.

> For example, std.md5 doesn't allow you to manually set the initialization vector
> to arbitrary contents. Okay, that's reasonable since most people wouldn't need
> to do that, but for things like stirring entropy pools it comes in dead handy.
> To make that small change, I'd need write-access to the internals.

Mine doesn't allow this either. yet.

> I haven't looked at Regan's MD5 implementation (sorry - just too busy),

Please do, any feedback at all would be good. :)

> but it's
> possible it's just a wrapper which calls std.md5. (That's what I would have
> done). But I do agree that we don't actually need two separate implementations.
>
> Jill
>
>



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

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:ccf16k$14ta$1@digitaldaemon.com...
> In article <ccercg$rgi$1@digitaldaemon.com>, Walter says...
> >
> >"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsaouhdrl5a2sq9@digitalmars.com...
> >> I have completed SHA0, SHA1, MD4, and MD5 in addition to the existing
> >> Tiger implementation.
> >> I plan to do MD2 next, for completeness if nothing else.
> >
> >Great! But why do MD5, since it is already in Phobos?
>
> Actually, when it eventually arrives, my crypto library will need to use
the
> hashing algorithms in a slightly more plug-innable form than that in which
they
> exist at present. Basically, they will all need to share a common (to-be-defined) architecture, so having them all in the same place where I
can
> get at the source code is a big plus from my point of view.
>
> For example, std.md5 doesn't allow you to manually set the initialization
vector
> to arbitrary contents. Okay, that's reasonable since most people wouldn't
need
> to do that, but for things like stirring entropy pools it comes in dead
handy.
> To make that small change, I'd need write-access to the internals.
>
> I haven't looked at Regan's MD5 implementation (sorry - just too busy),
but it's
> possible it's just a wrapper which calls std.md5. (That's what I would
have
> done). But I do agree that we don't actually need two separate
implementations.

I'd much rather just extend std.md5 a bit than have two confusingly different versions.

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:ccf1tu$1608$1@digitaldaemon.com...
> In article <ccf16k$14ta$1@digitaldaemon.com>, Arcane Jill says...
> >In article <ccercg$rgi$1@digitaldaemon.com>, Walter says...
> >>Great! But why do MD5, since it is already in Phobos?
>
> Forgot to add. It is my personal opinion that the md5 module shouldn't
live in
> the root of std or etc, but in the same package as all the other hash algorithms, since this makes for neater, cleaner organization.
>
> As Phobos/Deimos get more and more full of useful packages, we should be
wary of
> filling up the roots with single-purpose instances of anything generic.

It's a good suggestion.

In article <ccg056$2gj1$1@digitaldaemon.com>, Walter says...
>
>I'd much rather just extend std.md5 a bit than have two confusingly different versions.

What difference does it make which one we use? There is only one MD5 algorithm, so you're talking about two different /implementations/ that's all. (Since they both give the same result, they can hardly be called "confusingly different").

Please, may I suggest we don't worry about this for now. In a few days time I'll have finished doing my Unicode stuff, and then I'll be back doing crypto. Crypto needs crypto algorithms; crypto algorithms need true random numbers; true random numbers need entropy pools ... and entropy pools need hash algorithms. I can easily look up which hash algorithms are used in SSL/TLS and let Regan know if he's missed any (but I don't think he has). I can define the required interface (probably just a common base class, or maybe they would all have to implement the same interface - this is still To-Be-Defined), and Regan says he will implement it.

At that point, we will have a very clear idea of exactly what's needed. Regan has done pretty much all of the work for all of the required algorithms, and has said he will also do the last bit too.

In the long term, I, along with you, am hoping there will be just ONE implementation of MD5 (and all the others); it will be in a package containing many other hashing algorithms, and it will start with "std".

So I really don't think we should worry about which one to keep and which one to throw away. If they both do the same job, then we should keep the one which integrates best into the larger overall framework.

I imagine that, over time, /many/ things in D are going to be improved upon. AND THIS IS A GOOD THING. When this happens, we should not be too troubled. If an original version, necessary to get things up and running to a certain degree, is supplanted by a better or more-inclusive version, we should embrace it, because THIS IS A GOOD THING. And it is usually easier (from the point of veiw of maintenance) to have related things developed in synchrony, rather than leaving one "odd one out" maintained for historical reasons.

When it comes to making D better, progress is good, and generality is good.

Would it keep everyone happy if Regan were to take your std.md5 source code, modify it to meet his/our paradigm, and retain your copyright in the source code? What would be the licensing issued involved with that?

I guess what I'm saying is, I'd hate to be stuck with a limitation purely for historical reasons. Is there any way that my requirements, and Regan's work involving MD5, could keep you happy?

Arcane Jill