Re: Was Using OpenSSL and RSA - Blowfish in ObjC and Cocoa
Re: Was Using OpenSSL and RSA - Blowfish in ObjC and Cocoa
- Subject: Re: Was Using OpenSSL and RSA - Blowfish in ObjC and Cocoa
- From: Nat! <email@hidden>
- Date: Fri, 29 Mar 2002 20:41:53 +0100
Am Mittwoch den, 27. Mdrz 2002, um 23:08, schrieb Andy Lee:
At 5:14 PM +0100 3/27/02, email@hidden wrote:
Its seems you are looking for a good ObJC/Cocoa wrapper for
Blowfish encryption method.
I discovered on the net a very good package with full source at
http://www.mulle-kybernetik.com/software/MulleCipher/
Thanks, I saw that, and I found the source for the
MulleCipherBlowfish class very instructive. It provided the
breakthrough in understanding that I needed.
I used MulleCipherBlowfish as the basis for my own Blowfish
wrapper class (which I may change to use OpenSSL, but there's no
rush right now). I have a few notes about it:
(1) The encryption logic in MulleCipherBlowfish pads the source
data with zeros, because Blowfish operates on 8-byte chunks. This
means that after decryption, you will get 0-7 extra bytes at the
end that were not part of your original data. This may not
matter, depending on your app, but if it does matter to you,
you'll have to chop those bytes off yourself.
Yes this is a property of the blowfish algorithm. There is no good
way around it AFAIK. Putting the length of the data in front of the
plaintext data is not a good idea though, because that would make
cracking easier. [Mental note: Gotta document this property]
(2) I believe there is a subtle bug at the bottom of the
MulleCipherBlowfishEncrypt() function:
[data increaseLengthBy:sizeof( lr) - n];
memcpy( p, lr, sizeof( lr));
The "p" in the call to memcpy() may have become a stale pointer as
a side effect of the preceding called to -[NSMutableData
increaseLengthBy:]. I've sent the author an email pointing this
out. The approach I take in my version is to pad the source data
before the blowfish_encrypt() loop instead of after, thus avoiding
this bug altogether.
True indeed. Due to some internal fortunate circumstances (NSData:
malloc aligning on 16 byte boundaries, and realloc not needing to
memcpy because the block boundary will not be reached), the bug
will never happen. Anyway this is fixed in the easter version,
available real soon.
(3) MulleCipherBlowfish only supports encryption of a block of
memory that you have completely in hand. This is fine for my
needs, but according to the blowfish man page, there is something
called "stream ciphers," which I'm guessing means encrypting bytes
as they come across a stream, in chunks of unpredictable size.
MulleCipherBlowfish does not support stream ciphers.
The interface isn't there but the code is, because of course I
didn't write my own blowfish code. An enterprising hacker will have
an extension on NSFilehandle up in no time :)
(4) It will be obvious from the code, but I'll just mention that
MulleCipherBlowfish is not threadsafe. It would be up to you, the
caller, to wrap it with threadsafe logic if it matters.
Fortunately, this is not necessary for my simple needs.
Apart from the sharedInstance call, which leaves a small troubled
window of time, I would at the moment boldly contest that statement.
(5) The MulleCipher code dates back to late 2000. I couldn't find
a newer version, but if there is one, my points (1)-(4) may be
irrelevant. ;)
But that's in my eyes a positive thing. When I use a reasonably
popular routine that has f.e. "Copyright 1992" on it, I get that
warm comfortable feeling of trust, that this thing is going to work.
[I upped the date to 2002 for the new bug. :) ]
Cheers
Nat!
------------------------------------------------------
Some people drink deep from the fountains of life, and
some just gargle. -- DLR
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.