Higher-level API (Krypt?)

[Tony Arcieri]

Hey there, I hope we can move this discussion onto the Google Group ;)

https://github.com/cryptosphere/rbnacl/issues/42

There have been a request for more standard features of cryptographic libraries, like a way to serialize certificates and ciphertexts in a meaningful way that identifies the primitives involved.

My personal vote (barring some radical improvement in the Sodium space) is to use Krypt for this. I think it really makes sense for Krypt to be the central project that can provide these sorts of features to libraries like RbNaCl that can act as Krypt providers.

--
Tony Arcieri

[Stephen Touset]

To continue the discussion from GitHub:

> The problem with that is it leaves a C library where you have a developer specified

> way of deciding which algorithms to call. I don't think that's what libsodium should

> be. The beauty of NaCl/libsodium to me is that the C API is high level. That's part

> of what made writing RbNaCl so easy, and let me be more confident in its security

> properties. The goal of the library is that the developer can call

> crypto_box(mt,mlen,ct,nonce,key) and let it worry about the details of

> security, so that call needs to understand what is being passed in. So something

> that can work with opaque strings actually seems right.

This is a fair criticism, but libsodium *already* provides a developer-specified way of deciding which algorithm to call. crypto_secretbox is actually crypto_secretbox_xsalsa20_poly1305. And so a developer needing backwards compatibility, or needing to use a *specific* algorithm, is supported.

RbNaCl *must* at least provide a way to access these. If not, data output from one version of RbNaCl will be completely unable to be used in another version. There's no way to gracefully migrate forward. Whether or not that can be automatic (or automatic-ish) is a separate question.

Further, I think really high-level APIs are something that needs to be available to Rubyists. Even with current RbNaCl, there are too many ways a developer can shoot him/herself in the foot. RbNaCl will accept any string of appropriate length as a key, which practically guarantees that users will use unsafe sources of randomness. The same key can be used across multiple cryptographic primitives, which, while I don't believe there are currently practical attacks, is something that should be prevented.

I'm all for libsodium being a raw port of DJB's NaCl, and RbNaCl being a pure Ruby binding on top of it. And I can pursue writing my own ideas for a high-level library on top of this stack. But RbNaCl *must* then expose the alternate algorithms for libsodium.

[Tony Arcieri]

We will definitely support all algorithms available in both future NaCl releases (e.g. AES) and future Sodium releases (e.g. Blake2, PHC)

--
Tony Arcieri

[Stephen Touset]

You mean in Krypt, or RbNaCl?

[Tony Arcieri]

On Tue, Mar 12, 2013 at 11:47 AM, Stephen Touset <ste...@touset.org> wrote:

You mean in Krypt, or RbNaCl?

RbNaCl is the actual binding to NaCl/Sodium and will support all available algorithms 

--
Tony Arcieri