Talk:Blowfish (cipher)

From Wikipedia, the free encyclopedia

WikiProject on Cryptography This article is part of WikiProject Cryptography, an attempt to build a comprehensive and detailed guide to cryptography on Wikipedia. If you would like to participate, you can choose to edit the article attached to this page, or visit the project page, where you can join the project and see a list of open tasks.
WikiReader Cryptography It is intended that this article be included in WikiReader Cryptography, a WikiReader on the topic of cryptography. Help and comments for improving this article would be especially welcome. A tool for coordinating the editing and review of these articles is the daily article box.
To-do list for Blowfish (cipher):

Here are some tasks you can do:
    Priority 3  

    Contents

    [edit] Endianness

    Anyone inclined to talk about endianness issues with implementations? Including efficiency questions about using htonl() and ntohl() or equivalent?

    [edit] Disambiguation?

    Isn't a blowfish a kind of, well, fish? And what about Hootie and the?

    Errr, possibly, but not in my country. I guess this is the reason that the data compression algorithms are all subpages. Maybe encryption algorithms should be too, to make sure they don't clash with more mundane topics of the same name. Not a problem for RC4 and triple-Des, but there is a Tiger and a Serpent. Anyway, i just wrote this because there was an open link to it from one of the crypto pages. Better track that down and fix it if this moves.

    Added a note on the same. The fish is usually called a puffer, so the collision between the two isn't too bad. :)

    [edit] Question

    What does "symmetric, secret key, block cypher" mean? --LMS

    "symmetric, and secret key" means that it uses the same secret key for both encryption and decryption (compare public key cryptography), and "block cipher" means it encrypts data a block at a time (compare stream cipher).

    What is the time complexity of the blowfish encryption/decryption algorithm? --DWB

    Quite obviously, O(1) for a single block, O(n) for n blocks since the number of rounds is constant regardless of key size. -- intgr 22:25, 27 September 2006 (UTC)

    [edit] The removal of cryptoanalysis result by Schmidt

    On an email correspondense, I pointed out to Dieter Schmidt that the conclusion of his cryptoanalysis paper is wrong, and after this he retracted his article. The problem is, that while subkeys P3 and P4 do not depend on P1 and P2 (and this is a somewhat interesting observation), this does not mean that P3 and P4 do not depend on 64 bits of userkey. This is because the userkey bits will be cycled into the P-array, before any subkey encryptions take place. So if, for example, the userkey is 448 bits long, the first 64 bits will go to P1 and P2, and ALSO into P15 and P16. Then, P15 and P16 (and thus the first 64 bits) WILL affect the encryption iteration whose final value will be put into P3 and P4. -- 84.251.21.229 13:04, 28 August 2006 (UTC)

    Thanks for letting us know. (The paper has been withdrawn from ePrint: [1]). — Matt Crypto 13:31, 28 August 2006 (UTC)

    [edit] "Diagram on the right" isn't

    Somewhere along the line a diagram went missing. The second paragraph refers to "the diagram on the right" that describes the F-function, but there is only one diagram. --Joe Sewell 20:58, 27 September 2006 (UTC)

    I can see two diagrams - one on the right in the infobox, and the other on the left under the "The algorithm" section. This particular paragraph refers to the image in the infobox. Now that I see it, I agree that it can be confusing. Unfortunately, moving infobox around is out of the question, and duplicating the image would be silly as well. Any ideas how to improve it? -- intgr 22:16, 27 September 2006 (UTC)

    [edit] Why is this algorithm called 'blowfish'?

    If I look at the image, I would think it's called 'blowfish' because it blows up the plaintext while encrypting (the S-boxes have an 8-bit input and a 32-bit output). If someone knows the official reason or explanation why this algorithm is called 'blowfish', please add it to the article. --Bernard François 15:37, 15 October 2006 (UTC)

    My memory is that the analogy was to the pufferfish which defends itself well by both armed and poisonous. A good cypher algorithm would do something similar, metaphorically. Having said that, however, I can't connect it to any particular source, and so I'm not sure it belongs in the article. ww 02:18, 16 October 2006 (UTC)
    Actually the pufferfish is also called blowfish. It blows itself up like a balloon to impress. The input of the S-boxes gets blown up in a similar way... --Bernard François 15:52, 5 January 2007 (UTC)

    [edit] Is the description of the Blowfish decryption right?

    Please pardon me if I am wrong, but it seems the use of P17 and P18 in the Blowfish article is misleading if not wrong. The article states:

    "Blowfish [...] can be inverted simply by XORing P17 and P18 to the ciphertext block, then using the P-entries in reverse order"

    Though it seems reasonable at the first glance, I beleive that after application of XOR to P18 and Ln (the left part of the of the ciphertext), you will NOT get the intput of the last rounds F function, which is the case in the simpliest Feistel network. Instead one gets the input scrabled by XOR with F17 (or F18, depending on how you understand the fraze "using the P-entries in reverse order"). This means that there would be not guarantee in general that the first decryption round F() xor Rn will give the correct L[n-1].

    If, instead, we just use P18 instead of P1, P17 instead of P2, and so on, in a regular Blowfish net, we will get a correct input for the last F() function in the first round (namely, Ln xor P18). The F(Ln xor P18) xor Rn will give you (L[n-1] xor P17), because xor is commutative and associative. The result will be later XORed with P17 to yield the L[n-1] in the second round -- the correct input for the second F(); by induction, one gets at the last round the correct input for the last F(), which is L0 xor P1, and by using this F() in (F() xor R1) we get (R0 xor P2) (since the xor with P2 was not yet undeone). The final XOR operation will perform (R0 xor P2) xor P2 = R0 (since we use P2 instead of P17) and (L0 xor P1) xor P1 = L0, thus reconstituting the plaintext.

    If the above is right, then the correct recomendation of how to use Blowfish should read: "use P1, P2, ..., P18 entries in reverse order to decrypt". The "XORing P17 and P18" recommendation is wrong and should be omitted. The similar wording to the one I suggest is used, by the way, by Bruce Schneier himself in his blowfish paper:

    http://www.schneier.com/paper-blowfish-fse.html

    If I my understanding is right I suggest that the article part describing Blowfish decryption is corrected accordingly...

    Sincerely, Saulius Grazulis ((grazulis) commercial-at (akl) period (lt)) 193.219.56.14

    [edit] Changed lede not to say Twofish gets more attention than Blowfish

    While Twofish did get much more attention than Blowfish during the AES process, that no longer seems to be the case: Blowfish is still interesting because it's widely used in SSH implementations and so forth, but fewer applications use Twofish and it's no longer on a standards track. If this seems incorrect, revert. 75.24.110.218 21:44, 22 July 2007 (UTC)

    [edit] sign extension bug

    The sign extension bug existed as early as 1994 (Dr. Dobb's Journal) and as late as 2004 (from the code available at Schneier.com) and was confirmed by Schneier and his employees. The sign extension bug is quite serious for keys chosen at random. (No problem for ASCII keys, though, due to no sign extension of ASCII characters). Ra2007 (talk) 20:54, 10 December 2007 (UTC)

    Just checked, although the sign extension bug has been confirmed at various places, the source code credited to Bruce Schneier at schneier.com still has the sign extension bug http://www.schneier.com/code/bfsh-sch.zip even today (12-10-2007). The ohter links above should help confirm that this is a real bug and provide sources. Ra2007 (talk) 21:00, 10 December 2007 (UTC)

    [edit] Advising against Blowfish?

    "Bruce Schneier now advises against the use of Blowfish, and recommends using Twofish instead."

    I think this sentence should be cleaned up - it doesn't appear to be accurately referencing its source.

    Bruce Schneier does comment that he recommends Twofish instead. However he only indicates that he's "amazed" that Blowfish is still being used -- he doesn't explicitly state nor imply that Blowfish should not be used. Offering an up-to-date alternative is not an advisory against using the still-secure Blowfish algorithm.

    This sentence should be cleaned up for clarity and for the sake of faithful referencing. —Preceding unsigned comment added by 208.65.221.154 (talk) 00:02, 6 May 2008 (UTC)

    I edited the Twofish recommendation to read in a less "Blowfish negative" fashion; I hope it now reflects more closely what Schneier said in the referenced interview. -- Rydra Wong (talk) 05:00, 6 May 2008 (UTC)