Public Key / Box Encryption?

[NullVoxPopuli]

Is this library going to support Public Key / NaCl Box Encryption? Was looking at the wiki:

And I'm not sure if Public Key Encryption can be built from these things? Is this one of the non-goals? I saw on the readme that

The legacy libhydrogen code (leveraging XChaCha20, SipHashX, BLAKE2SX, Curve25519) remains available in the v0 branch.

and I know that Curve25519 is used in NaCl Box Encryption. so.. idk. :man_shrugging:

[jedisct1]

Hi,

Of course it supports public key encryption. box is a legacy API, and even in libsodium I can't think of any compelling reason to keep using it.

Look at the Key Exchange section. These functions can create key pairs, and use them to compute a shared secret. Once you have that shared secret, use it withsecretbox.

The closest construction to box (no forward secrecy, no authentication) would be the N variant without a pre-shared key + secretbox. The noise N variant without a pre-shared key is equivalent to libsodium's crypto_kx.

[NullVoxPopuli]

ah ok, cool. So, constructing that reminds of the process for using AES with RSA.

Is there an example / test somewhere that I could reference as I play around with this? Also, does there exist WASM bindings? ;)

[jedisct1]

Look at the documentation for the N variant. Or, if both parties already know their peer's public key, look at the KK variant. It should be pretty self-explanatory.

The KK variant requires an extra packet, but you get forward secrecy (each session will use a different shared key).

libhydrogen compiles fine to webassembly, and supports WASI. But there are no clean Javascript bindings yet.

[marek22k]

Of course it supports public key encryption. box is a legacy API, and even in libsodium I can't think of any compelling reason to keep using it.

Hi, I hope it's okay if I ask here: Are you referring to crypto_box_* in libsodium? Why is it legacy?

[rustonaut]

From a educational POV it would be grate to explain why box is legacy in the libsodium documentation.

I'm not an expert in this field at all but as far as I understand:

• NaCL crypto_box_* has some suboptimal design choices I'm not sure if @jedisct1 was referring to this

• libsodiums crypto_box with _easy and _detached has "replaced" NaCL crypto_box_*

• crypto_box with _easy/_detached still has a bit of sub-optimal API wrt.:

  • it doesn't use any context (i.e. neither a key derivation with context nor associated data)
  • it doesn't allow specifying a pre-shared key in the key exchange
  • it doesn't come with forward security

So by now it's not that rare to explicitly do a key exchange + a AEAD chipher for encryption passing some AD. Or to use a key exchange followed by using HKDF for generating subkeys with a specific context.