What is the difference between a sealed box and a normal box in libsodium?

Question

I'm trying to learn libsodium to better my crypto knowledge. One nagging question I have is what is the difference between libsodium's sealed box and their normal box? Not in terms of technicalities as the docs do distinguish this well; but in terms of practical use cases.

Per the docs:

Sealed boxes are designed to anonymously send messages to a recipient given its public key.

Only the recipient can decrypt these messages, using its private key. While the recipient can verify the integrity of the message, it cannot verify the identity of the sender.

A message is encrypted using an ephemeral key pair, whose secret part is destroyed right after the encryption process.

Without knowing the secret key used for a given message, the sender cannot decrypt its own message later. And without additional data, a message cannot be correlated with the identity of its sender.

Sadly this doesn't address the use case when this is needed. For example Say Alice generates a keypair and gives Charlie the untrusted 3rd party the public key for storage. Bob asks Charlie for the public key and sends Alice a message using said public key. From my limited understanding of this this should be secure and prevent Charlie from knowing the message. Is this not your basic end-to-end-trust-no-one system in the same vein as PGP?

If this system were to be implemented with an ephemeral key exchange as suggested by the sealed box concept would that not just add more overhead to an already secure system?

Perhaps I'm misunderstanding and perhaps my intended use case is different which is why I'll explain my mental model to better give context. (Also note I think the signal protocol uses ephemeral pre-keys and I also don't understand why in that context).

Alice runs an app on her phone which generates a unique keypair (unique in that it regenerates a new one every time the app opens) and then registers a unique address along with her public key with Charlie the back end server. The app then presents Alice with a URL that contains her unique address and a nonce. She shares this link with Bob who also opens the app providing it with the address and nonce. Bob's app generates a unique keypair then asks Charlie for Alice's public key (based on the address). Bob's app then encrypts Bob's public key along with the nonce and sends it to Alice (via Charlie). Alice's app verifies the nonce and then uses the provided Bob's public key and is now able to send him messages back.

AFAICT the above is a very basic key exchange through a third party in the same way we handle PGP key sharing on a key-server with the distinct difference in that once the session is over (app closed) the keys are no longer valid (secret keys erased) and a new session would be completely new identities and keypairs.

Is this even remotely related to the use of sealed boxes or have I only proved that I am sleep deprived and know nothing about crypto?

Answer 1

The premise of boxes is that Alice and Bob know each other and write to each other. Alice can use a box to send a message to Bob. On receipt of the box, Bob knows (a) it came from Alice, and (b) nobody else could have read or tampered with it.

The premise of sealed boxes is that Bob has an anonymous dropbox. Alice can use a sealed box to send a message to Bob. On receipt of the box, Bob knows nobody but the sender could have read or tampered with it. But he knows nothing about who the sender was—it could have been Alice, or Charlie, or Dominique.

The nonce is only required to be distinct for each message Alice sends to Bob, and vice versa. For example, Alice might count the number of messages she has sent so far, and use that number as a nonce. If the nonce is large enough, say ≥192, as it is in crypto_box_curve25519xsalsa20poly1305 (but not crypto_box_nistp256aes256gcm where it is 96), it can safely be chosen uniformly at random for each message and affixed to the ciphertext. The nonce need not be secret.

Neither boxes nor sealed boxes enables a third party to verify the authenticity of a message. For that, you need digital signatures.

If Bob's private key is ever compromised, whether for boxes or for sealed boxes, or if Alice's private key for boxes is ever compromised, then any message Alice has sent to Bob can be decrypted. To avoid this, protocols like Signal (a) regularly generate new keys and promptly erase the old keys for things like boxes,^* and (b) use long-term key pairs only for digital signatures to assert what the user's current box public key is, so that compromising the long-term private keys doesn't enable retroactive decryption.

---

_{^* A protocol that prescribes when to promptly erase keys is sometimes said to have ‘forward secrecy’, a term I prefer to avoid because in its glibness it obscures when the keys can be erased—which obscurity may serve to conceal lurking vulnerabilities like TLS session resumption even in sessions that use ‘forward secrecy’ cipher suites with ephemeral Diffie–Hellman key agreement.}

Answer 2

Couldn’t sleep and think I just answered mt own question.

The reason the mental model I had doesn’t fit with the use case of sealed boxes is in that the nonce described is a secret shared outside the system.

The use case for a sealed box would be if there were no nonce and the two parties wished to communicate an exchange of session keys. Bob would have to use an ephemeral key to initiate a dialog with Alice where nonces would be verified within the exchange I feel like this is what Signal is doing.

I also feel that in my case where we want the communication to be secured via a shared secret (the link) that a nonce is needed as part of the outside the system exchange leaving little need for any ephemeral pre-keys.

Please someone correct me if I am off here. I would hate to accidentally do crypto wrong.