API Thoughts - Githubissues

Seems like @jedisct1 has made this library, at least in part, as a bit of an experiment in API design. So maybe feedback/thoughts like this are just way too late, and there's no longer interest in making any changes. In any case here's some thoughts :)

I used libsodium's crypto_aead_chacha20poly1305_ietf_encrypt AEAD to implement a secure protocol over UDP for an online game. The packet structure had some unencrypted data, followed by some encrypted data, with the authentication appended to the end.

libsodium was replaced with libhydrogen just yesterday, and it was a little bit difficult due to minor API differences. We have access to hydro_secretbox_encrypt for encrypting, but for the unencrypted (but still authenticated) data hydro_sign_create was used. It just seems a little unfortunate as a couple hiccups popped up.

Both hydro functions compute an initialization vector and an authentication tag. This required a slight restructuring of my packets when switching from libsodium, and uses a little more packet memory than necessary.
hydro_secretbox_encrypt prepends data to a buffer, while crypto_aead_chacha20poly1305_ietf_encrypt (combined mode) appended data. And so the packet layout had to be adjusted. It's possible to just memcpy out the 20 bytes for the IV and 16 bytes for the tag to use my old packet layout... But this breaks the abstraction of hydro_secretbox_encrypt.

Now I don't understand the underlying algorithms all too well, but from a cursory understanding it seems like a slight API redesign might be really good. I think libhydrogen's small size is absolutely wonderful, and that's why I switched despite the above headaches. Very simple to integrate! For my use case if another more advanced version of hydro_secretbox_encrypt existed that accepted additional data and let me specify a pointer to write the output IV + tag, it would overall have been a perfect library.

jedisct1 / libhydrogen

API Thoughts #110