Great call.
Having personally been through the toils of FIPS certifying crypto libraries, I smiled and nodded as I read this post.
FIPS is about compliance, not about security. LibreSSL is about security, full stop.
LibreSSL: FIPS mode is not coming back
51–60 of 98 posts
Re: LibreSSL: FIPS mode is not coming back
#52Just looking at the wholesale cleanup [1] makes me shudder to think about how tough the code was to maintain in the past. Kudos to the libssl team for injecting some much-needed energy into such a critical library. If only this were available on GitHub, we could more easily browse the code and learn about patterns and anti-patterns in writing secure code. [1] http://freshbsd.org/search?project=openbsd&q=file.name:lib…
An unofficial mirror: https://github.com/libressl/libressl
Re: LibreSSL: FIPS mode is not coming back
#53Earlier quoted context omitted.
Also, I believe that only binaries can be FIPS certified, not source code, so there are times when one has to use an old, out-dated openssl binary in order to be compliant.
OpenSSL FIPS certification (#1747) is for source code, not for binary. This is highly unusual indeed, but it is not the case that only binaries can be FIPS certified. On the other hand, you can't change the source without losing the certification, so it doesn't actually matter.
So any change to openssl fips has to happen as compiler patches?
Re: LibreSSL: FIPS mode is not coming back
#54Earlier quoted context omitted.
"Fortunately" (and I don't mean to encourage it), the abrasive people in the crypto community are like that when they tend to be right - and don't want "newbies" to do stupid dangerous mistakes, so their tone comes out a little aggressive by default. But yeah, it could be improved. The community should work together on solving issues the right way.
Fortunately or unfortunately, there are also a reasonable number of abrasive people who tend not to be right, so I'm not sure it's a good marker either way. There's a whole rock-star persona around people who make consulting careers out of trying to position themselves as security badasses, and not all of them are.
I include amongst these, security/network guys that disable ICMP because they read it in a book somewhere.
Leads to a lot of facepalming when you are actually trying to get something done.
Re: LibreSSL: FIPS mode is not coming back
#55Lol, if WorldTechTribune were still around the headlines would write themselves. "Windows contains military-grade encryption certified by the U.S. government. Linux no longer does. Don't be fooled by the communist Al-Qaeda sympathizers in open-SORES development! Windows is more secure!"
Re: LibreSSL: FIPS mode is not coming back
#56Earlier quoted context omitted.
I'm sure they do, too. It isn't that simple.
What isn't simple about Red Hat paying a third-party to write some software and get it certified? Other companies are doing it for themselves, surely Red Hat can find someone qualified.
Just "write some software and get it certified"? Sounds so simple, why doesn't everyone do it?
Because it isn't just getting a body of code certified once.
Someone has to maintain that specific code and either upstream or backport important changes which require a re-certification, neither of which LibreSSL is interested in helping with.
Re: LibreSSL: FIPS mode is not coming back
#57Earlier quoted context omitted.
This is not true. FIPS requires that any 'approved' included crypto algorithm implementations are self-tested, and pass a verification program (just a big bunch of somewhat poorly conceived known answer tests). It also has a list of 'allowed' algorithms, which don't need to be tested but can be offered by a FIPS crypto module. The CSPRNG used for key generation must be of an approved construction, but there are a num…
A question if I may: Could you "accidentally" make a FIPS compliant library? Assuming that the LibreSSL fork where to include ONLY the FIPS approved ciphers and hashing algorithms, it should be possible to have a library that could be passed of a compliant. If I understand you correctly, the issue with FIPS is that you would have to be able to disable all but a subset of the features, regardless of these feature bein…
> Could you "accidentally" make a FIPS compliant library?
Let's differentiate between "FIPS compliant" and "FIPS certified".
FIPS complaint: you could get a FIPS certified product if you wanted, without changing your product.
FIPS certified: you paid NIST and a FIPS test lab some money, the lab tested your module, submitted a test report to NIST, and NIST published certificates saying that a certain version of your product (running on a particular OS and CPU architecture, for software modules) is FIPS certified.
So, yes, you could accidentally come up with a FIPS compliant crypto module. But getting certified costs actual money (last time I did it, as I recall just shy of $100k).
> the issue with FIPS is that you would have to be able to disable > all but a subset of the features, regardless of these feature > being worse or better than what is defined in the FIPS documents?
To some extent it depends what you mean by 'feature' here. If it's a crypto algorithm offered by your module for external use, there is quite little leeway. If it's a fundamental feature of your product that internally uses exotic crypto, you can often convince your test lab to gloss over it.
Re: LibreSSL: FIPS mode is not coming back
#58Earlier quoted context omitted.
OpenSSL FIPS certification (#1747) is for source code, not for binary. This is highly unusual indeed, but it is not the case that only binaries can be FIPS certified. On the other hand, you can't change the source without losing the certification, so it doesn't actually matter.
So any change to openssl fips has to happen as compiler patches?
No, changing the source means you're not using FIPS-compliant source so you're breaking your terms.
This is why you might have to use old versions of OpenSSL for FIPS compliance - not all versions might be certified.
Re: LibreSSL: FIPS mode is not coming back
#59This basically means libressl can not be used by the US Govt or any contractor working with the US Govt, which is a HUGE number of companies. By proxy, it means that libressl will not make its way into Fedora or RHEL, which also limits the adoption of it a fair bit. Perhaps the solution is to fix FIPS instead of berating the people forced to use it.
Not unless RedHat is willing to foot the bill for FIPS certification of a variant, or wait for someone else to do it. The LibreSSL folks have indicated that they won't stand in the way of anyone who wants to do that (in this very note!). It just won't be them. BTW, even some core OpenSSL developers think that the FIPS validation process is worse than useless. Here's OpenSSL developer Steve Marquess arguing that a FIP…
Redhat already foots the bill for certification of the OpenSSL library they ship. They also foot the bill to have the versions of OpenSSH, dm-crypt, the kernel crypto api and libgcrypt certified.
Re: LibreSSL: FIPS mode is not coming back
#60Earlier quoted context omitted.
What isn't simple about Red Hat paying a third-party to write some software and get it certified? Other companies are doing it for themselves, surely Red Hat can find someone qualified.
Just "write some software and get it certified"? Sounds so simple, why doesn't everyone do it? Because it isn't just getting a body of code certified once. Someone has to maintain that specific code and either upstream or backport important changes which require a re-certification, neither of which LibreSSL is interested in helping with.
Once LibreSSL has reached a point of minimal disruptive change, FIPS support could be re-implemented as a series of third-party patches, which could then be certified as needed.
For example, create a fipssl project which is patches to a specific version of LibreSSL; take the result (LibreSSL v1.x + fipssl v1.2 = libfipssl v1.2) and then get that certified. Companies/contractors which need FIPS certification then use libfipssl v1.2.
The fipssl maintainers then just have to track LibreSSL changes until their next release, which (for a series of small, maintainable patches) shouldn't be too difficult. The grsecurity project has been doing the same thing with the Linux kernel for years.