Re: Blowfish Sign Extension implementation risk
From: Tom St Denis (tom_at_securescience.net)
Date: 04/30/04
- Next message: Tom St Denis: "Re: Jacobi test algorithm."
- Previous message: Rob Warnock: "Re: Getting random numbers"
- In reply to: William Wallace: "Re: Blowfish Sign Extension implementation risk"
- Next in thread: Joe Peschel: "Re: Blowfish Sign Extension implementation risk"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 30 Apr 2004 11:55:36 GMT
William Wallace wrote:
> Yes, I think you made that point twice in this thread. I haven't read
> his paper, but I have read two Dr. Dobbs articles, and two applied
> cryptography books, by Bruce. In the 2nd edition, he says:
>
> (2) XOR P1 with the first 32 bits of the key, XOR P2 with the second
> 32 bits of the key, an so on for all bits of the key (up to P18).
> Repeatedly cycle through the key bits until the entire P-array has
> been XORed with the key bits.
>
> So, you have a point. However, does your implementation follow that
> description? I highly doubt it, but it might. Specifically, this
> step says key *bits*, not key bytes. Do you allow, for example, a
> 121-bit key in your crypto library? Do you rotate key bits or key
> bytes before XORing into the P array? Or do you follow Bruce's code
> from the 2nd edition. Specifically:
>
> for(k=0;k<4;k++){
> data = (data <<8) | k[j]; /* note, 2nd edition has sign extension
> bug too */
> //...
> }
>
> Again, let me be very clear in my question: Does your implementation
> follow his written description, or the source code?
That's just my point. You're saying it must be designed to resist more
errors and I'm saying people are just implementing it wrong. I don't
except keys that are not multiple of eight bits but that's because a)
they're not practical and b) adds undue complexity to the implementation.
As for how I implemented it... I definitely didn't use his source code
as a refererence [though I think I stole the constant sboxes out of one
of them, who wants to type that over again?]. This is primarily because
my code is meant to be portable to non-big endian machines.
>>In the relevence of this thread that's a big difference.
>
>
> Maybe, maybe not. Depends on how you answer the last question.
Not really. As Blowfish was *designed* it was quite clear about how the
key schedule should work. It was *implemented* poorly perhaps.
To move this into an analogy... It's like taking the safest car in the
world and letting a gaggle of 12 yr olds drive it. When they get into
an accident which of the two was "unsafe"? The kids or the car?
>>You're claiming [from what I gather] that Blowfish wasn't designed
>>robustly because an implementation is wrong.
>
>
> No, I claimed that the algorithm could have been designed to be more
> robust to implementation errors than it was, as was one of the stated
> goals (see Dr. Dobbs, April, 1994). You have a point that I might be
> including Bruce's de facto reference implementation as part of the
> algorithm description, since the algorithm, as it is available to the
> mainstream, was published with C source code (again, see Dr. Dobbs,
> Applied Cryptography, etc.).
Ok. But then XOR doesn't fix the problem. Specially considering on
platforms where the byte isn't sign extended [e.g. non-C].
And actually the source may be in the Dr. Dobbs journal but it isn't in
the paper I read [nor the section of AC2]. To me "the specification"
doesn't include the C code.
>>I'm simply stating that the implementation is wrong and the design [while
>>terse and lacking test vectors] is correct.
>
>
> Good point. But I am interested, is your implementation correct? Do
> you shift in key bits? Or do you interpret (2) above to mean that the
> key must be mod 32 bits? Or did you look at the C source code
> provided by Bruce for a clue?
Um, I didn't need a clue from Bruce to use keys that are k == 0 mod 8.
I did that for all dozen or so ciphers I wrote for LibTomCrypt.
We had this argument with the hashes where one guy claimed if your hash
code doesn't support BIT messages it was wrong. That guy died or
something... so sad.
Of course now we're venturing into another topic. Is added complexity
to support things people won't use a good thing? I happen to think not.
But who am I...
Tom
- Next message: Tom St Denis: "Re: Jacobi test algorithm."
- Previous message: Rob Warnock: "Re: Getting random numbers"
- In reply to: William Wallace: "Re: Blowfish Sign Extension implementation risk"
- Next in thread: Joe Peschel: "Re: Blowfish Sign Extension implementation risk"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
