1. 20
  1.  

  2. 6

    It hasn’t improved much IMO.

    Haskell is normally extremely strong when it comes to well-designed and reusable abstractions. Unfortunately that appears to be more or less absent from the Haskell crypto libraries. There are a few different monad classes for pseudorandom number generation, for example, and all of them are overcomplicated. I often end up just rolling my own (monad, not PRNG) when I need clean random number generation.

    There are a few decent libraries available for sundry concrete cryptographic tasks, but well below par for the Haskell ecosystem.

    In fairness, cryptography libraries are bad across almost all languages, but I expect more from Haskell.

    1. 4

      Is it fair to suggest that Haskell expects more from you, too? I mean, you’re certainly welcome to contribute.

      1. 3

        In fairness, cryptography libraries are bad across almost all languages, but I expect more from Haskell.

        Why? Does Haskell have any special features that make it fundamentally easier to correctly implement cryptography algorithms compared to other high-level languages? Parametricity doesn’t particularly help when all your routines map tuples of integers to tuples of integers.

        1. 4

          Does Haskell have any special features that make it fundamentally easier to correctly implement cryptography algorithms compared to other high-level languages?

          Yes, e.g. QuickCheck, QuickSpec, LiquidHaskell, etc.

          1. 4

            These get you some of the way but there’s a whole class of dude channel attacks we have very little ability to reason about in Haskell. Timing is something I have no idea how to talk about how to make a constant time Integrr multiplication algorithm and be sure it is constant time.

            My dream for this sort of work is a inline-rust package, in the vain of inline-c, so we get memory safety but also a language which better allows timing analysis.

            1. 2

              inline-rust is something I want in every programming language. :)

              I think it’s possible that a subset of Haskell in which you only use primitive types and primops (like Word32# and MutableByteArray# and so on) and can’t have any laziness anywhere (because no values are ever boxed) might be more amenable to timing analysis.

              I’m not sure if there is a pragma or Language setting in GHC that can automatically enforce that everything in a given file uses only primitives and primops.

              1. 2

                Check out Jasmin for language implementing high-assurance crypto. Once again, it’s achieved with a language quite opposite of Haskell’s high-level style.

                1. 2

                  That would be cool indeed—but I can already viscerally imagine the impact on build times from invoking the Rust compiler via Template Haskell… :)

                2. 3

                  In 2017, QuickCheck is by no means specific to Haskell. Nowadays you can find property-based testing libraries and frameworks for just about any language.

                  As for LiquidHaskell, the real verification is performed by an external SMT solver. So again I don’t think this constitutes a Haskell-specific advantage.

                3. 3

                  Because Haskell libraries are, in general, much higher quality than libraries in other ecosystems I use. Correctness also isn’t the concern — I have little doubt that the crypto libraries are correct. The concern is usability. Most of the Haskell crypto libraries are clumsy, typically because they just wrap some C library without providing any additional abstractions.

                  1. 2

                    So you are confident the underlying C library is correct?

              2. 6

                OP has promised an update to the blog post: https://twitter.com/solatis/status/940746022040453122

                Some discussion from when this was current, about 2.5 years ago: https://www.reddit.com/r/haskell/comments/2zsbth/on_the_state_of_cryptography_in_haskell/

                1. 2

                  hackage also now says crypto-random is deprecated in favour of cryptonite

                2. 1

                  FreeBSD has ditched the RdRand instruction altogether.

                  Huh?? What’s this?

                  random: registering fast source Intel Secure Key RNG
                  random: fast provider: "Intel Secure Key RNG"
                  

                  (hilariously, these exact messages appear on my AMD system, with zero Intel parts inside :D)

                  On the random issue… well, /dev/random sucks because of the /dev/ part. Randomness shouldn’t depend on the filesystem. This often blows up with many kinds of sandboxing.

                  So RDRAND is very attractive indeed, it doesn’t even depend on the operating system, you 100% reliably get random numbers.

                  If you’re paranoid about CPU vendors backdooring RDRAND and want to use the OS’s mixed entropy, you have to deal with getentropy/KERN_ARND/arc4random, their (lack of) thread- and fork-safety, and you have to deal with older version of operating systems (which might not have these APIs, might actually use RC4 in arc4random, etc.)

                  https://github.com/briansmith/ring/issues/326

                  It’s a horrible mess and I would totally understand why someone would prefer a single reliable CPU instruction to dealing with all that garbage.