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

 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

 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

 hashing algorithms in a slightly more plug-innable form than that in which

 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

 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

 to arbitrary contents. Okay, that's reasonable since most people wouldn't

 to do that, but for things like stirring entropy pools it comes in dead

 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),

 possible it's just a wrapper which calls std.md5. (That's what I would

 done). But I do agree that we don't actually need two separate

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