We want to choose an asymmetric encryption scheme for use as follows:
- A device holds its private key, with the corresponding public key known and trusted by all.
- The device also holds a small $b$-bit secret bitstring $S$, assumed having been chosen uniformly at random and also known by one legitimate user, only.
- The device performs authentication rounds indexed by $i$, where it
- produces and outputs some wide (say, 256-bit) uniformly random and unpredictable nonce $N_i$;
- then receives a cryptogram assumed prepared by enciphering with the public key the plaintext $S\mathbin\|K_i$, where $K_i$ is some wide (say, 256-bit) uniformly random secret, and $N_i$ is an auxiliary input of the encryption (e.g. concatenated with the plaintext),
- then deciphers that cryptogram and performs some additional test (e.g. comparing $N_i$ in the deciphered plaintext to the last $N_i$ produced);
- if that succeeds
- if the field of the deciphered plaintext expected to contain $S$ in fact contains something else, locks up forever;
- otherwise, makes some use of $K_i$.
The legitimate user tries, indefinitely, to performs authentication rounds per that protocol across a public channel where an adversary can perform MitM. The adversary succeeds is s/he manages, with probability sizably better than $2^{-b}$, that the device uses a $K_i$ known to the attacker, or a $K_i$ other than one encrypted by the legitimate user after the device last drew $N_i$. We assume the device's implementation is immune to side channel and fault attacks, and disregard DoS attack locking the device.
What's the weakest well-studied security property that a generic asymmetric encryption scheme must meet to be safely usable with that protocol, when the cryptogram is $S\mathbin\|K_i\|N_i$ and the later field is checked against $N_i$ after decryption?
Is it OK to use RSAES-OAEP of PKCS#1v2.2 with label $N_i$ and plaintext $S\mathbin\|K_i$ ?
What ECC-based encryption scheme has that property? Or can we make one?
Motivation: this is a simplified model of user PIN presentation to a Smart Card, by a method assuming no secret beyond the PIN on the presenter side, where some card OS API makes the PIN accessible only thru a comparison primitive (preventing the use of PAKE), we ignore the customary allowance of up to two or so consecutive errors, and we want a bare minimum of communication passes in a round. The dual success criteria mimics both use of $K_i$ as (or towards derivation of) a session key for a secure channel, and allowing some operation independently of $K_i$ after PIN-based authentication.
