3

OWASP ASVS 3.0 V7.7 states the following:

Verify that cryptographic algorithms used by the application have been validated against FIPS 140-2 or an equivalent standard.

Blowfish is not included in NISTs database of FIPS 140 validated modules. Has it been validated against another standard?

  • 2
    I'm not sure that it exists an FIPS 140-2 equivalent standard ! So probably **No**. – Soufiane Tahiri Feb 27 '19 at 09:48
  • That's my hunch as well. Just wanted to throw it out here in case someone with more experience than me knew about something. – Anders Frey Feb 28 '19 at 14:42
  • Why do you want this? Using Blowfish for nearly anything is a [bad idea](https://sweet32.info), and what is probably it's most widely used application, bcrypt, while not itself broken has been superseded by modern alternatives like scrypt, argon2, and balloon hashing. – Squeamish Ossifrage Apr 08 '19 at 01:51

2 Answers2

4

Blowfish is an algorithm. An algorithm isn't validated against anything. What is validated is an implementation of an algorithm.

Blowfish isn't defined by any text that calls itself a standard, as far as I know. The original paper is the closest thing to an official specification. The author has also published test vectors.

You should not use Blowfish because it is weak for some applications. Better alternatives exist: AES, CAMELLIA, ChaCha... Blowfish's main flaw is that it has a 64-bit block size, which allows some attacks with a cost of only about 4 billion calculations, like Sweet32 for DES.


You should take this particular piece of advice with a grain of salt. Having an implementation that comes with an official FIPS 140 compliance stamp is actually a bad thing! The reason is that getting the official stamp is slow and expensive, and any bug fix requires going through this process again. So having an official FIPS 140 compliance stamp practically guarantees that your code has known bugs.

Additionally, FIPS 140 comes in several levels, and level 1 only states that the implementation performs its calculations correctly when given good input. That's all. Only levels 2 and above include some security requirements. Note that the “2” in FIPS 140-2 is the version of the specification, not the level.

What is important is:

  1. Choose an algorithm that is well-known, and that is codified by some standard. This can be a government standard such as NIST publications, or an IEEE standard, or an IETF RFC, etc. Never use an in-house or recently-published algorithm. Always give the cryptographic research community a few years to try to break an algorithm before you start using it.
  2. Pay attention to the security parameters and security properties (key size, block size, resistance against common attack techniques, …). Some standards permit obsolete or deprecated choices for backward compatibility.
  3. Choose an implementation that has been, at a minimum, functionally validated against official test vectors. Preferably the implementation should come with interoperability tests that run against a well-known implementation such as the one by the author of the algorithm.
  4. Choose an implementation that has undergone a security review.
  5. Make sure that you have a process for keeping all copies of the software updated with the latest bug fixes.
Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
1

NIST is an administrative organization, and they just love anything which builds on already approved algorithms. Blowfish has never received any kind of blessing from NIST, ISO or anyone else. Most likely, this is because it did not build on a "known" construct.

When using the *fish in a production application, you can be sure that you will be blamed for not choosing some other "standard", no matter which sources you bring up to back your choice. (Having said that, I used *fish all of the time until recently)

b degnan
  • 536
  • 3
  • 8