Support for XSalsa20Poly1305

[madsodgaard]

Many other systems and languages use something like libsodium for AEAD. libsodium uses XSalsa20Poly1305 and not ChaCha20Poly1305 which means that we cannot easily support communication with these other systems, without introducing a dependency on the libsodium C library, for example on iOS or server-side.

Is the swift-crypto team open to the idea of adding support for XSalsa20 in the _CryptosExtras? Unfortunately, BoringSSL does not provide any APIs for this (but they do for Poly1305). The implementation of xsalsa20 would be written in Swift. However, I was uncertain whether any non-boringSSL APIs were allowed in this library or not.

I'd be happy to help drive the implementation forward!

[Lukasa]

Thanks for this!

To begin with, can I suggest that you wrap libsodium directly in APIs that look quite a lot like Crypto? Having canonical libsodium bindings is probably pretty useful in the Swift ecosystem, and they should be API compatible with what Crypto does. It's very possible that that's a better solution than placing the work in here, as it allows users who don't want the complexity of a complete BoringSSL story to use libsodium instead.

If it turns out after doing that that the community would still prefer to bring the APIs into CryptoExtras, we can revisit the issue. How does that sound?

[madsodgaard]

@Lukasa thanks for the comment Cory!

Just to make sure I understand what you meant. You are suggesting that I instead create a separate repository for just needed missing APIs and use libsodium to provide a similar interface as CryptoKit (like this swift-crypto does it) instead of users using something like https://github.com/jedisct1/swift-sodium

I was just thinking that swift-crypto contains quite a lot of useful utilities for such a package, in terms of working with bytes, buffers and something like SecureBytes. Those would likely be duplicated across such a package. But I also agree that depending on BoringSSL AND sodium in CryptoExtras would be a pain if you only need XSalsaPoly1305 for example. Hence my idea with a Swift implementation instead.

What are your thoughts?

[Lukasa]

I was just thinking that swift-crypto contains quite a lot of useful utilities for such a package, in terms of working with bytes, buffers and something like SecureBytes. Those would likely be duplicated across such a package.

Yeah, this is definitely a downside. However, as those files are open-source, you can safely copy them out and use them in a side package. They are not receiving rapid changes at this time so I don't think there's an immediate risk that the code would fall out of scope.

I also agree that in this package we'd probably not want a libsodium dependency. I think my biggest concern right now is getting a feel for how well those APIs fit into the ecosystem and what the need is. I'm definitely not opposed to us doing this once we've proven out the implementation, I just think it's useful for us to start with an out-of-tree implementation to prove the value before we move it into this package.

If you wanted to start with a Swift implementation out-of-tree, that's also a useful thing to do.