How do cryptohash-sha256 et al fit into this? Are these packages considered trustworthy? Should they ultimately also be deprecated in favor of libsodium?
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.
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.
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
<target-triple>-cc, and unless someone uses architecture specific code only (
scrypt), it basically just works.
One reason for not squashing is that since the last release of cryptonite there have been a few commits which have broken the build.
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.
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?
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.
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
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.
Hmm, I wonder how one would deal with timing attacks in haskell. How to equalize the time spent with presence of laziness?