Talk:Blowfish (cipher)

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)

Another question: The article says it cannot be used with some applications. Which applications? Can anyone expand on which applications it works well with and which applications is does not work well with so I don't have to get a degree in cryptography or have a user's applications crash to find out? Thanks! -DSp —Preceding unsigned comment added by 65.126.45.70 (talk) 17:27, 18 February 2009 (UTC)

Just like it says: if the key changes a lot, you'll spend all your time handling new keys. There's no application it's insecure in, just some it's very slow in. ciphergoth (talk) 09:25, 19 February 2009 (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 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

Saulius has a point. It is definitly wrong (and misleading)! Change it. —Preceding unsigned comment added by 94.189.146.252 (talk) 22:36, 9 April 2009 (UTC)

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)

Pop culture reference

Blowfish is specifically mentioned as being used by Agent Renee Walker to encrypt data in the "9:00 p.m.-10:00 p.m." episode in season 7 of 24. --Nlaverdure (talk) 00:41, 19 March 2009 (UTC)

In my opinion they went WAY TO FAR. One thing is to "invent" in a TV-Show that you can break a "super-duper" cipher in a few seconds and without any software tool claiming your know "super hidden back doors". Another completely different thing is saying the cipher is called Blowfish and also have the character saying that he knows the inventor (this guy has a name and he's Bruce Schneier) and, last but not least claiming that Blowfish is riddled with backdoors and breakable in a few seconds! I can't even break a zip file in a "few seconds". If I was Schneier I would take serious offense to that. Up to date there is no proven attack that works with Blowfish, then Blowfish has a key size between 32bit and 448bit, so it seems to me pretty obvious that if you need to encrypt a secret you'd go for 448bit also due to the fact that for a modern CPU it makes not much difference in computational time and so why bother choosing a key of a middle size, in "24" however the FBI analyst says that it had been encrypted with a 148bit key which doesn't seem a possible number to me since it is not divisible per 8. Why do they love to screw up details so much? They could have invented a hypothetical new cipher, nobody would have argued then. Why hurting Bruce Schneier? --Legba (talk) 22:08, 24 March 2009 (UTC)

Decryption description is wrong!

Saulius has a point. It is definitely wrong (and misleading)! It's OK now. —Preceding unsigned comment added by 94.189.146.252 (talk) 22:42, 9 April 2009 (UTC)

blowfish are cute! —Preceding unsigned comment added by 69.142.12.79 (talk) 17:02, 17 June 2009 (UTC)

Link to online version of blowfish

I added the following link to the "External Links" section -- however Intgr removed it citing "Spammy Link"

• Online encode/decode of blowfish encrypted data

However I see no reason for why it should not be included. The link provides an easy way to encode/decode a message with blowfish, and it is very relevant to the subject. There are no advert or other non-relevant content on the page/site linked, and I am not owner or affiliated in any way with the site. Looking at the "linking rules" I don't see any rules which excludes from having such a link to a subject-relevant-useful-resource. Is there some history between webnet77 and wikipedia which I would be unaware of that would warrant banning of linking? User:Sorenriise 07:40, 16 December 2010 (UTC)

Addendum -- Disabled my adblocker and found that the site _does_have a banner ad -- however looks pretty light to me..., would still suggest that linking would be worth it User:Sorenriise 07:48, 16 December 2010 (UTC)

With slogans like "Webnet77 Web Hosting", "High intensity Hosting!", "Affordable Quality Hosting with Fast Friendly Service", Google ads, a flashing banner ad, etc. I'd say it's hard to make a case that the link is not spammy.

From a security point of view, this link is obviously useless for encrypting/decrypting actual messages. Not only does it go over an insecure connection, through someone else's servers, but the block cipher is only a part of cryptography — real encryption software would also need block cipher modes of operation, MAC and KDF/key strengthening. It's just a toy, hardly useful for any purpose. -- intgr [talk] 08:44, 16 December 2010 (UTC)

Yes it is a toy, and no it cannot be used for any real security purpose -- however it does illustrate the working of the algo -- im not sure what you finding more objectionable, 1) that it is an illustration and not production worthy implementation, or 2) that the site has a banner ad? -- I.e. if I could find a similar illustration without a banner ad would that be acceptable in your POW? or would the changing of the link description to "Illustration" fix objections? Some indication of what would be a good way to fix, rather than just "no-dont-like" would be great.. sorenriise [talk] 15:25, 16 December 2010 (UTC)

I object mainly because it provides no value. For such a link, it displays too much glaring affiliation and ads.

What's there to illustrate? That you get back random-looking hex digits in the output? That's worse than nothing IMO, because some people will get the false impression that hex = Blowfish and that the output is twice as long as the input. People who do know what hex is are no wiser either. -- intgr [talk] 19:00, 16 December 2010 (UTC)

448-Bit vs 576-Bit

Just a thought, but wouldn't the extra P-Values increase total meta-difficulty (Decrypting a set of hashes) so long as the number of blocks affected is random enough per key? — Preceding unsigned comment added by 174.102.78.119 (talk)

Inclusion of "Bcrypt" utility

@Widefox: Wrt this revert, why do you think this "bcrypt" encryption utility even warrants a mention on Wikipedia? Are there any reliable sources covering it? -- intgr [talk] 20:54, 31 August 2015 (UTC)

Good question intgr. To now I was ensuring I moved someone else's content from the wrong article bcrypt to the right article (here) and disambiguated it. If we delete it then the hatnote should go too. Neutral on the content itself....let's have a look...it arguably has at least one RS, so I'm happy to leave in. Widefox; talk 21:53, 31 August 2015 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Blowfish (cipher). Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20120603124940/http://www.computerworld.com.au/article/46254/bruce_almighty_schneier_preaches_security_linux_faithful/ to https://www.computerworld.com.au/article/46254/bruce_almighty_schneier_preaches_security_linux_faithful/

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 03:13, 22 July 2017 (UTC)

Weaknesses

Isn't the sentence "Blowfish provides a good encryption rate in software and no effective cryptanalysis of it has been found to date." in contradiction with the section "Weakness and successors"? Specifically, "the SWEET32 attack demonstrated how to leverage birthday attacks to perform plaintext recovery (i.e. decrypting ciphertext) against ciphers with a 64-bit block size such as Blowfish."? — Preceding unsigned comment added by 2001:67C:1220:80C:C4E7:4F99:A58F:5989 (talk) 15:09, 9 October 2017 (UTC)

Pseudo-code change and addition of a large code block

@Lion Holler: I'm a bit puzzled why you are changing the code and why those large arrays were added. Pseudo-code is supposed to be pseudo-code, it doesn't/shouldn't match a specific language. There is no need to have working C++ code in the article, same with the digits of Pi. SamStrongTalks (talk) 13:33, 1 July 2021 (UTC)

@SamStrongTalks: The Pseudo code contained mistakes, which are misleading for someone looking into the working of blowfish, indeed there is no need for functioning C++ code but the pseudo code should at least be correct in what it represents. As for the arrays, it can be useful to see how the S- and P-boxes actually look for someone interested in implementing blowfish, all the relevant information would be in one place. However they can be replaced/removed. — Preceding unsigned comment added by Lion Holler (talk • contribs) 13:45, 1 July 2021 (UTC)

@SamStrongTalks: Large arrays are removed. — Preceding unsigned comment added by Lion Holler (talk • contribs) 13:55, 1 July 2021 (UTC)

@Lion Holler: I'll be honest, I'm not familiar enough with the algorithm to actually evaluate if it has errors or not. Thanks for removing the large arrays. SamStrongTalks (talk) 13:59, 1 July 2021 (UTC)

@SamStrongTalks: If I have more time in the coming weeks I will add a more "pseudo-code like" code block. Now it is C++ as the previous code block was already very much C++ dependent.