Hi, so I recently started to develop in haskell and I was going good till my company started to require fed ramp certification and started to use fips based container images.
Though I have not tested the code on it, but I am wondering if me using libraries which depend on crypton set of libraries will cause the violation of fips compliance.
So the question is,
is crypton fips compliant ? and if not
I heard botan was fips compliant, so are there plans to use botan to be used within crypton to make it fips compliant.
From a cursory search around the web (as I’ve not heard of FIPS before), FIPS compliance seems to be more about how you use encryption and which algorithms you use. So in that sense, if crypton supports the algorithm(s) you need, then yes, it seems to be FIPS compliant?
No haskell libraries have been FIPS-validated, so if that is a requirement, then haskell is out. That doesn’t mean you cannot use haskell at all. It just means the portion that is required to be compliant must be in some other FIPS-validated library. In other words, the answer to the question
Does the security of our software depend on haskell implementation details?
must be:
No.
As to haskell and security:
Crypton’s implementation is:
Hand-rolled.
Primarily written by one person.
Not audited.
In a language with unexplored security concerns (e.g. laziness and side-channel attacks).
At best you can say it implements FIPS-approved algorithms like AES, but that just moves the question to the implementation, where it is doomed by all of the above.
Bindings to FIPS-validated libraries are about the best you can do in haskell. For example, HsOpenSSL binds to openssl, of which some versions are FIPS-validated. But that doesn’t make HsOpenSSL itself compliant.
I don’t know much about Botan. It has a “FIPS mode”, though this appears to restrict the provided algorithms to FIPS-compliant ones. I don’t believe Botan the implementation has been validated (though it has been audited). So this may be even worse than HsOpenSsl, from a compliance POV.
For what it’s worth, FIPS is not flawless. Old (bad) algorithms are kept in, and plenty of good libraries are excluded (e.g. libsodium). If I was making a security-conscious app in haskell, my decision tree would be something like:
Need something else? Hopefully the new botan bindings suffice.
Crypton/cryptonite should only ever be used due to backwards-compat reasons, and existing usages should be moved off as soon as possible (ideally to a haskell library that wraps some audited bindings).
Of course none of that applies when you have a formal validation requirement.
@ApothecaLabs was working on botan bindings and posting updates, but I haven’t heard anything for a while. Which is a shame, because I’d really love to switch a lot of my code over to it.
Perhaps if he sees this, he can let us know how it’s going, and what he’d need to be able to work more on it?
Work on botan and related items (such as a replacement for `memory) is more or less at the mercy of my having time to work on it, previously supported by a combination of my income and foundation funding
I have been away for 9 months on a Ruby job that took up 100% of my time, but thankfully that work has now concluded
I once again able to spend some energy on Haskell while taking some time to look for new work
I have been doing a lot of work related to memory allocators and management that has relevance and may show up
It has been a while since I made any significant code changes, so I need to regain my bearings
Botan has also updated a few times so I need to see what needs changing
