10 ms·

^^^^^^. This x1000. Yes, it's bad when bureaucracy means that individual bad decisions are made. But casually saying "oh, well, this is idiocy, the government

^^^^^^. This x1000. Yes, it's bad when bureaucracy means that individual bad decisions are made. But casually saying "oh, well, this is idiocy, the government doesn't care about security" ignores the fact that organizing the regulation of human behavior is immensely costly, and the government needs to optimize on those costs. A good dev analogy is using a library function vs rolling your own. The government's library is the list of things that its own engineers approved. The equivalent of rolling their own is for some individual auditor to make an independent decision to deviate from the list. Now, it might be that you can squeeze out an extra tiny bit of performance[/the government can squeeze out some extra security] by rolling your own sort function or whatever, but most wise devs will balance that off against the risk of introducing extra bugs, the extra writing and maintenance time involved, etc. Reality is that this sucks. It would be amazing if it wasn't actually super-super costly to organize human beings to all point in the same direction and make sure that people don't cheat. Government would be a lot cheaper and more efficient. But, alas, reality does suck.

richardwhiuk 6y ago
Yeah - utterly agree. The point raised in the article is valid - but the correct thing to do isn't to persuade the auditor they are wrong, it's to push FIPS to include bcrypt instead of SHA2 (although as below, this isn't the right answer either - it should use PBKDF2 or similar).
- renewiltord 6y ago
  No, the right answer is to push no one on anything, comply with the FIPS standard and suck up the marginally increased probability of a breach. They made the right decision throughout.
- Nullabillity 6y ago
  You could also consider it a M&M test for both FIPS and the auditor. If they get something this simple wrong, what other issues lay hidden?
- tptacek 6y ago
  FIPS is never going to include bcrypt. Not including things like bcrypt is literally part of the point of FIPS.
  - wool_gather 6y ago
    Which aspects of bcrypt are you referring to by "things like bcrypt"?
    - tptacek 6y ago
      Modern, superior alternatives to standard algorithms and constructions. Canonical example: Curve25519. WireGuard, for instance, will never be FIPS compatible.
      - loup-vaillant 6y ago
        How then, can refusing superior alternative be anyone's point? Are you merely calling them overly conservative to the point of incompetence (I'd be tempted to), or is there another aspect to it?
        yencabulator 6y ago
        One angle to consider here is that FIPS is informed by whatever NSA knows about cryptography, so not all the evaluation criteria is public. You and I may think djb's inventions are superior, but for example NSA might have an active research project into elliptic curves, and refused to endorse Curve25519 until those results came in.
      - NovemberWhiskey 6y ago
        Don't the drafts for NIST FIPS 186-5 and SP 800-186 both include Curve25519-based algorithms?
        SAI_Peregrinus 6y ago
        They do. This person doesn't know what they're talking about. The point of FIPS is to provide a set of approved algorithms (and other standards) that are considered to be secure due to thorough analysis. Curve25519 has become widely implemented, and hasn't been broken, and has some advantages over the other NIST-approved curves, so NIST will likely approve it. Password hashing has been rapidly changing over the last few years. PBKDF2 isn't memory-hard, but can be instantiated with only a FIPS-approved cryptographic hash. Bcrypt is OK, Scrypt has different tradeoffs, Argon2 has different tradeoffs (and even more tweakability with multiple variants), Pufferfish2 is cache-hard instead of just memory hard (so potentially better than any of the only-memory-hard systems), etc. NIST probably don't see any reason to update the standard for a marginal improvement when they can wait for the cryptographic research in the area to stabilize. There's also a lot of research into ways to avoid having to send passwords to servers in the first place with strong asymmetric password-authenticated key exchange (sAPAKE) algorithms. So NIST might end up standardizing a password-based key derivation function separately from a PAKE system. Personally I think standards should be updated a bit more frequently than they are, but I can understand NIST's conservative stance here.
darkerside 6y ago
Great analogy. It is a frustrating end result in this case. I wonder if there's any possibility for escalating this to a regulator's technical resources? I wonder if this kind of thing is typically left to the auditor discretion.
jl6 6y ago
Yep. That which is globally optimal may be locally suboptimal.
bjeds 6y ago
I feel bad for the author for publishing this article. If your (the author) mindset is that "everyone else is an idiot", be it management, or regulators, auditors or some other group that is not your group (engineer?), then unfortunately you have an attitude problem. If furthermore you maliciously misinterpret the other group, saying "they want us to be compliant, not secure", based on misunderstanding the domain expertise _of your own group_ (!), then you are a liability to your business and should be kept at arms length from external auditors. Because the author clearly has no clue what he is doing, and based on his technical shortcomings he is speaking down on others who are _actually_ doing their job correctly: the auditors. Why is the author comparing bcrypt using 32 iterations with sha512crypt with 5000 iterations? Why not increase the sha512crypt iteration count by orders of magnitude if he want the hashcat test to fair equal or better under the testing methodology in use? Why is he using hashcat and basing decisions solely on that tool? Why is he using shacrypt at all and not a a proper KDF, such as PDKDF2, plugging in SHA2?
- feoren 6y ago
  You're criticizing the author for not adequately understanding the regulatory concerns but letting the regulators off the hook for not adequately understanding the engineering concerns. Frankly the latter feels more important and more beneficial (to everyone) to improve upon.
  - CaptArmchair 6y ago
    The author didn't relate how the exact conversation went down. The closest we get is this: > But the auditors were adamant. They did not care that the approved algorithms were weaker. Nothing would change their decision. That's the 100% the author's perspective. It's quite possible those auditors were aware of the existence of bcrypt and what it does. Even so, their personal opinions simply didn't matter. And they, quite likely, tried to point this out to the author. Yes, a stronger algorithm - bcrypt - existed, but as long as it wasn't a formally vetted FIPS approved algorithm, it simply wasn't an option for operational use. Compliance isn't bad in itself. It's a tool. Compliance is implemented to ensure that large and complex organizations can continue to function as a structured system. It helps ensure accountability, audit-ability, integrity, reliability, sustainability and other "abilities". There is a trade-off, though, when it comes to day-to-day operations. You simply can't improvise. In a large organisations, that's a good thing, which the author clearly hasn't understood. While the direct result is that their systems security is now weaker, that same compliance also shields them from any legal repercussions. If those systems get compromised, they can always point to the list of sanctioned algorithms and the oversight. That's how accountability works. You'll find the freedom and the flexibility to implement your own solutions in smaller organizations. However, that comes at a price: The buck stops at your desk. When something breaks, all eyes will turn to you in order to fix it. And there will be little to hide from. Of course, I'm well aware that there's more nuance to it. There are plenty of stories on both sides of the aisle were the lack of or very existence of formalisms either saved the day or directly lead to catastrophe. That doesn't imply that one is always better then the other.
throwaway316943 6y ago
You make government cheaper and more efficient the same way you do with code, by removing as much as possible.
- eximius 6y ago
  Cheaper is not always better.
  - sli 6y ago
    Likewise, neither is smaller. Code golf is just for fun.
tw25543818 6y ago
I think your analogy misses the most important benefit: you must use the government's library. If people were allowed to choose other libraries, then they might choose wrong. And since the government protects companies from the consequences of making bad choices, the government can't let them make those choices. The great failing of so many here is that they don't recognize that uniformity and centralization are more important than innovation. If those innovations really are better, then you can vote to elect representatives to nominate regulators to eventually change the requirements. This is how things work in a civilized society.

richardwhiuk 6y ago

Yeah - utterly agree. The point raised in the article is valid - but the correct thing to do isn't to persuade the auditor they are wrong, it's to push FIPS to include bcrypt instead of SHA2 (although as below, this isn't the right answer either - it should use PBKDF2 or similar).

renewiltord 6y ago
No, the right answer is to push no one on anything, comply with the FIPS standard and suck up the marginally increased probability of a breach. They made the right decision throughout.
Nullabillity 6y ago
You could also consider it a M&M test for both FIPS and the auditor. If they get something this simple wrong, what other issues lay hidden?
tptacek 6y ago
FIPS is never going to include bcrypt. Not including things like bcrypt is literally part of the point of FIPS.
- wool_gather 6y ago
  Which aspects of bcrypt are you referring to by "things like bcrypt"?
  - tptacek 6y ago
    Modern, superior alternatives to standard algorithms and constructions. Canonical example: Curve25519. WireGuard, for instance, will never be FIPS compatible.
    - loup-vaillant 6y ago
      How then, can refusing superior alternative be anyone's point? Are you merely calling them overly conservative to the point of incompetence (I'd be tempted to), or is there another aspect to it?
      - yencabulator 6y ago
        One angle to consider here is that FIPS is informed by whatever NSA knows about cryptography, so not all the evaluation criteria is public. You and I may think djb's inventions are superior, but for example NSA might have an active research project into elliptic curves, and refused to endorse Curve25519 until those results came in.
    - NovemberWhiskey 6y ago
      Don't the drafts for NIST FIPS 186-5 and SP 800-186 both include Curve25519-based algorithms?
      - SAI_Peregrinus 6y ago
        They do. This person doesn't know what they're talking about. The point of FIPS is to provide a set of approved algorithms (and other standards) that are considered to be secure due to thorough analysis. Curve25519 has become widely implemented, and hasn't been broken, and has some advantages over the other NIST-approved curves, so NIST will likely approve it. Password hashing has been rapidly changing over the last few years. PBKDF2 isn't memory-hard, but can be instantiated with only a FIPS-approved cryptographic hash. Bcrypt is OK, Scrypt has different tradeoffs, Argon2 has different tradeoffs (and even more tweakability with multiple variants), Pufferfish2 is cache-hard instead of just memory hard (so potentially better than any of the only-memory-hard systems), etc. NIST probably don't see any reason to update the standard for a marginal improvement when they can wait for the cryptographic research in the area to stabilize. There's also a lot of research into ways to avoid having to send passwords to servers in the first place with strong asymmetric password-authenticated key exchange (sAPAKE) algorithms. So NIST might end up standardizing a password-based key derivation function separately from a PAKE system. Personally I think standards should be updated a bit more frequently than they are, but I can understand NIST's conservative stance here.

darkerside 6y ago

Great analogy. It is a frustrating end result in this case. I wonder if there's any possibility for escalating this to a regulator's technical resources? I wonder if this kind of thing is typically left to the auditor discretion.

jl6 6y ago

Yep. That which is globally optimal may be locally suboptimal.

bjeds 6y ago

I feel bad for the author for publishing this article. If your (the author) mindset is that "everyone else is an idiot", be it management, or regulators, auditors or some other group that is not your group (engineer?), then unfortunately you have an attitude problem. If furthermore you maliciously misinterpret the other group, saying "they want us to be compliant, not secure", based on misunderstanding the domain expertise _of your own group_ (!), then you are a liability to your business and should be kept at arms length from external auditors. Because the author clearly has no clue what he is doing, and based on his technical shortcomings he is speaking down on others who are _actually_ doing their job correctly: the auditors. Why is the author comparing bcrypt using 32 iterations with sha512crypt with 5000 iterations? Why not increase the sha512crypt iteration count by orders of magnitude if he want the hashcat test to fair equal or better under the testing methodology in use? Why is he using hashcat and basing decisions solely on that tool? Why is he using shacrypt at all and not a a proper KDF, such as PDKDF2, plugging in SHA2?

feoren 6y ago
You're criticizing the author for not adequately understanding the regulatory concerns but letting the regulators off the hook for not adequately understanding the engineering concerns. Frankly the latter feels more important and more beneficial (to everyone) to improve upon.
- CaptArmchair 6y ago
  The author didn't relate how the exact conversation went down. The closest we get is this: > But the auditors were adamant. They did not care that the approved algorithms were weaker. Nothing would change their decision. That's the 100% the author's perspective. It's quite possible those auditors were aware of the existence of bcrypt and what it does. Even so, their personal opinions simply didn't matter. And they, quite likely, tried to point this out to the author. Yes, a stronger algorithm - bcrypt - existed, but as long as it wasn't a formally vetted FIPS approved algorithm, it simply wasn't an option for operational use. Compliance isn't bad in itself. It's a tool. Compliance is implemented to ensure that large and complex organizations can continue to function as a structured system. It helps ensure accountability, audit-ability, integrity, reliability, sustainability and other "abilities". There is a trade-off, though, when it comes to day-to-day operations. You simply can't improvise. In a large organisations, that's a good thing, which the author clearly hasn't understood. While the direct result is that their systems security is now weaker, that same compliance also shields them from any legal repercussions. If those systems get compromised, they can always point to the list of sanctioned algorithms and the oversight. That's how accountability works. You'll find the freedom and the flexibility to implement your own solutions in smaller organizations. However, that comes at a price: The buck stops at your desk. When something breaks, all eyes will turn to you in order to fix it. And there will be little to hide from. Of course, I'm well aware that there's more nuance to it. There are plenty of stories on both sides of the aisle were the lack of or very existence of formalisms either saved the day or directly lead to catastrophe. That doesn't imply that one is always better then the other.

throwaway316943 6y ago

You make government cheaper and more efficient the same way you do with code, by removing as much as possible.

eximius 6y ago
Cheaper is not always better.
- sli 6y ago
  Likewise, neither is smaller. Code golf is just for fun.

tw25543818 6y ago

I think your analogy misses the most important benefit: you must use the government's library. If people were allowed to choose other libraries, then they might choose wrong. And since the government protects companies from the consequences of making bad choices, the government can't let them make those choices. The great failing of so many here is that they don't recognize that uniformity and centralization are more important than innovation. If those innovations really are better, then you can vote to elect representatives to nominate regulators to eventually change the requirements. This is how things work in a civilized society.