minimal public-key authenticated encryption protocol

yoyo

10/31/23, 11:09 PM

One party (master) wants to send data to another party (slave) over an insecure channel using public-key encryption and signature schemes such that:

master is authenticated,
data is confidential,
data cannot be replayed.

The minimal assumptions are:

master has slave's public encryption key,
slave has master's public verification key,
the public keys are trusted (how they were obtained is immaterial).

The data can be chosen by master or not (e.g. maybe use a KEM instead of PKE to transmit random data). I would also like to protect against replay attacks. For an application, think of remotely (re)setting a key on some device without any pre-shared material; don't want adversary to replay previous exchange.

Something like encrypt-then-sign with a nonce:

master sends request to slave,
slave generates, stores, and sends nonce $r$ to master,
master encrypts data $d$ and nonce $c=\texttt{enc}(d\|r)$, signs the ciphertext $\sigma=\texttt{sig}(c)$, and sends both $(c,\sigma)$ to slave,
slave verifies and decrypts.

Or perhaps sign-then-encrypt with a nonce:

master sends request to slave,
slave generates, stores, and sends nonce $r$ to master,
master signs and encrypts some combination of data and nonce, e.g. $c=\texttt{enc}(d\|\texttt{sig}(d\|r))$, and sends ciphertext to slave,
slave decrypts and verifies.

Coming up with your own protocol is a bad idea, but I can't find a reference fitting my needs. Can someone give a reference or an outline of such a protocol (asymmetric primitives, one-sided authentication, replay protection)???

EDIT: Why not use TLS? Maybe I should, but I don't know the ins and outs of it. Some considerations:

There is no PKI; certificates would be self-signed if used.
There is no secure Diffie-Hellman I can use.
I don't need mutual authentication.
Can't use timestamps.
Don't need baggage like cipher suites etc.

0 + 4

key-exchange

authenticated-encryption

mentallurg

11/1/23, 12:03 AM

TLS fits all your requirements. Why don't you want to use it?

SAI Peregrinus

11/1/23, 1:05 AM

And if TLS somehow didn't work for you, there's almost certainly a [Noise](https://noiseprotocol.org/) pattern that will work.

Maarten Bodewes

11/1/23, 8:19 PM

What I understand from the question is a protocol that doesn't use symmetric encryption but instead simply encrypts the plaintext messages using asymmetric cryptography. Problem is that in most use cases encrypt-then-sign is not secure (as the signature can be stripped / replaced), and sign-then-encrypt is tricky because the message + signature will generally not fit into the maximum message size.

Maarten Bodewes

11/1/23, 8:22 PM

In general, instead of designing a new protocol, you could also take an existing protocol and strip all the overhead (e.g. you can assume the versions - except maybe for a single byte - algorithms, key sizes etc.).

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: minimal public-key authenticated encryption protocol

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.