 Jun 2020

eprint.iacr.org eprint.iacr.org243.pdf1

The necessity ofskRbeing secure for sender authentication is due to HPKEbeing vulnerable to keycompromise impersonation.
Tags
Annotators
URL

 May 2020

nvlpubs.nist.gov nvlpubs.nist.gov

(Thus, for these curves, the cofactor is always h = 1.)
This means there is no need to check if the point is in the correct subgroup.

 Mar 2020

moderncrypto.org moderncrypto.org

Thus it's an incomplete fix, and the correct solution is binding the transcript.

It's wellunderstood nowadays that channel binding must cover the session transcript.

A safe DH protocol is easy to instantiate with a wide range of DH algorithms, and in many cases nonDH key agreements (e.g. postquantum algorithms, and encryption like RSA).

X25519 is very close to this ideal, with the exception that public keys have easilycomputed equivalent values. (Preventing equivalent values would require a different and more costly check. Instead, protocols should "bind" the exact public keys by MAC'ing them or hashing them into the session key.)

Curve25519 key generation uses scalar multiplication with a private key "clamped" so that it will always produce a valid public key, regardless of RNG behavior.

* Valid points have equivalent "invalid" representations, due to the cofactor, masking of the high bit, and (in a few cases) unreduced coordinates.

With all the talk of "validation", the reader of JP's essay is likely to think this check is equivalent to "full validation" (e.g. [SP80056A]), where only valid public keys are accepted (i.e. public keys which uniquely encode a generator of the correct subgroup).

(1) The proposed check has the goal of blacklisting a few input values. It's nowhere near full validation, does not match existing standards for ECDH input validation, and is not even applied to the input.


research.kudelskisecurity.com research.kudelskisecurity.com

If Alice generates allzero prekeys and identity key, and pushes them to the Signal’s servers, then all the peers who initiate a new session with Alice will encrypt their first message with the same key, derived from allzero shared secrets—essentially, the first message will be in the clear for an eavesdropper.

arguing that a zero check “adds complexity (consttime code, errorhandling, and implementation variance), and is not needed in good protocols.”


eprint.iacr.org eprint.iacr.org

Figure 7: Onephase experiment
I use this security notion for DHKEM

We then considerthe same question for keyencapsulation mechanisms (KEMs)and show that in this case the fournotionsareall equivalent.


newhopecrypto.org newhopecrypto.org

SHAKE256(96,μ‖SHAKE256(32,pk))
This is the same G(mH(pk)) construction as in Kyber.
Tags
Annotators
URL


pqcrystals.org pqcrystals.org

Asimilarstatementholdsforadditionallyhashingtheciphertextintothenalkey.Severalproto colsneedtoensurethatthekeydep endsonthecompleteviewofexchangedproto colmessages.Thisisthecase,forexample,fortheauthenticatedkeyexchangeproto colsdescrib edintheKyberpap er[22,Sec.5].Hashingthefullproto colview(publickeyandciphertext)intothenalkeyalreadyaspartoftheKEMmakesitunnecessary(althoughofcoursestillsafe)totakecareofthesehashesonthehigherproto collayer
Here is their reasoning about why the public key and the ciphertext are used in the “context” of the key derivation.

InanearlierversionofKyberweinstantiatedH,G,andPRFallwithSHAKE256.WedecidedtochangethistodierentfunctionsfromtheFIPS202familytoavoidanydomainseparationdiscussion.
Random oracle cloning by using different hash functions.

KDF( ̄K‖H(c))
Here they put the ciphertext into the “context” as well, just like FrodoKEM.

G(m‖H(pk))
 this makes the shared secret dependent on the exact public key; good in case there would be equivalent public keys
 this construction looks a bit similar to HMAC, but not exactly; how do they model it in the security proof? SHA2 is vulnerable to length extension attacks!

weinstantiateKDFwithSHAKE256
Interesting that the last derivation step is done with Keccak even in the 90s variant. Probably for security reasons. Todo: look at the proof to see if they assume RO for KDF.

Asanadditionalup dateforround2,wealsopresentavariantofKyberthatinsteadofrelyingonKeccakforallsymmetricprimitives,reliesonAESandSHA2.
It could be interesting to compare this variant to DHKEM.


frodokem.org frodokem.org

These domain separators have bit patterns (0x5F=01011111,0x96=10010110) that were chosen to make it hard to use individual or consecutive bit flipping attacks to turn oneinto the other
Interesting point when choosing prefixes. Sounds like this is meant to harden against fault injection.

FrodoKEM.Encaps: By the chain of highlighted variables, the shared secret seems to depend on the (complete, not only parts like seed_A or b) recipient public key.



Cryptology ePrint Archive, Report2001/108, 2001.<http://eprint.iacr.org>

SetK=KDF(Z‖PEH,KeyLen)
If not in SingleHashMode, the "context" includes the ephemeral public key. ECIES does not include the recipient's public key in the context, though.

8.1.1 Prefixfreeness propertyAdditionally, a key encapsulation mechanism must satisfy the following property. The set of allpossible ciphertext outputs of the encryption algorithm should be a subset of acandidateset ofoctet strings (that may depend on the public key), such that the candidate set is prefix free andelements of the candidate set are easy to recognize (given either the public key or the privatekey).
Is there a security implication here? Why don't we require this for HPKE? (I suspect this has been replaced by a more modern or just different definition by now) (Edited to add: might be related to the fact that the notion of AEAD seems to have appeared only later)

DEM.Encrypt(K, L, M)
Here, in contrast to the DEM used in the TagKEM paper, we have a label (additional data).


eprint.iacr.org eprint.iacr.org027.pdf3

or instance, schemes that follow the CCA KEM/DEM framework are better suitable forstreaming applications where the receiver does not need to buffer the entire ciphertex
Would HPKE be used for streaming? I'd say rather export a key from HPKE and use it externally.

Theorem 3.1[TagKEM/DEM Composition Theorem] If the TagKEM is CCA secure and theDEM is onetime secure then the Hybrid PKE scheme in Section3is CCA secure. In particular,²pke<2²tkem+²dem.
Could we reuse this theorem? Or at least replicate this proof in CryptoVerif?

Notethat, in the above syntactic definition,τis not included inψand explicitly given toTKEM.Dec
If we change DHKEM to use a context when deriving zz, does this make DHKEM a TagKEM?
