[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MD5

From: David Ayers
Subject: Re: MD5
Date: Fri, 24 Jan 2003 11:13:13 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212

Hi Manuel,
hi Richard

Manuel Guesdon wrote:


On Thu, 23 Jan 2003 12:44:59 +0100 David Ayers <d.ayers@inode.at> wrote:
>| I don't think the issue right now is "how" to implement it (because with >| yours we now seem to have three implementations) but rather "where". >| But let me get back to "how" anyway. I think the following API would be >| usefull >| >| @interface NSData (MD5)
>| - (NSData *)md5Digest; /* This method actually implements the calculations*/

seems good.

Currently base exports -(NSData *)MD5Digest (but personnally I would have preferred md5Digest :-)...)

>| - (NSString *)md5StringUsingEncoding: (NSStringEncoding) enc;

MD5 strings are usually encoded as done in GSCryptBase.m: DataToHexString (be 
carefill to checkout last version .There
was a bug on previous versions).
There's no need for encoding. so I'll prefer using name like: 

(Yes, Richard made me aware of that also :-) ) The gsweb patch I posted yesterday still refered to DataToHexSting, but I didn't have to link it agains gscrypt for some strange reason. So I guess I left a runtime error. :-( (I didn't see a compiler warning using 3.2.1 either, but I think I noticed that before.)

>| - (NSString *)md5String; /* uses default encoding.*/

==> md5DigestHexString.

Yes something like this what would be very convienient. All we would *really* need is an NSData category that returns the contents in a hex representation. This is already done in a way by the plist representation but not in a format that is usable as URL's or as a comparison for check md5 check sums. In fact I'm wondering whether there should be some parameter denoting the format (capitol vs. lower case letters / prepending bytes with ' 0x' or not) but that would only be interesting for NSData. All we would need for md5 digests are capital letters.

>| @end
>| >| @interface NSString (MD5)
>| - (NSString *)md5StringUsingEncoding: (NSStringEncoding) enc;

==> md5DigestHexString.

Carefull! Here we would need the encoding because the string recieving the message would have to turned into NSData before it gets digested.

>| - (NSString *)md5String; /* uses default encoding.*/

==> md5DigestHexString.

OK, this would use the default encoding to produce the NSData.

The names sound sane, and I'm not too emotional about them. I would just like to know, Richard, if you agree this to be plausible and whether you are allready doing something in this respect. If it's acceptable but you just don't have the time currently, I'll gladly get to it. I just want to avoid duplicating the work. (BTW: what should we do with md5.c/h in base currently as you seem to have used yet another md5 implementation within GSCategories.m)

>| But more importantly is where these Categories should go:
>| >| 1. base/Additions

base/Additions seems a good place.

>| 2. gscrypt - well actually I wouldn't change the existing >| implementation, I would just try handling the pam_-problem transparently >| with LIBRARY_DEPENDS_UPON or/and configure.

The best way I see for this is to add a configure so pam part can be ignored.

I'll do this on monday.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]