search

thoughtpolice / salt

Fast cryptographic networking for Haskell
http://thoughtpolice.github.com/salt
MIT License
24 stars 1 forks source link

Sodium dependency #27

Closed tel closed 11 years ago

tel commented 11 years ago

I wanted to raise question about basing this library off of Sodium instead of raw nacl due to Sodium's desire for portability. I cannot provide justification for or against personally at this point, but instead simply have noticed a trend of using Sodium for NaCl bindings in other languages.

Currently, to my knowledge, Sodium is compatible with NaCl excepting its use of SUPERCOP's Ed25519 implementation for crypto_sign_*. According to the NaCl docs this is the implementation that will eventually replace the current crypto_sign_* in NaCl, so it's hopefully only a temporary incompatibility.

thoughtpolice commented 11 years ago

We already explicitly use ed25519 for the signature API in salt; see commit e9cc79508a1c6b9ec74e0dd9d3cbf625ccbd5148 (related, see commit f9c4472506083d36343af8abbe858f0db8fc8662 in which I backed out the optimized-implementations due to bug #14. I'm unaware if SUPERCOP has a fixed implementation as of now.) I did this for the same reasons as them: to pre-emptively ensure users are future compatible, and save them gray hairs. As a result we should be completely compatible with Sodium for now and the forseeable future.

My primary reservation is that they seem to be consistently shifting around the API tiny bit-by-bit. I have given them some feedback on what I personally thought were some bad API decisions (which are minor, but important for the Haskell binding.) The library also moves significantly faster (having seen several point releases since the announcement) and this has variously changed the way things are linked for example. This is actually cleaner than using the glue implementations, but it also means a lot of shuffling in order to keep up with any other changes that might happen.

Another point is that Sodium requires your traditional autoconf-dance to install. That means it's fairly unsuitable for inline inclusion into the library, which I believe is a win from a user and distribution standpoint (notably in the uptake for users - is Sodium, for example, in ANY package manager, for any largely-used Linux distro that isn't ArchLinux or something similarly bleeding edge?) The fact salt includes the patched nacl-20110221 and doesn't require any setup is a large win for users, in my opinion.

On the other hand, the current facility to support distributing nacl with the cabal package is an incredible hack to the nth degree (for pretty much any n you can think up or write down.) It could very likely be fixed (for good) with some extra help from Cabal, however. But I have not had time to do this.

Finally, I am also unsure of what the scope of their changes will be over time. For example, it has also adopted BLAKE hashes, but should we support them? Especially since Keccak is officially the SHA3 winner, this is a question worth asking. Users won't know the difference beyond perceivable speed (and users really can't - in general - be relied upon to make a sound decision regarding the merits of either choice,) so it'd ultimately be better for us to just make the decision for them. There's even the argument we shouldn't necessarily expose low-level hashes at all, because they're typically building block primitives of larger things (ergo, if you need it, you might be doing it wrong.) My worry is that eventually people will start using things, and then get angry we don't support their favorite random thing. This will - for better or worse - force pressure to completely switch.

Windows users are still currently SOL in any case, if you ask me. I wouldn't wish autoconf upon them if you paid me to. Dynamic linking is also currently out of the mix for any forseeable future, which sucks. But neither Sodium nor NaCl solves this problem while retaining high-performance primitives (we need position-independent versions of the generated assembly.)

Sodium certainly seems to be evolving NaCl development much more quickly than it was before. (This is good, because apparently DJB exists in a vacuum where public source control/review mechanisms/public development never entered existence.) But I think it is still a little too new and moving a bit to make a clear value judgement. It is definitely worth reconsidering over the next couple of months.

tel commented 11 years ago

Sounds like a very well-considered point of view. I think my primary interest in Sodium came from the DJB-vacuum you refer to that also excludes all code that isn't (a) written in C or C++ and (b) expected to exist in any environment that's less than down-to-the-byte meticulously controlled.

I didn't realize Sodium had made larger changes such as including the BLAKE hashes. I had assumed for compatibility's sake it intended to stay true to the source source, but it clearly takes a less hardline opinion than DJB's security impact of a new cryptographic library-POV leaves you with.

I suppose my primary concern is that Sodium will eventually exhibit genetic drift from NaCl "core" and this library will lose the ability to communicate on par with implementations in other places.

thoughtpolice commented 11 years ago

FWIW, their BLAKE extensions are just that. They did not change the crypto_hash API from SHA512 (the current NaCl default) to BLAKE, merely added new crypto_hash_blake... functions (this is from my memory.) However, my general opinion is that if you give users something, they're going to use it (and thus you should be careful what you give them.) So it's not unthinkable that people may want BLAKE implementations down the line, for whatever reason (interop, for example.)

They are also very aware of the possibility of Sodium becoming a "catch all" library should this kind of behavior go unchecked, and I don't think this will happen at all. I think BLAKE is one of the few (if not the only) extra addition in terms of "brand new thing that wasn't in the core already." Despite that they are also adopting things beyond the current core specification of NaCl itself. That's not necessarily a bad thing, but can be enough to build pressure to switch - once users start banging on your door.

I too am worried about the drift, but not too worried. Several of the problems are technical ones, and sodium does solve several of them (like the build system not being there.) Unlike NaCl, it eventually WILL be possible to get it from a package manager. It won't have a crazy, weird build step. It will probably finally be available on Windows.

It is actually entirely likely the situation will end up all for the better, and not worse at all, despite my negative appearances (if they are so.) But that won't happen in the immediate future, and I think letting the library bake a little bit, and hit some larger distribution is the best choice instead of playing catch up for now.

tel commented 11 years ago

Oh—that's incredibly much better.

I don't think there are negative appearances as much as a lot of obvious tradeoffs to be played as you move from a DJB library to a apt-get-able library. I frankly have had a hell of a time convincing anyone to use NaCl purely because it doesn't let you pick your crypto primitives—even after reading Security Impact (!)—so Sodium walks a fine line adding more flexibility.

So this discussion is exactly what I was hoping to have and learn more via. I think the future for Sodium is potentially quite bright and it's use as a target for library implementation great. As long as it's API compatible with NaCl there's no hurry to move to it (or away from it).