Releasing crypton v2.0.0
Hello cafe, I have posted a new blog article on "crypton": https://kazu-yamamoto.hatenablog.jp/entry/2026/09/25/110313 --Kazu
In your blog you mentioned you asked Claude about botan and it said:
Binary distributions for Botan might not be available, and building from source—given that it is written in C++—imposes a heavy burden in terms of setting up a C++ compiler.
This is hot garbage. GHC already kinda depends on C++ (e.g. building the text package will link against stdc++). There's virtually no operating system that doesn't have access to a C++ compiler. Users who want to link statically will have to jump through some hoops. But that's already the case for many packages. We could also provide a botan-clib package that converts the upstream library into a haskell package. I've done the same for libffi. It's not always trivial, but it can be done. On September 25, 2026 2:07:39 AM UTC, "Kazu Yamamoto (山本和彦) via Haskell-Cafe" <haskell-cafe@haskell.org> wrote:
Hello cafe,
I have posted a new blog article on "crypton": https://kazu-yamamoto.hatenablog.jp/entry/2026/09/25/110313
--Kazu
_______________________________________________ Haskell-Cafe mailing list -- haskell-cafe@haskell.org To (un)subscribe, modify options or view archives go to: Only members subscribed via the mailman list are allowed to post.
Hello cafe,
I have posted a new blog article on "crypton": https://kazu-yamamoto.hatenablog.jp/entry/2026/09/25/110313
Just FYI: In crypton v2.1.2, thanks to AWS's s2n-bignum library, P-256 performance now rivals that of OpenSSL. The next target is RSA. https://github.com/kazu-yamamoto/crypton --Kazu
On Sun, Sep 27, 2026 at 07:30:02AM +0900, Kazu Yamamoto (山本和彦) via Haskell-Cafe wrote:
Hello cafe,
I have posted a new blog article on "crypton": https://kazu-yamamoto.hatenablog.jp/entry/2026/09/25/110313
Just FYI: In crypton v2.1.2, thanks to AWS's s2n-bignum library, P-256 performance now rivals that of OpenSSL. The next target is RSA.
Many thanks for this work. Much appreciated, from both a security (attention to constant-time) and performance perspective. I've rebuilt the DNSSEC/DANE survey engine to use crypton 2.1 and it is working well (though TLS is not performance critical, since the engine's performance is constrained primarily by network-latency rather than CPU, thus uses 1400 forkIO threads to amortise an average latency in excess of 100ms). Just one nit on the README.md, the X86_64 numbers are said to be measured against OpenSSL 3.0, which is rather dated and has just reached end-of-life. The fair comparison is head-to-head, so against either 4.0 (released in April) or the "master" branch. Yes, that could mean building from source. The now outdated 3.0 release had notable performance regressions, being a major redesign of the OpenSSL core for modularity, and much subsequent effort went into streamlining its performance in later releases. Yes, the assembly modules and base cryptography algorithms (once fetched and used to perform multiple operations) may have been less affected in various use cases, but it is now prudent to use 4.0 or later when making measurements. -- Viktor. 🇺🇦 Слава Україні!
Hi Viktor,
Just one nit on the README.md, the X86_64 numbers are said to be measured against OpenSSL 3.0, which is rather dated and has just reached end-of-life. The fair comparison is head-to-head, so against either 4.0 (released in April) or the "master" branch. Yes, that could mean building from source.
Thank you for letting me know this. Since my token has exhaused, I can't do it right away, but I will update the comparison table within a few days. --Kazu
participants (3)
-
Julian Ospald -
Kazu Yamamoto -
Viktor Dukhovni