Re: padding scheme
From: Bryan Olson (fakeaddress@nowhere.org)
Date: 02/04/03
- Next message: Gregory G Rose: "Re: Text on LFSR"
- Previous message: Dennis Ritchie: "Re: Making of analog signal with noise"
- In reply to: Kris: "Re: padding scheme"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: Bryan Olson <fakeaddress@nowhere.org> Date: Tue, 04 Feb 2003 02:06:37 GMT
Kris wrote:
> Bryan Olson wrote:
>
>>I just looked up Blowfish and found that the key can be any
>>length from 1 to 448 bits. The keying procedure uses the key
>>bits cyclically; there is no padding.
>
> Schnier's original Blowfish paper does not specify how the K-Array is
> established, to my knowledge.
There is no "K-Array" in the Blowfish specification. See:
Fast Software Encryption, Cambridge Security Workshop
Proceedings (December 1993), Springer-Verlag, 1994, pp. 191-
204.
Available at:
http://www.counterpane.com/bfsverlag.html
And posted to this group on 08 April 1994.
http://groups.google.com/groups?selm=Cny9G5.4Lz%40chinet.chinet.com
> What it does specify is how to use the
> K-Array in conjunction with the P-Array. You're correct, it uses it
> cyclically. The K-Array has up to 14 entries (32-bit words), while
> the P-Array has up to 18 entries (32-bit words), meaning that a
> cyclical design is required.
An implementation might hold the key in an array called "K", but
it's not part of the spec. As specified, Blowfish takes "a key
of at most 448 bits". The P-Array is part of the specification,
and here's what to do: "Repeatedly cycle through the key bits
until the entire P-array has been XORed with key bits."
> What we're discussing here is how to pad the actual key entries, the
> 32-bit words. I believe this is left open to implementation.
There is no such padding in Blowfish. One could view the
scheduling as padding the key to 448 bits by concatenating
copies. That view is legal because it's functionally equivalent.
Doing anything that's not equivalent will result in an incorrect
implementation. Schneier could have done a better job
specifying some things, such as bit and byte order, but nothing
functional is left to the implementer.
-- --Bryan
- Next message: Gregory G Rose: "Re: Text on LFSR"
- Previous message: Dennis Ritchie: "Re: Making of analog signal with noise"
- In reply to: Kris: "Re: padding scheme"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|