# NACL with public key encryption and authentication

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 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. Dec 30 '19 at 11:14
• I think you are confusing. Who will force the sender to delete? See also the sealed_boxes Dec 30 '19 at 12:11
• I am controlling both sides, so i know that i deleted the ephemeral key. Jan 2 '20 at 8:12

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.