Does libsodium sealed box leak key ids?

I am using python and libnacl, which is a libsodium wrapper, to develop an application where users can deposit encrypted data.

Alice uses libnacl.sealed.SealedBox(keyBob) to encrypt her message and uploads it to a database for Bob to download it. Bob and Eve can read the database and observe there I a new entry. Neither Eve nor Bob cannot tell that the message was sent by Alice. Bob can decrypt the message and therefore knows that he is the recipient.

Eve also knows Bob's public key. Can Eve tell that the message's recipient is Bob?

edit:
VincBreaker pointed me at the documentation of libsodium sealed box where you can find:

ephemeral_pk ‖ box(m, recipient_pk, ephemeral_sk, nonce=blake2b(ephemeral_pk ‖ recipient_pk))

This tells some "ephemeral" public key is included in the sealed box.
What does "ephemeral" mean?
To be precise is there a way to link the ephemeral_pk to Bob's actual public key?

• By looking at download.libsodium.org/doc/public-key_cryptography/sealed_boxes , especially the last line "ephemeral_pk ‖ box(m, recipient_pk, ephemeral_sk, nonce=blake2b(ephemeral_pk ‖ recipient_pk))" hints at the public key somehow used in the box context. However I could not find any reference whether is used for key exchange, aad or public data. – VincBreaker Jan 28 '19 at 19:45
• @VincBreaker thank you, this is the real question. Can the ephemeral_pk be linked to the original pk? I'll update the question. – Brolf Jan 29 '19 at 14:46
• ephemeral_pk cannot be linked to the original pk as it randomly generated for each sealed box. – VincBreaker Jan 29 '19 at 15:26

2 Answers

The answer from the libsodium web site

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.

While Bob can decrypt the message and cannot verify the identity with his public and private key pair, there is no way the Eve can determine with the only public key.

To understand the sealed box we must first see the crypto box.

Crypto Box Structure

Cryptobox encrypts and authenticates a message $$m$$ using the sender's secret key and receiver's public key and a nonce $$n$$.

$$c = box(m,nonce,recipient_{pk},sender_{sk})$$

The receiver, verifies the and decrypts the $$c$$ by using his secret key and sender's public key.

Sealed Box Structure

A sealed box constructed only using the public key of the recipient. The sealed box is;

$$sealed\_box = ephemeral_{pk} \| box(m, recipient_{pk}, ephemeral_{sk}, nonce)$$ $$nonce = blake2b(ephemeral_{pk} \| recipient_{pk})$$

an ephemeral private and public key pair (generated and used once) is generated and later the ephemeral private key is destroyed.

Therefore, the sealed box contains no information about the sender. Since the sealed box can only be opened by the $$recipient_{sk}$$ the Eve cannot understand the recipient, too.

However, Eve can look for who downloads the message. Without it how is going to Bob know that there is a message for him? The best way to protect from this is;

1. Bob check himself
2. Bob uses Private Information Retrieval to hide the data he access.

Also, this answer for What is the difference between a sealed box and a normal box in libsodium? might be helpful.

• I know that no information about the sender is included in a sealed box but my question is regarding information about the recipient. Does the sealed box leak information about the recipient? – Brolf Jan 29 '19 at 14:31
• @Brolf I've looked at some implementations as TweetNacl. The ciphertext doesn't contain any information about the receiver. – kelalaka Jan 29 '19 at 20:27

The recipient's public key should have been securely transmitted to the sender prior to encrypting anything with it.

And the ciphertext itself doesn't include any information about the recipient.

However, if the recipient's secret key ever gets revealed, previously captured ciphertexts can be decrypted using that secret key.