# A new future for cryptography in Haskell

**URL:** <https://discourse.haskell.org/t/a-new-future-for-cryptography-in-haskell/3888>\
**Category:** Announcements\
**Created:** [January 9, 2022, 1:49pm UTC](https://discourse.haskell.org/t/a-new-future-for-cryptography-in-haskell/3888 "2022-01-09T13:49:28Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Kleidukos](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/kleidukos/32/1213_2.png) [@Kleidukos](https://discourse.haskell.org/u/Kleidukos)\
**Post date:** [January 9, 2022, 1:49pm UTC](https://discourse.haskell.org/t/a-new-future-for-cryptography-in-haskell/3888/1 "2022-01-09T13:49:28Z")

</div>

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](https://github.com/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

---

<div class="post-metadata">

**Author:** ![Las](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/las/32/1592_2.png) [@Las](https://discourse.haskell.org/u/Las)\
**Post date:** [January 9, 2022, 2:13pm UTC](https://discourse.haskell.org/t/a-new-future-for-cryptography-in-haskell/3888/2 "2022-01-09T14:13:06Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Kleidukos](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/kleidukos/32/1213_2.png) [@Kleidukos](https://discourse.haskell.org/u/Kleidukos)\
**Post date:** [January 9, 2022, 2:15pm UTC](https://discourse.haskell.org/t/a-new-future-for-cryptography-in-haskell/3888/3 "2022-01-09T14:15:35Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![bgamari](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/bgamari/32/3599_2.png) [@bgamari](https://discourse.haskell.org/u/bgamari)\
**Post date:** [January 9, 2022, 2:26pm UTC](https://discourse.haskell.org/t/a-new-future-for-cryptography-in-haskell/3888/4 "2022-01-09T14:26:46Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![TomMD](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/tommd/32/1464_2.png) [@TomMD](https://discourse.haskell.org/u/TomMD)\
**Post date:** [January 9, 2022, 4:22pm UTC](https://discourse.haskell.org/t/a-new-future-for-cryptography-in-haskell/3888/5 "2022-01-09T16:22:58Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Kleidukos](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/kleidukos/32/1213_2.png) [@Kleidukos](https://discourse.haskell.org/u/Kleidukos)\
**Post date:** [January 9, 2022, 4:30pm UTC](https://discourse.haskell.org/t/a-new-future-for-cryptography-in-haskell/3888/6 "2022-01-09T16:30:47Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Bodigrim](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/bodigrim/32/1457_2.png) [@Bodigrim](https://discourse.haskell.org/u/Bodigrim)\
**Post date:** [January 9, 2022, 5:07pm UTC](https://discourse.haskell.org/t/a-new-future-for-cryptography-in-haskell/3888/7 "2022-01-09T17:07:14Z")

</div>

> [@TomMD](#):
>
> 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?

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.

---

<div class="post-metadata">

**Author:** ![emilypi](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/emilypi/32/5307_2.png) [@emilypi](https://discourse.haskell.org/u/emilypi)\
**Post date:** [January 9, 2022, 6:04pm UTC](https://discourse.haskell.org/t/a-new-future-for-cryptography-in-haskell/3888/8 "2022-01-09T18:04:35Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Bodigrim](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/bodigrim/32/1457_2.png) [@Bodigrim](https://discourse.haskell.org/u/Bodigrim)\
**Post date:** [January 9, 2022, 6:54pm UTC](https://discourse.haskell.org/t/a-new-future-for-cryptography-in-haskell/3888/9 "2022-01-09T18:54:22Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Las](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/las/32/1592_2.png) [@Las](https://discourse.haskell.org/u/Las)\
**Post date:** [January 9, 2022, 8:42pm UTC](https://discourse.haskell.org/t/a-new-future-for-cryptography-in-haskell/3888/10 "2022-01-09T20:42:54Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Las](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/las/32/1592_2.png) [@Las](https://discourse.haskell.org/u/Las)\
**Post date:** [January 9, 2022, 8:43pm UTC](https://discourse.haskell.org/t/a-new-future-for-cryptography-in-haskell/3888/11 "2022-01-09T20:43:54Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![Kleidukos](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/kleidukos/32/1213_2.png) [@Kleidukos](https://discourse.haskell.org/u/Kleidukos)\
**Post date:** [January 9, 2022, 8:44pm UTC](https://discourse.haskell.org/t/a-new-future-for-cryptography-in-haskell/3888/12 "2022-01-09T20:44:38Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Las](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/las/32/1592_2.png) [@Las](https://discourse.haskell.org/u/Las)\
**Post date:** [January 9, 2022, 8:45pm UTC](https://discourse.haskell.org/t/a-new-future-for-cryptography-in-haskell/3888/13 "2022-01-09T20:45:29Z")

</div>

Nevermind, I just found out cryptonite is basically a C library! [cryptonite/cbits at master · haskell-crypto/cryptonite · GitHub](https://github.com/haskell-crypto/cryptonite/tree/master/cbits)

---

<div class="post-metadata">

**Author:** ![Las](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/las/32/1592_2.png) [@Las](https://discourse.haskell.org/u/Las)\
**Post date:** [January 9, 2022, 8:46pm UTC](https://discourse.haskell.org/t/a-new-future-for-cryptography-in-haskell/3888/14 "2022-01-09T20:46:55Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Kleidukos](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/kleidukos/32/1213_2.png) [@Kleidukos](https://discourse.haskell.org/u/Kleidukos)\
**Post date:** [January 9, 2022, 8:48pm UTC](https://discourse.haskell.org/t/a-new-future-for-cryptography-in-haskell/3888/15 "2022-01-09T20:48:07Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Las](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/las/32/1592_2.png) [@Las](https://discourse.haskell.org/u/Las)\
**Post date:** [January 9, 2022, 8:53pm UTC](https://discourse.haskell.org/t/a-new-future-for-cryptography-in-haskell/3888/16 "2022-01-09T20:53:10Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Kleidukos](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/kleidukos/32/1213_2.png) [@Kleidukos](https://discourse.haskell.org/u/Kleidukos)\
**Post date:** [January 9, 2022, 9:05pm UTC](https://discourse.haskell.org/t/a-new-future-for-cryptography-in-haskell/3888/17 "2022-01-09T21:05:24Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Axman6](https://avatars.discourse-cdn.com/v4/letter/a/ce73a5/32.png) [@Axman6](https://discourse.haskell.org/u/Axman6)\
**Post date:** [January 10, 2022, 1:23am UTC](https://discourse.haskell.org/t/a-new-future-for-cryptography-in-haskell/3888/18 "2022-01-10T01:23:06Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Abab9579](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/abab9579/32/2163_2.png) [@Abab9579](https://discourse.haskell.org/u/Abab9579)\
**Post date:** [January 10, 2022, 2:37am UTC](https://discourse.haskell.org/t/a-new-future-for-cryptography-in-haskell/3888/19 "2022-01-10T02:37:19Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![vshabanov](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/vshabanov/32/2080_2.png) [@vshabanov](https://discourse.haskell.org/u/vshabanov)\
**Post date:** [January 10, 2022, 10:46am UTC](https://discourse.haskell.org/t/a-new-future-for-cryptography-in-haskell/3888/20 "2022-01-10T10:46:33Z")

</div>

Hi, as an [HsOpenSSL](https://hackage.haskell.org/package/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](https://github.com/vshabanov/HsOpenSSL) to the haskell-cryptography organization.

[Next page](https://discourse.haskell.org/t/a-new-future-for-cryptography-in-haskell/3888.md?page=2)