3 ms·

I really can't see any compelling point here of why Blowfish should be avoided when the case is that its benefits panders well towards the intended means, just

I really can't see any compelling point here of why Blowfish should be avoided when the case is that its benefits panders well towards the intended means, just because there are obvious risks involved - as with all ciphers. These risks you point out exist today in one flavor or the other for AES as well; exploits loom around them, too (and to be fair, AES, too, has its fair share of dangers that Blowfish is immune to), but you seem inclined to ignore AES' case seemingly only because of its young age. Mind you, Blowfish has had its share of prying eyes, too, but I don't think that the amount of scrutiny involved in these two ciphers weighs particularly much at this point when both ciphers are still unbroken. What you're laying forth in AES' favor is really the exact same tune people sang in favor of DES 20 years ago. I find it ironic that, given Blowfish's strengths, you pass all of its use in modern software off as plain, simple vanity. Is OpenBSD's use of Blowfish vain in any way what so ever? Is interest in, or a requirement of, high performance or a compact codebase vanity? And, just to end your weird assumption, let's also be clear that I threw out examples of cryptography libraries for the surplus value of having additional choices at hand, not in any was as passing out advices on what ciphers to use for what purpose. I don't like when people imply that I'm an indoctrinating zealot.

tptacek 16y ago
(a) Yes, OpenBSD's use of Blowfish was a vanity move (outside of bcrypt, which takes special advantage of a Blowfish quirk in a setting where Blowfish's other disadvantages aren't relevant). But it's also an understandable one, since OpenBSD's adoption of Blowfish predates even Rijndael. (b) The risks of using a cipher with a 64 bit block size are simple and pragmatic, and there's almost certainly no offsetting advantages. (c) I don't understand any of the rest of your arguments. I don't think you're an "indoctrinating zealot" (at least, I don't think I think that; I don't know what you mean.) (d) Choice in cryptography is bad. This is not a 'tptacek idiosyncracy. Ferguson and Schneier's book has essentially that principal as its thesis. So do the modern crypto libraries. You seem to have some background with this material. Can you tell me about a system you've implemented that used Blowfish, or any selectable or negotiated block cipher? I'm curious (and have a follow-up question).
- hackermom 16y ago
  Some years ago I wrote custom software for voice/memo and messaging (incl. storage) for a cellphone-based intercom system used in one or more of PricewaterhouseCoopers' establishments here in Sweden. Their offices residing in public complexes prompted the concern for privacy, and they wanted a communications system of their own rather than relying on GSM intercom or buying in on other solutions available at large on the market. I chose Blowfish because I knew I could make it run faster (read: lower power consumption) than AES or any other applicable cipher, which was a priority for their handheld devices, and because I knew that it wasn't at risk of being broken.
  - tptacek 16y ago
    What cipher mode did you use, how did you establish keys, what parts of messages were encrypted vs. not encrypted (control channel, call setup, keepalives, audio frames, etc), and how did you protect integrity? (That's my followup question).
    - hackermom 16y ago
      I didn't write any protocols, didn't design any schemes in the chain of communication; the "engineers" sourced different people for different parts for obvious reasons. I wrote the ADPCM codec for the audio and the bare crypto component. My implementation allowed both EBC and CBC modes. I know keys were randomized for each handheld by the exchange every time an employee checked out a handheld.
      - tptacek 16y ago
        So basically, and excuse the snark here because I really don't think you're dumb or anything, but... you have a lot of very strong opinions about whether developers should be able to use a 17-year old 64-bit block cipher, but not a lot of opinions about anything that goes into making a block cipher construction secure. (Why did you allow ECB to be used?)
        16y ago

tptacek 16y ago

(a) Yes, OpenBSD's use of Blowfish was a vanity move (outside of bcrypt, which takes special advantage of a Blowfish quirk in a setting where Blowfish's other disadvantages aren't relevant). But it's also an understandable one, since OpenBSD's adoption of Blowfish predates even Rijndael. (b) The risks of using a cipher with a 64 bit block size are simple and pragmatic, and there's almost certainly no offsetting advantages. (c) I don't understand any of the rest of your arguments. I don't think you're an "indoctrinating zealot" (at least, I don't think I think that; I don't know what you mean.) (d) Choice in cryptography is bad. This is not a 'tptacek idiosyncracy. Ferguson and Schneier's book has essentially that principal as its thesis. So do the modern crypto libraries. You seem to have some background with this material. Can you tell me about a system you've implemented that used Blowfish, or any selectable or negotiated block cipher? I'm curious (and have a follow-up question).

hackermom 16y ago
Some years ago I wrote custom software for voice/memo and messaging (incl. storage) for a cellphone-based intercom system used in one or more of PricewaterhouseCoopers' establishments here in Sweden. Their offices residing in public complexes prompted the concern for privacy, and they wanted a communications system of their own rather than relying on GSM intercom or buying in on other solutions available at large on the market. I chose Blowfish because I knew I could make it run faster (read: lower power consumption) than AES or any other applicable cipher, which was a priority for their handheld devices, and because I knew that it wasn't at risk of being broken.
- tptacek 16y ago
  What cipher mode did you use, how did you establish keys, what parts of messages were encrypted vs. not encrypted (control channel, call setup, keepalives, audio frames, etc), and how did you protect integrity? (That's my followup question).
  - hackermom 16y ago
    I didn't write any protocols, didn't design any schemes in the chain of communication; the "engineers" sourced different people for different parts for obvious reasons. I wrote the ADPCM codec for the audio and the bare crypto component. My implementation allowed both EBC and CBC modes. I know keys were randomized for each handheld by the exchange every time an employee checked out a handheld.
    - tptacek 16y ago
      So basically, and excuse the snark here because I really don't think you're dumb or anything, but... you have a lot of very strong opinions about whether developers should be able to use a 17-year old 64-bit block cipher, but not a lot of opinions about anything that goes into making a block cipher construction secure. (Why did you allow ECB to be used?)
      - 16y ago