How do cryptohash-sha256 et al fit into this? Are these packages considered trustworthy? Should they ultimately also be deprecated in favor of libsodium?
2 Likes
Hi! We would welcome your repository with great honour! 
An invite has been sent so that you can transfer the repository to the haskell-cryptography organisation. 
I think that in this day and age we should aim to get away from hand-rolled, non audited, non-verified C implementations. I would rather have the algorithms based on libsodium yes.
3 Likes
I think we should have a discussion wrt. what implementation to use if available in multiple libraries. What do people here feel wrt. using Rust implementations?
Thank you for the invite. Iāve just moved the repository to the haskell-cryptography and updated links on Hackage.
If you like, I could add somebody to the list of the HsOpenSSL package maintainers on Hackage.
1 Like
Well fortunately the debate is closed fairly quickly: We become bound to what LLVM supports, which means that every arch that LLVM doesnāt support but that the GHC native code generator supports becomes excluded from using the package.
Perfect! If you want to stick around in a non-committed way, the #haskell-cryptography IRC channel (also bridged to Matrix) is open.
This is also my reservation, but realistically speaking, there is no target that LLVM doesnāt have that GHC does have a NCG for. And the gcc rust project. So Iām not too concerned about this, especially with a 1-2 year horizon.
That being said, integrating C code is just by far easier than anything else. GHCās FFI is geared towards C, (and please use CApiFFI!), and the lack of buildsystems for C, actually play into our hand here, we donāt need to deal with intricacies of other package managers, weird and deep dependency trees, ā¦
Even cross compilation for C is fairly straight forward. Swap our $CC for <target-triple>-cc, and unless someone uses architecture specific code only (
scrypt), it basically just works.
3 Likes
One reason for not squashing is that since the last release of cryptonite there have been a few commits which have broken the build.
1 Like
Is anybody here in touch with Galois? It seems like theyāve put a lot of effort into the cryptol library, wondering if itās relevant to our goals here.
1 Like
Yes, I talk to Galwegians a bit but cryptol and saw are designed for verifying very low level implementations. What the discussion here is looking like is bindings to pre-existing implementations. Other than asking if they want to join is there something you have in mind?
1 Like
maybe too easy 
i wonder if it will make other targets like js, wasm or jvm harder
I think emscripten would be useful for the JS & Wasm.
For Java, the JNI will need a bit more tooling that is for sure.
but jni is not the same that produce directly jvm bytecode, but use the c ffi common to both targets, if i am not wrong
jni defeats one of main motivations of using the jvm in the first place, no?
Oh yeah but Iām not sure you want to compile C to Java for those kind of operations.
For ghcjs, not having to deal with (non-c) languages yet, is actually a benefit. The ecosystem hasnāt yet been tainted much with anything but c. Thus if you can turn c ā JavaScript and generate bindings, you got a C integration. The fact that there is no package management solution you also need to deal with makes this quite tractable, and we do have ghcjs-c integration via emscripten. Asterius will do something similar with wasm via wasi.
1 Like
well, i still think there would be value in have a pure haskell implementation alternative which theoretically should be able to beat libsodium in terms of safety and reliability (not performance i guess), at least in the long term
3 Likes
java has its own cryptography libs (with irregular quality i guess) in pure jvm so you always could have the alternative of using them as jvm ffi of a hypothetical jvm backend for ghc
Yeah I would like to see a Haskell implementations of everything. Just put them behind a flag and make due note of things like timing side channels and whatever else not being investigated.
Itās good for cross compilation (even if C can work for JS, thereās always really obscure backends like Clash) and good for testing.
1 Like
Hmm, I wonder how one would deal with timing attacks in haskell. How to equalize the time spent with presence of laziness?