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: Sat, 30 Mar 2002 13:50:07 +0100
In response two to posts..
On Friday, March 29, 2002, at 05:01 PM, cocoa-dev-
email@hidden wrote:
> 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]
The way around it would be to use a stream cipher (e.g. RC4), but
that's not necessary and has its own set of trade-off's that's
often more ugly. A common trick is to encode the padding length
in the pad itself. Often, you're just going to know the length
from other sources. Or it may just be that you know (or can
define) that 0x1 - 0x7 (where '7' here is the cipher block
length - 1) isn't valid as the last byte.
So if len is an exact multiple of the cipher block length, or
data[len] > 0x7 (in this case), you're done. Otherwise, you look
in the last byte of the decrypted data to determine the length of
the pad. This also enables you use random length pads (i.e., pads
which are > 1 x (cipher block length - 1) bytes). Such padding
can deter chosen plaintext attacks but is rarely used in practice.
Slight bug here, as you can't really know if the last byte is
meaningful as the cipher block length, since the encrypted length
will always be block size. For incoming data that "fits" one would
need an extra block, which I think isn't so bad at all.
Am Samstag den, 30. Mdrz 2002, um 02:37, schrieb Andy Lee:
At 8:41 PM +0100 3/29/02, Nat! wrote:
(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]
How about this: put the size of the padding at the end of the data
before encrypting it. Instead of padding by 0-7 null bytes, pad
by 1-8 random bytes, and put the pad size in the last three bits
of the last byte. Then after decrypting, you can read those three
bits to tell how many bytes to chop off the end.
Today I wrote code that does almost this, but pads with zeros,
which after reading your comment I realized is bad. I will change
my code shortly to use random bits in the padding (except for the
last three, of course). Seems like this should solve the
problem -- or am I mistaken?
Yes sounds good, especially the random padding. Together with the
size bits that's superior than padding with zeroes. I am pondering
if I should make a convenience method for that in MulleCipher. Or
maybe I will make this the default modus operandi and put the "raw"
encryprtion/decryption in an underbar method ? Hmmm....
(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.
Couldn't another thread muck with the NSMutableData that is being
encrypted, during the encryption process? That was what I was
thinking.
Yeah but that's a property of Foundation. When you write
"MulleCipherBlowfish is not threadsafe" people get the idea that
the algorithm/wrapper itself is thread unsafe. This is not the
case, as long as you don't have two threads trying to
encrpyt/decrypt the same data inplace, which is I think an
uninteresting scenario. :)
Cheers
Nat!
P.S. Thanks both of you for the feedback!
------------------------------------------------------
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.