On the other hand, there's the FIPS-accelerationist perspective, which suggests that as more and more modern cryptography is mainstreamed irrespective of FIPS silly requirements, FIPS will itself gradually become untenable, leaving us all better off.
I'm not a cryptographer so disregard my opinions as you please, but I really like OpenSSH's approach. They just implement whatever the cryptographer community thinks is the best approach at the moment and disregard NIST and other authorities. For example they already have a post quantum key exchange as one of the default algorithms.
I'm not a cryptographer either and I certainly trust OpenSSH developers and actual cryptographers a lot mote than outdated government standards. As far as I'm concerned, what these people say is the standard and they're the people I look for when I want to learn something about cryptography from websites, LWN articles, mailing list discussions and other such sources. I've learned a lot reading about getrandom on LWN, plenty of knowledgeable people involved in that work.
This sounds like wishful thinking. FIPS cryptography is involved, often by legal requirement, in major parts of American data processing and in important parts of society.
Banks and government data processors alike are often forced to use things with FIPS’ lesser security. FIPS is where NSA is known to have sabotaged cryptography. NIST is still disgraced by the tip of the backdoor/sabotage iceberg. Yet we are still stuck with NIST, and indeed with various lesser standards which we can generally just call FIPS.
It is lame and sure, we should build better things. We should ignore FIPS where possible. We probably agree there, but it seems unreasonable to ignore all the systems which cannot be made better by intentional limitation.
Ignoring FIPS doesn’t change that many important systems do use FIPS’ cryptographic constructions. It would be nice if the U.S. government wasn’t actively sabotaging the security of standards with backdoors. It would also be nice if the U.S. government didn’t require anyone at all to use FIPS. Too bad we can’t have nice things in many important sectors.
Acceleration won’t fix the systemic issues here. Ignoring the systematic failure of (intentionally) weak FIPS standards will only further create division. Non-compliance will sideline reasonably secure modern systems in important contexts.
We shouldn’t need to fix FIPS, but what other alternative will help users whose data is protected by FIPS cryptography in the FIPS legally mandated contexts? Ignoring it isn’t going to change the law, ignoring it won’t secure those systems. OPM leadership probably really wished they had ignored FIPS. That wishful thinking won’t repair the damage to national security done by just one NSA/NIST FIPS backdoor being exploited in that single prominent example case.
The way I've seen at least some standards structured, you could take a FIPS entropy source and XOR it with a non-FIPS entropy source and from a security perspective (disregarding consideration of complexity introducing bugs or side channel attack considerations) you'd be no worse off than using one entropy source on its own, but would potentially gain the benefit of not having to trust a single standard/implementation. Linux and BSD kernels already use this approach with CPU-supplied entropy sources which the kernels do not just inherently trust (there is no way to verify the implementation).
For encryption, you could have a FIPS-compatible TLS connection over a non-FIPS Wireguard tunnel and again be no worse off (excluding performance etc reasons), whilst gaining the benefit of not having to trust one implementation exclusively.
Are there any standards that you are aware of that would prohibit mixing FIPS and non-FIPS entropy and encryption techniques as described above?
CPUs are “Enabled” and listed as a successful operation by NSA. Standards which are implemented in hardware and software are similarly backdoored. Protocols are designed to leak enough information to exploit various things at various levels. The new push to post-quantum without using mandatory hybrid constructions that include something we at least strongly believe to be (contemporarily) secure means that we should expect problems at literally every level from hardware to the newest key exchange mechanisms.
Can we theoretically build a baroque machine that combines something we trust with something we explicitly assume is compromised? Sure, and I like XOR as much as the next cryptographically knowledgeable person.
Should we? No, absolutely not. More importantly, will everyone who is required to use FIPS? Certainly not. Is it even allowed by auditors? Doubtful but maybe you can become one and bless your own solution. It’s still not a solution for everyone, not even close.
At the point where we start to even try, might we ask ourselves why we tolerate NSA and NIST doing this to the American public? Why don’t we understand what they planned to do when someone like you proposed things like you have done? After all, there is no question that NSA was playing the long game - they just believed their own NOBUS propaganda. Whoops.
Are you implying that the OPM breach happened because of a successful exploit of an NSA backdoor in a FIPS 140-2 approved cipher? Do you have any evidence to substantiate that?
My understanding of the OPM breach is that it was a classic example of poor access control combined with phishing.
Here’s one of the academics from the papers I linked above explaining his “pet” theory: https://mobile.twitter.com/matthew_d_green/status/1433476266... The papers explain more in detail, and the ACM publication seems reasonable to characterize as peer reviewed for some value of that depending on your impression of ACM.
You asked for “any evidence” and those papers explain the how, while Wired explains the what and reporting on the Project BULLRUN clearly lays out the why. It is undeniable that U.S. government sabotage to benefit NSA surveillance is involved in deployed Juniper devices. It is also widely discussed that those sabotaged devices were used by OPM. It is understood by many reasonable people in the know that OPM was hacked by Chinese intelligence and that they likely did this by compromising at least one Juniper device. See https://www.bloomberg.com/news/features/2021-09-02/juniper-m... for the Chinese link, for one example.
Bloomberg says:
“The NSA introduces an algorithm called Dual Elliptic Curve...”
“...which it urges the National Institute of Standards and Technology to approve.”
“The Pentagon—NSA’s parent agency—insists that Juniper Networks use the algorithm as a condition for some contracts. Juniper adds it to NetScreen’s ScreenOS software.”
“This introduces an alleged backdoor that could be used to spy on select NetScreen customers, which include telecommunications providers and government agencies.
Juniper includes two tweaks that it says neutralize the vulnerability.”
There are other sources which investigated this topic.
You don’t have to connect the dots, or believe the reprint from several reputable journalists or academics but I would appreciate you acknowledging that it’s not something that I made up. Many reasonable people have concluded that the NSA sabotage played some role in the OPM hack as a result of the link to Juniper.
The attack against OPM leveraged juniper bugs, which clearly exceeds your claims. I acknowledged that your claim is at least the bare minimum possible. However there is ample evidence that is goes much much further. At the time this happened, people pushed back that it was even plausible, and the paper represents a better investigation than I will be able to provide on a message board.
What I hope we can also agree on is that a complete lack of transparency means we cannot fairly adjudicate this in public to completion. Juniper, the FBI and the NSA, and indeed NIST, have not provided a full analysis to the public or even to the relevant IG as far as I understand things.
Comments
On the other hand, there's the FIPS-accelerationist perspective, which suggests that as more and more modern cryptography is mainstreamed irrespective of FIPS silly requirements, FIPS will itself gradually become untenable, leaving us all better off.
I'm not a cryptographer so disregard my opinions as you please, but I really like OpenSSH's approach. They just implement whatever the cryptographer community thinks is the best approach at the moment and disregard NIST and other authorities. For example they already have a post quantum key exchange as one of the default algorithms.
I'm not a cryptographer either and I certainly trust OpenSSH developers and actual cryptographers a lot mote than outdated government standards. As far as I'm concerned, what these people say is the standard and they're the people I look for when I want to learn something about cryptography from websites, LWN articles, mailing list discussions and other such sources. I've learned a lot reading about getrandom on LWN, plenty of knowledgeable people involved in that work.
This sounds like wishful thinking. FIPS cryptography is involved, often by legal requirement, in major parts of American data processing and in important parts of society.
Banks and government data processors alike are often forced to use things with FIPS’ lesser security. FIPS is where NSA is known to have sabotaged cryptography. NIST is still disgraced by the tip of the backdoor/sabotage iceberg. Yet we are still stuck with NIST, and indeed with various lesser standards which we can generally just call FIPS.
It is lame and sure, we should build better things. We should ignore FIPS where possible. We probably agree there, but it seems unreasonable to ignore all the systems which cannot be made better by intentional limitation.
Ignoring FIPS doesn’t change that many important systems do use FIPS’ cryptographic constructions. It would be nice if the U.S. government wasn’t actively sabotaging the security of standards with backdoors. It would also be nice if the U.S. government didn’t require anyone at all to use FIPS. Too bad we can’t have nice things in many important sectors.
Acceleration won’t fix the systemic issues here. Ignoring the systematic failure of (intentionally) weak FIPS standards will only further create division. Non-compliance will sideline reasonably secure modern systems in important contexts.
We shouldn’t need to fix FIPS, but what other alternative will help users whose data is protected by FIPS cryptography in the FIPS legally mandated contexts? Ignoring it isn’t going to change the law, ignoring it won’t secure those systems. OPM leadership probably really wished they had ignored FIPS. That wishful thinking won’t repair the damage to national security done by just one NSA/NIST FIPS backdoor being exploited in that single prominent example case.
The way I've seen at least some standards structured, you could take a FIPS entropy source and XOR it with a non-FIPS entropy source and from a security perspective (disregarding consideration of complexity introducing bugs or side channel attack considerations) you'd be no worse off than using one entropy source on its own, but would potentially gain the benefit of not having to trust a single standard/implementation. Linux and BSD kernels already use this approach with CPU-supplied entropy sources which the kernels do not just inherently trust (there is no way to verify the implementation).
For encryption, you could have a FIPS-compatible TLS connection over a non-FIPS Wireguard tunnel and again be no worse off (excluding performance etc reasons), whilst gaining the benefit of not having to trust one implementation exclusively.
Are there any standards that you are aware of that would prohibit mixing FIPS and non-FIPS entropy and encryption techniques as described above?
It’s turtles all the way down.
CPUs are “Enabled” and listed as a successful operation by NSA. Standards which are implemented in hardware and software are similarly backdoored. Protocols are designed to leak enough information to exploit various things at various levels. The new push to post-quantum without using mandatory hybrid constructions that include something we at least strongly believe to be (contemporarily) secure means that we should expect problems at literally every level from hardware to the newest key exchange mechanisms.
Can we theoretically build a baroque machine that combines something we trust with something we explicitly assume is compromised? Sure, and I like XOR as much as the next cryptographically knowledgeable person.
Should we? No, absolutely not. More importantly, will everyone who is required to use FIPS? Certainly not. Is it even allowed by auditors? Doubtful but maybe you can become one and bless your own solution. It’s still not a solution for everyone, not even close.
At the point where we start to even try, might we ask ourselves why we tolerate NSA and NIST doing this to the American public? Why don’t we understand what they planned to do when someone like you proposed things like you have done? After all, there is no question that NSA was playing the long game - they just believed their own NOBUS propaganda. Whoops.
Are you implying that the OPM breach happened because of a successful exploit of an NSA backdoor in a FIPS 140-2 approved cipher? Do you have any evidence to substantiate that?
My understanding of the OPM breach is that it was a classic example of poor access control combined with phishing.
Sure, of course.
Wired: https://www.wired.com/2015/12/the-years-11-biggest-hacks-fro...
IACR pre-print: https://eprint.iacr.org/2016/376
Later published in ACM: https://m-cacm.acm.org/magazines/2018/11/232227-where-did-i-...
Only the first article mentions both Dual_EC_DRBG and the OPM hack, and doesn’t link them. They’re just in the same list of “big hacks.”
It explicitly links them.
Here’s one of the academics from the papers I linked above explaining his “pet” theory: https://mobile.twitter.com/matthew_d_green/status/1433476266... The papers explain more in detail, and the ACM publication seems reasonable to characterize as peer reviewed for some value of that depending on your impression of ACM.
You asked for “any evidence” and those papers explain the how, while Wired explains the what and reporting on the Project BULLRUN clearly lays out the why. It is undeniable that U.S. government sabotage to benefit NSA surveillance is involved in deployed Juniper devices. It is also widely discussed that those sabotaged devices were used by OPM. It is understood by many reasonable people in the know that OPM was hacked by Chinese intelligence and that they likely did this by compromising at least one Juniper device. See https://www.bloomberg.com/news/features/2021-09-02/juniper-m... for the Chinese link, for one example.
Bloomberg says: “The NSA introduces an algorithm called Dual Elliptic Curve...”
“...which it urges the National Institute of Standards and Technology to approve.”
“The Pentagon—NSA’s parent agency—insists that Juniper Networks use the algorithm as a condition for some contracts. Juniper adds it to NetScreen’s ScreenOS software.”
“This introduces an alleged backdoor that could be used to spy on select NetScreen customers, which include telecommunications providers and government agencies. Juniper includes two tweaks that it says neutralize the vulnerability.”
There are other sources which investigated this topic.
You don’t have to connect the dots, or believe the reprint from several reputable journalists or academics but I would appreciate you acknowledging that it’s not something that I made up. Many reasonable people have concluded that the NSA sabotage played some role in the OPM hack as a result of the link to Juniper.
The attack against OPM leveraged juniper bugs, which clearly exceeds your claims. I acknowledged that your claim is at least the bare minimum possible. However there is ample evidence that is goes much much further. At the time this happened, people pushed back that it was even plausible, and the paper represents a better investigation than I will be able to provide on a message board.
What I hope we can also agree on is that a complete lack of transparency means we cannot fairly adjudicate this in public to completion. Juniper, the FBI and the NSA, and indeed NIST, have not provided a full analysis to the public or even to the relevant IG as far as I understand things.
See also https://en.wikipedia.org/wiki/Office_of_Personnel_Management... for many other sources, as well as https://fcw.com/security/2021/01/lawmakers-press-nsa-for-ans... and this gem of a FOIA: https://www.muckrock.com/foi/united-states-of-america-10/inf...
So since your stated request was any evidence, I think I have shown that I didn’t make this up out of the thin air.
I have too much faith in the ability of government standards to remain decoupled from reality to hope for that, but I hope you're right.