Several members of the Haskell Foundation have decided to take action regarding the precarious state of cryptography tooling in Haskell, and we are working on rejuvenating the maintenance of highly important projects that have lacked the means to keep up with new GHC releases and new features.
As such, the haskell-cryptography GitHub organisation has been created, and it aims to be the central point for developers and stake-holders of the ecosystem to join forces and collaborate.
This a matter of cryptography engineering and community-owned maintenance. You don’t have to be a cryptographer to participate, being involved in the stewardship of the repositories can be a very good first open-source Haskell experience.
That being said, we are also looking to collaborate with cryptographers who would like to use Haskell, or directly benefit from it and have a vested interest in its cryptography tooling.
Please make yourself known if you wish to participate. We’re not asking for a lifetime of commitment.
@chris, while in most cases it probably doesn’t matter, I would indeed avoid squashing in the case of security-sensitive packages to retain some sort of traceability. I would be happy to help in rebasing the repositories’ current states on top of their proper upstream histories if this would be helpful.
I’d join the effort based on the higher level goal but I don’t think I’d spend any time maintaining forks of basement, memory, or cryptonite.
From a security engineering perspective a big purpose of memory is to ensure critical data like keys are not copied and zeroed after free. I don’t believe this is being done at the program level for any users of memory, meaning the secrets being encrypted and often the entropy used to generate or agree on the original key isn’t being zeroed. Instead let’s add a GHC flag to zero memory on copy/free/move operations.
Can someone give motivation for why basement is in this group other than its maintenance falling behind and it being a dependency of cryptonite? Would the community be better served by removing the basement dependency?
As for cryptonite, last I looked it didn’t have any cohesion between implementations. There’s hand written C with hand written Haskell bindings. Making a binding generator, that isn’t just CPP, for each class of algorithm would be more comfortable. Even then it might be better to do micro libraries much like amazonka does instead of having all crypto algorithms in one package.
I’d join the effort based on the higher level goal but I don’t think I’d spend any time maintaining forks of basement, memory, or cryptonite.
Well that’s good because I’ve initiated a package takeover on Hackage.
Instead let’s add a GHC flag to zero memory on copy/free/move operations.
I agree.
Would the community be better served by removing the basement dependency?
I would, I plan on doing so.
Even then it might be better to do micro libraries much like amazonka does instead of having all crypto algorithms in one package.
For the sake of discoverability and usability I’d prefer keeping cryptonite as a “kitchen sink” aggregating packages whilst having more focused libraries, indeed.
I don’t mind hand-written C but then I’d like to have the HF pay for security audits.
Absolutely. cryptonite and memory migrated to basement at a pretty late stage of their evolution. It should be possible to skip migration commits and rebase everything else.
I do not believe that adding options to GHC is a good approach to this issue. If you want control over how the keys are passed around, do not let the RTS handle it, and instead allocate it manually.
I think this effort is admirable, however, I’m not convinced that we need any native cryptography implementations in Haskell. What’s wrong with linking to libsodium, openssl, or ring?
Perhaps we should switch out the C implementations in cryptonite for verified implementations, since seemingly there is no benefit to using the implementations in cryptonite.
I’m interested in being a part of this, I’ve used cryptonite many times over the years, though I’m not exactly sure how I’d best contribute. Happy to help implement changes and do reviews on whatever’s needed.
