5 ms·

I'm not sure that im entirely convinced by the arguments against libsodium. Wouldnt it be possible to extend/fork libsodium where one could create a simpler api

by Ninn 9y ago

I'm not sure that im entirely convinced by the arguments against libsodium. Wouldnt it be possible to extend/fork libsodium where one could create a simpler api to automatically force (or atleast default to) correct nonce handling?

lvh 9y ago
Yes, I believe that's possible, though not necessarily with the same performance. I built magicnonce [1] explicitly with two properties in mind: * the simplest possible synthetic nonce design that's "obviously" correct for some useful value of correct. * uses only explicitly exported libsodium APIs. It's an off-line scheme like SIV, because the users I'm targeting don't care about on-line schemes. If you really care about on-line schemes, I think the simplest, most practicable solution right now is to just use an large nonce scheme (like secretbox) filled with random bits. To give you an idea about performance and to continue with the author's gracious use of unflattering benchmarks, my Clojure+FFI code is about 20% slower than his AES-SIV-PMAC code. It should probably just publish it on IACR instead of just in a random module of my libsodium binding. [1]: https://github.com/lvh/caesium/blob/master/src/caesium/magicnonce/secretbox.clj https://github.com/lvh/caesium/blob/master/src/caesium/magic... One could argue that it is still desirable to have fast, AES-based algorithms, and I think that both this article and related work (e.g. the AES-GCM-SIV paper) do a reasonable job of making that point. For example, my cost function assumes libsodium is free but implementing any nontrivial crypto is very expensive. If that's not true, say, in resource-constrained embedded environments (libsodium not free, developing crypto par for the course), I can totally see why you'd end up with SIV or SIV-PMAC: you just need one really fast implementation of an established primitive (AES). Really anywhere where the platform hasn't tilted the table in favor of GCM by having CLMUL instructions, AES-SIV-PMAC should dominate both from a performance and safety perspective.
bascule 9y ago
There are plans to address this in libsodium. Here are some relevant issues: https://github.com/jedisct1/libsodium/issues/361 https://github.com/jedisct1/libsodium/issues/361 https://github.com/jedisct1/libsodium/issues/392 https://github.com/jedisct1/libsodium/issues/392

by Ninn 9y ago

lvh 9y ago

Yes, I believe that's possible, though not necessarily with the same performance. I built magicnonce [1] explicitly with two properties in mind: * the simplest possible synthetic nonce design that's "obviously" correct for some useful value of correct. * uses only explicitly exported libsodium APIs. It's an off-line scheme like SIV, because the users I'm targeting don't care about on-line schemes. If you really care about on-line schemes, I think the simplest, most practicable solution right now is to just use an large nonce scheme (like secretbox) filled with random bits. To give you an idea about performance and to continue with the author's gracious use of unflattering benchmarks, my Clojure+FFI code is about 20% slower than his AES-SIV-PMAC code. It should probably just publish it on IACR instead of just in a random module of my libsodium binding. [1]: https://github.com/lvh/caesium/blob/master/src/caesium/magicnonce/secretbox.clj https://github.com/lvh/caesium/blob/master/src/caesium/magic... One could argue that it is still desirable to have fast, AES-based algorithms, and I think that both this article and related work (e.g. the AES-GCM-SIV paper) do a reasonable job of making that point. For example, my cost function assumes libsodium is free but implementing any nontrivial crypto is very expensive. If that's not true, say, in resource-constrained embedded environments (libsodium not free, developing crypto par for the course), I can totally see why you'd end up with SIV or SIV-PMAC: you just need one really fast implementation of an established primitive (AES). Really anywhere where the platform hasn't tilted the table in favor of GCM by having CLMUL instructions, AES-SIV-PMAC should dominate both from a performance and safety perspective.

bascule 9y ago

There are plans to address this in libsodium. Here are some relevant issues: https://github.com/jedisct1/libsodium/issues/361 https://github.com/jedisct1/libsodium/issues/361 https://github.com/jedisct1/libsodium/issues/392 https://github.com/jedisct1/libsodium/issues/392