NACL with public key encryption and authentication

Question

As suggested in this answer i can use nacl for public key encryption with:

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

But if i want also the sender to verify that it is him. Would the practice to use HMAC with preshared key or using a box as nonce be safe?

Something like:

ephemeral_pk ‖ box( m, recipient_pk, ephemeral_sk,
           nonce=HMAC(ephemeral_pk ‖ recipient_pk, hmac_key))

or like:

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

I was looking into the tweetnacl implementation. And there it appeared to me that the nonce length is 24 bytes. So i would have to truncate the nonces created with HMAC or box. Would this impact the overall security in an negative way? The third possibility would be to sign the secret with sender_sign_sk and provide sender_sign_pk to the recipient. From my trials i got the speed of the hmac solution to be on par with the normal hashing solution. The box solution is about 1.5 times slower and the solution with additional signing is about 3 times slower.

NACL also has Crypto Box. The first construction is the cryptobox — kelalaka, Dec 27 '19 at 18:03
Crypto Box is different because the sender which encrypts the message can also decrypt it. In my scenario the sender discards the ephemeral private key directly after encrypting every message. — Florat, Dec 30 '19 at 11:14
I think you are confusing. Who will force the sender to delete? See also the sealed_boxes — kelalaka, Dec 30 '19 at 12:11
I am controlling both sides, so i know that i deleted the ephemeral key. — Florat, Jan 02 '20 at 08:12

score 1 · Answer 1 · answered Dec 27 '19 at 21:31

If I understand properly, you want to use ephemeral keys, and verify the identity of the sender.

A HMAC would not be enough to verify the identity of the sender, because the recipient is able to compute a valid authentication tag as well.

Signing the message before encrypting it solves this. Note that in that case, the message can simply be a random session key. So, for most applications, the cost is pretty low: signing is only required once, during key exchange. If this is acceptable for your application, this is probably the easiest route to go.

Otherwise, the Noise framework can be used to build secure key exchange protocols, according to what each participant knows about its peer. I would highly recommend using these patterns instead of inventing your own.

Do both the client and the server know about each other's public keys? The Noise KK pattern is likely to be the one you are interested in. Or if you have a single client, NNpsk0 is faster as it requires a single DH operation.

Thank you for suggesting the Noise framework. I will look into it. They both know each others public keys. — Florat, Dec 29 '19 at 11:34

NACL with public key encryption and authentication

1 Answers1