A new future for cryptography in Haskell

Announcements
#1

Hello everyone,

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.

Cheers,
HĂ©cate, for the Haskell Foundation

28 Likes
Haskell Foundation January Update
#2

How come all the repositories have had their entire history squashed?

2 Likes
#3

@chris has forked the repositories, maybe he can answer.

1 Like
#4

@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.

3 Likes
#5

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.

1 Like
#6

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. :slight_smile:

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. :slight_smile:

3 Likes
#7

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.

1 Like
#8

Forking completely around basement, foundation, tls, x509, and cryptonite would be an excellent step forward for the Haskell ecosystem.

3 Likes
#9

(There is no reason to fork tls, it has an active maintainer)

#10

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.

#11

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?

#12

@Las I am not advocating for native Haskell cryptography and never implied that linking to libsodium and openssl or ring would be out of the question. :slight_smile:

2 Likes
#13

Nevermind, I just found out cryptonite is basically a C library! cryptonite/cbits at master · haskell-crypto/cryptonite · GitHub

#14

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.

1 Like
#15

Yes, this is absolutely something that should be done. Wanna give a hand? :slight_smile:

1 Like
#16

Yes, absolutely! Do we have any Matrix channel to discuss the efforts, or anything similar?

1 Like
#17

Sure, #haskell-cryptography on LiberaChat, also available through the IRC <-> Matrix bridge, if I’m not mistaken.

1 Like
#18

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.

1 Like
#19

Any way for me to contribute? I am curious about which part the current project is lacking, so that I might aid some in.

1 Like
#20

Hi, as an HsOpenSSL maintainer, I’m ready to participate.

I don’t have enough time to do new developments but will happily accept any pull requests.

I can also add somebody from Haskell Foundation as a co-maintainer or transfer the repository to the haskell-cryptography organization.

2 Likes