Welcome to the MedLibrary.org Wikipedia Supplement on Talk:Blowfish (cipher) -- Please Click to Return to Front Page

This article is within the scope of WikiProject Cryptography, a collaborative effort to improve the coverage of Cryptography on Wikipedia. If you would like to participate, please visit the project page, where you can join the project and see a list of open tasks.

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):	· history · watch · refresh
Here are some tasks you can do:
Priority 3

Contents 1 Endianness 2 Disambiguation? 3 Question 4 The removal of cryptoanalysis result by Schmidt 5 "Diagram on the right" isn't 6 Why is this algorithm called 'blowfish'? 7 Is the description of the Blowfish decryption right? 8 Changed lede not to say Twofish gets more attention than Blowfish 9 sign extension bug 10 Advising against Blowfish? 11 "4KiB is relatively large" vs. "relatively small"

Endianness

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

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. :)

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)

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)

"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)

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)

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

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)

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)

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)

"4KiB is relatively large" vs. "relatively small"

An earlier post was reverted that changed "relatively large" to "relatively small" and the boilerplate "thanks for experimenting" template appeared on the IP address talk page. I have reinstated the reverted change. My justification for doing so is as follows.

The revert was based on a misinterpretation of the context in which the wording was placed. The sentence mentions "early smartcards" at the end, and the reverting party used this as justification for a 4KiB Blowfish implementation being referred to as "relatively LARGE," because for most smart cards, it certainly would be, as the capacity of those devices is measured in single- or double-digit kibibyte counts, and 4KiB out of a card with a 12KiB EEPROM is 1/3 of the total storage on the card. Relative to most modern embedded devices, 4KiB is very, very small. An ancient Linksys 802.11b wireless router (BEFSR11) is an excellent example, with 512KiB of ROM and 2MiB of RAM; a 4KiB Blowfish implementation, uncompressed, would consume 1/128 of the total ROM. That being a router from many years ago, newer SOHO routers often have specifications exceeding these significantly.

Given that the statement refers to the "relative" size of a 4KiB chunk of code, the question to ask is "relative to WHAT?" Given that most embedded devices that can even handle a 4KiB Blowfish implementationin the first place tend to have specifications far exceeding 4KiB of code space, I would argue that "early smartcards" (or PIC microcontrollers, or an Intel 8051, or a W65C02) are not an appropriate basis for the relative size of said chunk of code. If you disagree, please do so before reverting the edit again. Daivox (talk • contribs) 21:15, 26 June 2008 (UTC)

Since I have worked with crypto in embedded systems and happen to watch this page I should perhaps comment: Last time I worked with embedded systems was in 2000. The cars (as in automobiles) we programmed for then had 16 kilobytes of RAM and about as much ROM per node, and up to 23 such nodes in one car. They also had a main node in the car with anything from about 100 kbyte to 4 Mbyte of RAM depending on type of car. Note that that was high end luxury cars. Most cars had much less computing power than that. Similar numbers were also valid for the nodes on engines for big ships that we also programmed at the same company. Now that was 8 years ago so if Moore's law applies to computers in cars then modern cars perhaps have about 512 kbyte of RAM in the smaller nodes.

Back then we did prefer to use ciphers with a RAM footprint of tops 258 bytes or less. (258 bytes = RC4.) But I guess today Blowfish with a 4 kbyte footprint would be okay. Although compared to XTEA Blowfish has a pretty huge RAM footprint. So it depends on if you compare the size with the space available in the embedded systems or with other ciphers.

--David Göthberg (talk) 23:35, 26 June 2008 (UTC)

Perhaps the statement regarding relative size of the algorithm's implementation should be removed, leaving only the size figure; as you have stated, Blowfish is not necessarily going to be practical in very small embedded systems anyway (i.e. smart cards) and so any thoughts about embedded application should be omitted and left to the reader's imagination, with the 4KiB figure as one point of reference. Also, I've noticed that there are zero citations in the "Blowfish in practice" section, which I feel should be remedied by someone who cares more than I currently do. Who knows? I may have been arguing a moot point since there's no proof! :) Daivox (talk) 00:17, 27 June 2008 (UTC)

Yeah, simply removing the words "relatively small" is probably a good suggestion, since as you and I now have realised both "small" and "big" is true depending on what you compare with.

--David Göthberg (talk) 03:24, 27 June 2008 (UTC)

Wikipedia content modification information:

• This page was last modified on 27 June 2008, at 03:24.

Wikipedia Authorship and Review

Wikipedia content provided here is not reviewed directly by MedLibrary.org. Wikipedia content is authored by an open community of volunteers and is not produced by or in any way affiliated with MedLibrary.org.

Wikipedia Usage Guidelines

This article is licensed under the GNU Free Documentation License. It uses material from the Wikipedia article on "Talk:Blowfish (cipher)".

The URL for this specific entry is:

• http://medlibrary.org/medwiki/Talk:Blowfish_(cipher)

All Wikipedia text is available under the terms of the GNU Free Documentation License. (See Copyrights for details). Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc.