www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - deimos etc.crypto.hash update

reply Regan Heath <regan netwin.co.nz> writes:
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.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 05 2004
next sibling parent reply Regan Heath <regan netwin.co.nz> writes:
On Tue, 06 Jul 2004 11:35:27 +1200, Regan Heath <regan netwin.co.nz> wrote:

 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.


MD2 has been completed and added.
Arcane Jill: What hashing algorithm should I work on next?

Is anyone actually using this stuff. I'm adding it for the fun of it, but 
it'd be nice to know it was actually useful. :)

Regan.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 05 2004
parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 06 Jul 2004 18:21:42 +1200, Regan Heath wrote:


 On Tue, 06 Jul 2004 11:35:27 +1200, Regan Heath <regan netwin.co.nz> wrote:

 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.


 
 MD2 has been completed and added.
 Arcane Jill: What hashing algorithm should I work on next?
 
 Is anyone actually using this stuff. I'm adding it for the fun of it, but 
 it'd be nice to know it was actually useful. :)
 
 Regan.


I will be needing some of this stuff later on. Not quite ready for it yet.
Also I'll need some of the proposed crypto stuff from Jill.
-- 
Derek
Melbourne, Australia
6/Jul/04 5:28:25 PM
Jul 06 2004
parent Arcane Jill <Arcane_member pathlink.com> writes:
In article <ccdkcl$1s5c$1 digitaldaemon.com>, Derek Parnell says...


Also I'll need some of the proposed crypto stuff from Jill.


I have a "roadmap", but not really a timetable. Random number generation will
come next. Full SSL/TLS is still a long way off. Most crypto algorithms require
(true) random numbers, so it seems to me I do have to deal with randomness next.
What do you need? I can maybe adjust the plan.

(I got sidetracked by Unicode, temporarily, by the way, but I'll be back to
crypto as soon as I've got the Unicode stuff in an easily downloadable/useable
state and released the codebuilder code. Maybe a week, depending on whether I
can get past a librarian page-size problem).

Jill
Jul 06 2004
prev sibling next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <opsaouhdrl5a2sq9 digitalmars.com>, Regan Heath says...

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.

Regan


Yay! Absolutely superb! Well done.
Presumably we still need SHA-256 though. The suite won't be complete without it.

Jill




-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 06 2004
parent Regan Heath <regan netwin.co.nz> writes:
On Tue, 6 Jul 2004 07:59:09 +0000 (UTC), Arcane Jill 
<Arcane_member pathlink.com> wrote:


 In article <opsaouhdrl5a2sq9 digitalmars.com>, Regan Heath says...

 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.

 Regan


 Yay! Absolutely superb! Well done.
 Presumably we still need SHA-256 though. The suite won't be complete 
 without it.


Done. SHA-512 too! :)
What about RIPEMD?

The code may still need a little bit of a shuffle round. Some functions 
might need renaming. As an example I have a decode function that deals 
with big/little endian, it is used in the MD hashes, BUT, the same fn does 
not work in the SHA ones, instead I had to reverse the endian logic call 
it decode2 for it to work.

Regan.


 Jill




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






-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 06 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"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?
Jul 06 2004
next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
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.

Jill
Jul 06 2004
next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
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.

But that's just an opinion.
Jill
Jul 06 2004
parent "Walter" <newshound digitalmars.com> writes:
"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.
Jul 06 2004
prev sibling next sibling parent Regan Heath <regan netwin.co.nz> writes:
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/
Jul 06 2004
prev sibling next sibling parent Regan Heath <regan netwin.co.nz> writes:
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/
Jul 06 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"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.
Jul 06 2004
parent Arcane Jill <Arcane_member pathlink.com> writes:
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
Jul 07 2004
prev sibling parent Regan Heath <regan netwin.co.nz> writes:
On Tue, 6 Jul 2004 11:28:22 -0700, Walter <newshound digitalmars.com> 
wrote:


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


Consistency, plus it was dead simple as I reused all the code from md4.
Regan.

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