Call for early adopters of Sel, Botan and one-time-password

The Haskell Cryptography Group is calling for early adopters of sel, botan-low, and one-time-password which provide reliable and well-documented bindings to libsodium and botan, as well as an implementation of OTP codes (TOTP and HOTP) backed in large part by sel.

https://haskell-cryptography.org/blog/early-adopters-call-sel-botan/

5 Likes

Just as an aside, you may want to tweak the mobile CSS of the website:

1 Like

From a quick glance: I think it might be a bit misleading to present sel as “bindings to libsodium”. It seems to be a fine “cryptography toolkit for the unsuspecting developer”, but if you approach it with the expectation of finding all the familiar libsodium functionality wrapped in straightforward Haskell, then this is not it (but libsodium-bindings looks like it would be).

Also, though I’m not 100% sure whether this warrants any action, sel does not explicitly address the mlocking issues it inherits from libsodium. The issue, specifically, is that sodium_malloc() will attempt to mlock any memory it allocates, but if it fails, it will silently carry on without mlocking. For many applications this is perfectly acceptable, but when you rely on secret keys never being written out to disk, or when your swap volumes are not encrypted (for whatever reasons), this can be a problem. Libsodium itself recommends calling sodium_mlock() explicitly in such cases, but doing so uncritically can lead to other problems, especially when, like sel does, you rely on finalizers and GC to deallocate your keys, because quota on mlocked memory tend to be pretty strict, and you can easily overrun those.

For a turn-key-don’t-make-me-think-about-cryptography library like sel, this is of course a conundrum - if you want to offer users a “just works” experience, you can’t mlock everything uncritically, but that also means you will not be able to offer adequate security for some use cases. Personally, I would consider at least warning about this in the documentation.

5 Likes

I think amazonka is too big and heavy to be a botan early adopter, but I look forward to porting it over once things are ironed out. Not that this has stopped @axman6 from trying, and writing up his thoughts.

1 Like