A new future for cryptography in Haskell

Announcements
#41

I must say I’m rather confused about this.

Our biggest issue with cryptography isn’t that packages don’t keep up with GHC releases. It’s that they have had no external audit and that there’s very little confidence about whether Haskell is even the right language for low-level crypto and what we’d need to do in order to make it feasible.

Here are some threads I’ve raised over the years:

Cryptography isn’t like other ecosystem parts where you should just “get your hands dirty”. It’s so critical and easy to mess up that it’s better only people with very extensive knowledge work on it. That includes seemingly trivial patches as the infamous Debian OpenSSL debacle illustrates, where an incompetent maintainer tried to fix a valgrind warning.

So I’m not sure what the HF is trying to do here. To me, it seems the only reasonable way forward is to temporarily mark all crypto implementations that are implemented in Haskell as NOT AUDITED and fund research about crypto security in Haskell similar to the everest project.

1 Like
#42

Entirely agreed about that @hasufell, although I don’t see the benefit of funding crypto security research in Haskell. Why not just wrap audited, widely used, robust libraries? (I believe libsodium is or will be wrapped in this way.)

#43

Our biggest issue with cryptography isn’t that packages don’t keep up with GHC releases. It’s that they have had no external audit and that there’s very little confidence about whether Haskell is even the right language for low-level crypto and what we’d need to do in order to make it feasible.

@hasufell I’m certain that you’ve already taken a look at the haskell-cryptography GitHub organisation and the content of its repository, so I’m having trouble understanding how you are under the impression that

  • We are using non-audited implementations
  • We are using Haskell as an implementation language for cryptography primitives

So I’m not sure what the HF is trying to do here.

I can see this, indeed, but rest assured that never has arisen the will or desire to implement cryptography primitives in Haskell.

Edit: Regarding HACL*, I’m not against having bindings to it but this is not in the TODO at present time.

3 Likes
#44

@Kleidukos

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.

Don’t get me wrong… I’m a firm believer in collaboration and open-source, but this gave me the impression we’re doing a general call-for-help, so people with no cryptography background can provide patches with low effort.

If that’s not the case, who’s the head reviewer of these new HF repositories? What is their crypto background?

Well, afaiu @chris has forked some of Vincent Hanquez’ repositories (which definitely do include crypto primitives) and there has been this rather confusing thread about taking over maintenance those libs.

So I’m still confused what the real motivation here is. I don’t see a proper technical agenda. And who’s spearheading this effort and with what technical background?

1 Like
#45

Shouldn’t this be clarified in the agenda then? And does that mean haskell-tls will be discouraged by HF? Or supported? And then in what way?

#46

I’m not sure which agenda you are referring to. As far as I know the HF has no plans at this time to either discourage or support haskell-tls.

#47

Right, I think this sums up my confusion.

My suggestion would be to:

  1. Have an internal HF meeting to discuss goals and strategy wrt crypto in Haskell, including the technical controversies around it
  2. Find crypto experts in the community and industry (IOHK probably has some) that may help with consultation or concrete projects
  3. Lay out a concrete agenda on how crypto in Haskell could move forward (funding of research? Bindings to C libs? New frameworks? Audits?) and have an open discussion in the community.
  4. Support existing efforts and create structured HF led projects around that agenda

The current approach (bumping support for GHC versions, forking of large crypto packages) looks too unstructured to me for something as sensitive as crypto.

As has been discussed before, this is something a HF CTO would be needed for.

1 Like
#48

Seems like a reasonable plan to me, but any reason why step 1 needs to be internal? I tend to think that involving the community as early as possible is beneficial.

#49

I think it helps to gain some orientation first, so the conversation with the community has some structure and the main bullet points are clear.

2 Likes
#50

tls was originally developed by Vincent and is depending on the x509/foundation/memory ecosystem. Is it feasible to make it independent of that?

#51

Just a regular Haskell user here, I’ve been eagerly waiting for an update on this thread for a couple of months now, has there been anything new that HF has agreed upon? The repos in haskell-cryptography organisation seem untouched for a few months and leaves me wondering if they are supposed to be ready for production or are abandoned.

1 Like
#52

@david-christiansen for visibility :slight_smile: I believe this thread was written before the HF switched hands!

#53

For clarity, my understanding is that this was not an initiative by the HF. This was just an individual initiative by several people who also happen to be on the HF board. That said, the crypto ecosystem certainly is a place where HF as such might want to play a more active role – resources and time permitting (both always in short supply!).

3 Likes
#54

Hello! To summarise the situation:

  • The Haskell Cryptography Group is indeed a group affiliated with the HF (and thus, as sclv points out) able to receive HF support, should the supply allow it)
  • I regularly make our presence known to individual maintainers of cryptography packages, and we have a Slack channel where we can discuss relevant matters on the Haskell Foundation workspace

Feel free to review our governance documents here: GitHub - haskell-cryptography/governance: Governance documents, by-laws, code of conduct

2 Likes
#55

Committees don’t take initiatives, people do. /s

1 Like
#56

To be clear, groups not affiliated with the HF are also able to receive support :slight_smile:

2 Likes
#57

This is an important effort, and I’d like to participate.

In the meanwhile, one question: pretty much all the repos seem to provide bindings from Haskell to libraries in other languages (usually C). Is there an effort to create a “pure” Haskell implementation of, e.g., basic Post-Quantum algorithms?

1 Like
#58

Yes, it’s a matter of cost effectiveness for algorithms that are widely used and produced from trusted sources.
That being said I believe Galois has produced cryptography packages in Haskell. You should check them out.

#59

Yes, it’s a matter of cost effectiveness for algorithms that are widely used and produced from trusted sources.

I understand that, thanks. Do you think that math implemented in Haskell would be noticeably slower than, e.g., in C?

(Majority of the PQC finalists are Lattice-based, so if lattice operations and vector encoding/decoding can be fast “enough” in Haskell, there’s no need to FFI-access C libraries. And vs. versa.)

That being said I believe Galois has produced cryptography packages in Haskell.

Could you please point me at those packages?

I’m perfectly happy (and, probably, ready) to start playing myself with the algorithms I’m interested in (NIST PQC finalists), but if there’s something already written - it would be silly for me to ignore it.

#60

I wrote one in C years ago (naive implementation). Lots of fun. But I wouldn’t go anywhere near a Haskell implementation, unless we have sufficient knowledge about the memory model, branching etc.

We can barely guess what’s going on with simple list fusion and laziness in some cases. What makes us think that’s a good idea to implement crypto?

This is a research area and there shouldn’t be any production libraries unless there’s clarity about it.

2 Likes