Equivalent of Sodium's crypto_box_seal(..) / crypto_box_seal_open(..)?

[getify]

I see this quote on the README:

Nacl / Libsodium popularized term "secretbox", a simple black-box authenticated encryption. Secretbox is just xsalsa20-poly1305. We provide the alias and corresponding seal / open methods.

A couple of questions:

1. Sodium uses the term "secretbox" (crypto_secretbox_easy(..) and crypto_secretbox_easy_open(..)) for its symmetric authenticated encryption (same key for encryption/decryption). Further, they use the term "box" (crypto_box_easy(..) and crypto_box_easy_open(..)) for their asymmetric authenticated encryption (by generating an ephemeral keypair).

   But they use "sealedbox" (crypto_seal(..) and crypto_seal_open(..)) terminology for its un-authenticated (anonymous) asymmetric encryption/decryption.

   Do you support (have aliases for) all three of these: "secretbox", "box", and "sealedbox"? Or only some of them?

2. Where specifically on the noble-ciphers API are these various "seal / open method" aliases located? I couldn't find them.

---

My desired goal is to do the "sealedbox" equivalent with Noble, from this Sodium-using code:

let encBuffer = sodium.crypto_seal(msgBuffer, x25519pk, ivBuffer);
let msgBuffer_2 = sodium.crypto_seal_open(encBuffer, x25519sk, ivBuffer);

I'm trying to figure out if these aliases already exist, or if the pieces are there in Noble (Ciphers, etc) to do the equivalent operations, specifically where values would be interchangeable between a Sodium-using implementation and a Noble-using implementation.

Any thoughts/tips/guidance are appreciated.

[paulmillr]

"boxes" is something sodium invented, but never standardized. It's a mess. Since the package is 0-deps and limited to ciphers, it only supports secretbox. For an example of similar standardized effort, take a glance at HPKE RFC9180.

As mentioned in the README, those are equivalent:

import { xsalsa20poly1305 } from '@noble/ciphers/salsa';
import { secretbox } from '@noble/ciphers/salsa'; // == xsalsa20poly1305

The implementation is as follows:

noble-ciphers/src/salsa.ts

Lines 175 to 178 in 68c5250

	export function secretbox(key: Uint8Array, nonce: Uint8Array) {
	const xs = xsalsa20poly1305(key, nonce);
	return { seal: xs.encrypt, open: xs.decrypt };
	}

[getify]

So just to clarify, your library does not support/alias Sodium's notion of "seal"?

If so, may I suggest you take out/replace the reference to "seal" in your README, as I quoted above, to save others the confusion I've had? :)

[paulmillr]

Huh? It does. secretbox(key, nonce).seal(stuff)

[paulmillr]

"sealing" as verb is not limited to whatever new thing sodium invented https://pkg.go.dev/golang.org/x/crypto/nacl/secretbox#Seal

[paulmillr]

I will clarify there's no sealedbox or box.

[paulmillr]

For the simple "hybrid" encryption, besides standard rfc9180, you can use something like this:

const sharedKey = hkdf(x25519(privA, pubB), undefined, 'my-app', 32);
const nonce = randomBytes(32);
const cipher = xchacha20poly1305(sharedKey, nonce); // or xsalsa
cipher.encrypt(data);

[nichoth]

Thanks everyone for discussing.

If I were to implement this, looking at the example code @paulmillr posted, you call a function x25519 with privateA and publicB. Would that be equivalent to the function x25519.getSharedSecret(privA, pubB), as seen here?

[paulmillr]

Yes