- Nov 2022
-
www.sciencedirect.com www.sciencedirect.com
-
Slack does not have a Head of Diversity. He wants these efforts to be something “everyone is engaged in” and not “shunted off to a designated specialist,” a statement that raises the bar for all of us
Does it work for them, though? (maybe the answer is in the linked article)
-
Figure 1. What Does Implicit Bias Look Like in STEM?
Figure 1D would be easier to process as a pie chart? It is unclear what the Y axis represents.
-
- Apr 2022
-
link.springer.com link.springer.com
-
henever the encryption scheme used for the computa-tional interpretation provides indistinguishability under chosen-ciphertext attacks(IND-CCA2 security)
What about completeness?
-
hide all infor-mation about the encryption key
Does this mean they are key-committing? I suppose it does, because in this symbolic model, only the exact same key can be used for decryption.
-
-
eprint.iacr.org eprint.iacr.org
-
However, while (Q)ROM is often needed for the analysis of primitives, it is less often needed for protocols.
Good point, protocols could just use KEMs and IND-CCA for them, for example.
-
- Mar 2022
-
-
we use theCoSP framework (Backes, Hofheinz, and Unruh, CCS 2009)
Tags
Annotators
URL
-
- Nov 2021
-
eprint.iacr.org eprint.iacr.org
-
return ()
I suppose it does not reveal the secret key to keep forward secrecy?
-
nd
-
NBPES
-
Section ?? and ??
-
out(A) = out(A)
out(A) = out(B) ?
-
in(G) = ∅
G is self-sufficient so to say, it does not call into any other oracles.
-
output interface out(P)
Important to understand that this is different from CryptoVerif out processes. Actually, it kind of corresponds to CryptoVerif in processes. It is the oracles that are “exported”, “exposed”, callable from others. The input interface in() is not so much related to CryptoVerif in processes. It is the internally called oracles, it is the interface that needs to be satisfied by other oracles.
-
in(P) ∩ out(P′) = ∅
if P does not need to call an oracle provided by P'.
-
provides these package
“provides these oracles”?
-
-
eprint.iacr.org eprint.iacr.org
-
Before we prove this lemma, we explain why such a lemma is useful for proofs in the quantumrandom oracle model.
one-way-to-hiding lemma
Tags
Annotators
URL
-
- Jul 2021
-
eprint.iacr.org eprint.iacr.org
-
unencrypted acknowledg-ment to the group indicating that it has applied the update
unencrypted, but authenticated?
-
all group members converge to the same view of the groupstate as they receive the same set of control messages.
Does this include “same order of content messages”? (it should)
-
alternatively, a consensus protocol could be used
I did not know that MLS allows for that, nice.
-
WhatsApp’s group messaging protocol doesnot provide PCS [35,42].
Tags
Annotators
URL
-
- Jun 2021
-
prosecco.gforge.inria.fr prosecco.gforge.inria.fr
-
has been adapted to thecomputational model in [14]; it uses type annotations to help the proo
-
- May 2021
-
eprint.iacr.org eprint.iacr.org
-
We also show how our construction im-proves the efficiency of all existing tightly-secure AKE protocols.
-
-
eprint.iacr.org eprint.iacr.org
-
non-interactive complexity assumption
-
- Jan 2021
-
tools.ietf.org tools.ietf.org
-
Alice and Bob can then use a key-derivation function that includes K, K_A, and K_B to derive a symmetric key.
public keys included in key derivation.
-
- Dec 2020
-
-
Q_plain
Is the entropy from
Q_plain
really needed? A reason for it would be that the client provides randomness with the nonce contained inQ_plain
, in the sense of a contributive key exchange. However, the client already contributes the HPKE ephemeral key.If the Extract step should stay, I suggest changing the order of
Q_plain
andodoh_secret
. The valueodoh_secret
is of fixed size and uniformly random, and thus fits better assalt
to HKDF-Extract. If the first value is longer than a hash function block size, HMAC will do an additional hashing step: This seems easily possible for Q_plain. -
proxy and target indistinguishability
How is this defined?
-
of unique per-client keys
What kind of keys are meant here? Unique target public keys per client?
-
an
typo (mismatch with “queries”)
-
Q_encrypted
The function could receive only
ct
instead, as it does not useenc
, andsetup_query_context
already splitsQ_encrypted
. -
key_id
The function does not use this parameter.
-
context
The
context
is not returned by this function, but required as parameter todecrypt_response_body
. -
Expand(Extract("", config), "odoh key id", Nh)
config
contains kem_id, kdf_id, aead_id, and the public key. Why is entropy extraction needed here?
Tags
Annotators
URL
-
-
eprint.iacr.org eprint.iacr.org128.pdf2
-
Intuitively, in order to prove that a processQ0satisfiesa non-injective correspondenceψ⇒φ, we collect all factsthat hold at events inψand show that these facts implyφusing the equational prover.
How CryptoVerif proves non-injective correspondence properties
-
6.3. Injective CorrespondencesInjective correspondences are more difficult to checkthan non-injective ones, because they require distinguishingbetween several executions of the same event. We achievethat as follows
How CryptoVerif proves injective correspondence properties
Tags
Annotators
URL
-
-
eprint.iacr.org eprint.iacr.org069.pdf1
-
Actually, the modifications of games can beseen as “rewriting rules” of the probability distributions of the variables involved in the games. Theymay consist of a simple renaming of some variables, and thus to perfectly identical distributions. Theymay introduce unlikely differences, and then the distributions are “statistically” indistinguishable.Finally, the rewriting rule may be true under a computational assumption only: then appears thecomputational indistinguishability
Tags
Annotators
URL
-
- Sep 2020
-
eprint.iacr.org eprint.iacr.org
-
GetKey
If the original key has bytes of zeros at the end, they will be lost/stripped by this function. This is ok, because it's deterministic, and the original HMAC is filling up with zeros anyway, so it does not make a difference.
-
IsOuter
In the case of restriction to keys with length < d - 1 bytes, the predicate can be computed by looking at the least significant byte: it will be either opad or ipad.
-
opadis 0
opad = 0x5c, decimal 12 at the end, that's 1100 in binary ipad = 0x36, decimal 6 at the end, that's 110 in binary
-
ParseUasX‖Ywith|X|=d
This is exactly the pattern of calls to the hash function inside HMAC: Hash( (K' xor opad) || Hash( (K' xor ipad) || m ) ).
This clarifies that the simulator can only simulate calls to Hash that have this form, i.e. that are done from within HMAC. It cannot consistently simulate calls of a different form, i.e. that are done directly.
The consequence for a protocol that uses this theorem for its security proof is that the hash function cannot be used directly for arbitrary calls.
-
Another example is exactly the set of widestconsequence: the set of all keys of a fixed length that is less thand−1.
This works because internally, the key will be padded up to the block length. Then, there will be at least one byte where the two different paddings can be distinguished.
Tags
Annotators
URL
-
- Aug 2020
-
tools.ietf.org tools.ietf.org
-
some applications may even have a secret salt value available for use; in such a case, HKDF provides an even stronger security guarantee.
It seems to be ok to use a secret or something derived from a secret as salt.
-
-
threema.ch threema.ch
-
Experimental schemes like caching pre-generated temporary keys from the clients on the servers increase the server and protocol complexity, leading to lower reliability and more potential for mistakes that impact security.
This seems like a reference to the Signal protocol.
-
- Jul 2020
-
csrc.nist.gov csrc.nist.gov
-
4.A.2 Security Definition for Encryption/Key-Establishment
-
-
eprint.iacr.org eprint.iacr.org112.pdf1
-
and that is independent of the implementation of the encryptionscheme
-
-
eprint.iacr.org eprint.iacr.org431.pdf1
-
compressed public keypk2={bi t,(t1,t2,t3)∈(Z2e2)3,A∈Fp2,ent_bi t,r∈Z256}
Tags
Annotators
URL
-
-
-
Does a non- negligible failure rate affect the security of TLS?
-
-
eprint.iacr.org eprint.iacr.org
-
RealMOS
-
-
www.cypherpunks.ca www.cypherpunks.ca
-
6.6 Conjecture: TextSecure Iron Triangle
Tags
Annotators
URL
-
- Jun 2020
-
-
In contrast, theorems in Abstract Cryptography can be provedat a (high) level of abstraction without the instantiation ofthe lower levels. The lower levels inherit these theorems ifthey satisfy the postulated axioms of the higher level. Eachabstraction level can thus focus on specific aspects, such ascomposability or efficiency.
-
-
tools.ietf.org tools.ietf.org
-
To implement the X25519(k, u) and X448(k, u) functions (where k is the scalar and u is the u-coordinate), first decode k and u and then perform the following procedure
-
For X25519, in order to decode 32 random bytes as an integer scalar, set the three least significant bits of the first byte and the most significant bit of the last to zero, set the second most significant bit of the last byte to 1 and, finally, decode as little-endian.
-
-
eprint.iacr.org eprint.iacr.org243.pdf1
-
The necessity ofskRbeing secure for sender authentication is due to HPKEbeing vulnerable to key-compromise impersonation.
Tags
Annotators
URL
-
-
www.crypto.ethz.ch www.crypto.ethz.ch
-
his level is not required if one considersonly information-theoretic security
Why? Because for example side channels are not harmful if a system is information-theoretically secure?
-
re in some cases evenwrong in technical details, thus missing the promise ofthe bottom-up approach
… and such errors in technical details might even mean that the result is not at all relevant for the real-world system.
-
- May 2020
-
tools.ietf.org tools.ietf.org
-
As a result, the algorithm enjoys a "tight" security proof in the random oracle model.
-
-
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.
-
- Apr 2020
-
arxiv.org arxiv.org
-
Note that by definition of the corruptionqueryCi⊆Ci+1.
I think this means that no notion of “post-compromise security” is modeled.
-
-
eprint.iacr.org eprint.iacr.org401.pdf2
-
findu′≤nsuchthat defined(y[u′],u1[u′],...,um[u′])∧u1[u′] =u1∧...∧um[u′] =umthenc〈y[u′]
If the same indices are queried again, return the same y.
-
Q|Rx≈Q|R′x
When proving a “query secret k” for Q, CryptoVerif proves the indistinguishability of Q|R_x and Q|R'_x. One could imagine that CryptoVerif appends the oracle R_x to Q by parallel composition.
-
-
www.academie-medecine.fr www.academie-medecine.fr
-
Enfin, il faut que les quatre opérateurs principaux soient obligatoirement im-pliqués dans le processus de traçage.
How? By providing free internet access? For the tracing itself, I do not think help of network providers is needed.
-
pourraient alors être prévenus par sms
SMS, not push notification via the app? The app is using an internet connection anyways, to download and/or upload ephemeral IDs.
-
des applications d’intelligence artificielle (IA),
It is new to me that StopCovid uses AI.
-
-
nvlpubs.nist.gov nvlpubs.nist.gov
-
The probability that the authenticated encryption function ever will be invoked with the same IV and the same key on two (or more) distinct sets of input data shall be no greater than 2-32.
-
-
raw.githubusercontent.com raw.githubusercontent.com
-
learn
typo: learns
-
s
low priority: bytes vs byte is not consistent throughout the document
-
Thehealthauthorityneedstoknowwhoisatrisksothattheycannotifythem.
With the description of the system until now, at-risk individuals are informed by their app; no interaction with the health authority seems to be necessary for this notification. In contrast, the app needs to notify the health authority. Maybe this could be clarified?
-
PRG( PRF(SKt, “broadcast key”) )
Could this also be HKDF-Expand? Its maximum output length is 256HashLen. When used with SHA-256, this is 256256 bit and would be enough for for 512 16-byte chunks (changing every 2.8 minutes during one day).
PRG(PRF()) is fine too; the construction with “broadcast key” just reminded my of the context variable of HKDF-Expand. HKDF-Expand could reduce the needed cryptographic primitives to just a hash function.
-
ItsufficeswithaddingthetargetEphIDstothelistofobservedeventspriortouploadingittothe backend.
As a mitigation, maybe a potentially at-risk user could confirm that their app saw the infected person's EphID?
-
Inthedecentralizedsystem
Why is this only possible in the decentralized system?
-
Thesmartphonethenrelaysthisat-riskstatustothehealthauthoritysothatthehealthauthoritycancontactthephone’suser.
Ok here this becomes clearer.
-
as if it was not roaming
I found this hard to understand. Does this mean “as if it was not abroad”?
-
AfterreportingtheircurrentSKt,thesmartphoneoftheinfectedpatientpicksanewcompletely random key.
Nice, was about to ask about that. This probably only makes sense from an epidemiologic view if the app user then is sent to quarantine/confinement/has to wear a mask/etc? Well, this is the choice of the health authority, but if it's an assumption of the system it might be worth mentioning
-
beablelearn the
“be able to learn”
-
-
noiseprotocol.org noiseprotocol.org
-
HMAC is used with all hash functions instead of allowing hashes to use a more specialized function (e.g. keyed BLAKE2), because: HKDF requires the use of HMAC
This does not comment on the choice of HKDF over specialized hash function modes that are designed to be a KDF (like BLAKE3 seems to do). The comment “HMAC applies nested hashing to process each input. This "extra" hashing might mitigate the impact of hash function weakness.” applies on the level of HKDF, too.
-
SHA3 candidates such as Keccak and BLAKE were required to be suitable with HMAC
-
- Mar 2020
-
-
HKDF-Expand-Label(Secret, Label, Context, Length) = HKDF-Expand(Secret, HkdfLabel, Length)
Tags
Annotators
URL
-
-
hal.inria.fr hal.inria.fr
-
Figure 2: Simulator forH
-
4 Indifferentiability of Hash Chains
-
WireGuard excludes zero Diffie-Hellman shared secrets to avoid points of small order, while Noiserecommends not to perform this check
-
-
tools.ietf.org tools.ietf.org
-
In the case of password-based KDFs, a main goal is to slow down dictionary attacks using two ingredients: a salt value, and the intentional slowing of the key derivation computation. HKDF naturally accommodates the use of salt; however, a slowing down mechanism is not part of this specification.
-
Ideally, the salt value is a random (or pseudorandom) string of the length HashLen. Yet, even a salt value of less quality (shorter in size or with limited entropy) may still make a significant contribution to the security of the output keying material;
-
(and adding 'info' as an input to the extract step is not advisable -- see [HKDF-paper]).
-
-
eprint.iacr.org eprint.iacr.org517.pdf4
-
Definition 2.1(GenericPRF-ODHassumption)
-
The strong DH assumption (StDH) demands that the adversary solves the computational problemof computingguvfromgu,gv, but having access to a decisional oracleDDH(gu,·,·)checking for DHtuples.
-
the strong Diffie–Hellman (StDH), or the even more general Gap-Diffie–Hellman (GapDH) problem
-
While we show that even the strongest variantis achievable in the random oracle model under the strong Diffie–Hellman assumption, we provide anegative result showing that it is implausible to instantiate even the weaker variants in the standardmodel via algebraic black-box reductions to common cryptographic problems.
Tags
Annotators
URL
-
-
eprint.iacr.org eprint.iacr.org264.pdf1
-
D Some Practical Notes onHKDF
-
-
tools.ietf.org tools.ietf.org
-
This is acceptable because the standard security levels are primarily driven by much simpler, symmetric primitives where the security level naturally falls on a power of two. For asymmetric primitives, rigidly adhering to a power-of-two security level would require compromises in other parts of the design, which we reject.
-
Designers using these curves should be aware that for each public key, there are several publicly computable public keys that are equivalent to it, i.e., they produce the same shared secrets. Thus using a public key as an identifier and knowledge of a shared secret as proof of ownership (without including the public keys in the key derivation) might lead to subtle vulnerabilities.
-
Protocol designers using Diffie-Hellman over the curves defined in this document must not assume "contributory behaviour". Specially, contributory behaviour means that both parties' private keys contribute to the resulting shared key. Since curve25519 and curve448 have cofactors of 8 and 4 (respectively), an input point of small order will eliminate any contribution from the other party's private key. This situation can be detected by checking for the all- zero output, which implementations MAY do, as specified in Section 6. However, a large number of existing implementations do not do this.
-
The check for the all-zero value results from the fact that the X25519 function produces that value if it operates on an input corresponding to a point with small order, where the order divides the cofactor of the curve (see Section 7).
-
Both MAY check, without leaking extra information about the value of K, whether K is the all-zero value and abort if so (see below).
Tags
Annotators
URL
-
-
nvlpubs.nist.gov nvlpubs.nist.gov
-
n
n is the order of the subgroup and n is prime
-
an ECC key-establishment scheme requires the use of public keys that are affine elliptic-curve points chosen from a specific cyclic subgroup with prime order n
n is the order of the subgroup and n is prime
-
5.6.2.3.3ECC Full Public-Key Validation Routine
-
The recipient performs a successful full public-key validation of the received public key (see Sections 5.6.2.3.1for FFCdomain parameters andSection5.6.2.3.3for ECCdomain parameters).
-
Assurance of public-key validity –assurance that the public key of the other party (i.e., the claimed owner of the public key) has the (unique) correct representation for a non-identity element of the correct cryptographic subgroup, as determined by the
-
-
prosecco.gforge.inria.fr prosecco.gforge.inria.fr
-
outside the subgroup
-
-
nvlpubs.nist.gov nvlpubs.nist.gov
-
5.6.2.3.2ECC Full Public-Key Validation Routine
-
The recipient performs a successful full public-key validation of the received public key (see Sections 5.6.2.3.1 and 5.6.2.3.2).
-
Assurance of public-key validity – assurance that the public key of the other party (i.e., the claimed owner of the public key) has the (unique) correct representation for a non-identity element of the correct cryptographic subgroup, as determined by the domain parameters (see Sections 5.6.2.2.1 and 5.6.2.2.2). This assurance is required for both static and ephemeral public keys.
-
-
noiseprotocol.org noiseprotocol.org
-
Misusing public keys as secrets: It might be tempting to use a pattern with a pre-message public key and assume that a successful handshake implies the other party's knowledge of the public key. Unfortunately, this is not the case, since setting public keys to invalid values might cause predictable DH output. For example, a Noise_NK_25519 initiator might send an invalid ephemeral public key to cause a known DH output of all zeros, despite not knowing the responder's static public key. If the parties want to authenticate with a shared secret, it should be used as a PSK.
-
Channel binding: Depending on the DH functions, it might be possible for a malicious party to engage in multiple sessions that derive the same shared secret key by setting public keys to invalid values that cause predictable DH output (as in the previous bullet). It might also be possible to set public keys to equivalent values that cause the same DH output for different inputs. This is why a higher-level protocol should use the handshake hash (h) for a unique channel binding, instead of ck, as explained in Section 11.2.
-
The public_key either encodes some value which is a generator in a large prime-order group (which value may have multiple equivalent encodings), or is an invalid value. Implementations must handle invalid public keys either by returning some output which is purely a function of the public key and does not depend on the private key, or by signaling an error to the caller. The DH function may define more specific rules for handling invalid values.
Tags
Annotators
URL
-
-
moderncrypto.org moderncrypto.org
-
This check strikes a delicate balance: It checks Y sufficiently to prevent forgery of a (Y, Y^x) pair without knowledge of X, but the rejected values for X are unlikely to be hit by an attacker flipping ciphertext bits in the least-significant portion of X. Stricter checking could easily *WEAKEN* security, e.g. the NIST-mandated subgroup check would provide an oracle on whether a tampered X was square or nonsquare.
-
The client is relying on the server's unauthenticated DH public key Y to somehow authenticate the server's knowledge of X. Obviously, this is making an assumption about a DH that could be bad, thus is an unsafe protocol. This is Tor's (older) TAP circuit handshake (using regular DH, not ECDH). The original deployment was easily attacked by a fake server sending a public key Y = 0, 1, or -1, thus allowing the fake server to calculate Y^x without seeing X [TAP].
-
Thus it's an incomplete fix, and the correct solution is binding the transcript.
-
It's well-understood 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 non-DH key agreements (e.g. post-quantum algorithms, and encryption like RSA).
-
X25519 is very close to this ideal, with the exception that public keys have easily-computed 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 all-zero 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 all-zero shared secrets—essentially, the first message will be in the clear for an eavesdropper.
-
arguing that a zero check “adds complexity (const-time code, error-handling, and implementation variance), and is not needed in good protocols.”
-
-
eprint.iacr.org eprint.iacr.org
-
Figure 7: One-phase experiment
I use this security notion for DHKEM
-
We then considerthe same question for key-encapsulation 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(m||H(pk)) construction as in Kyber.
Tags
Annotators
URL
-
-
pq-crystals.org pq-crystals.org
-
Asimilarstatementholdsforadditionallyhashingtheciphertextintothenalkey.Severalproto colsneedtoensurethatthekeydep endsonthecompleteviewofexchangedproto colmessages.Thisisthecase,forexample,fortheauthenticated-key-exchangeproto 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,andPRFallwithSHAKE-256.WedecidedtochangethistodierentfunctionsfromtheFIPS-202familytoavoidanydomain-separationdiscussion.
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? SHA-2 is vulnerable to length extension attacks!
-
weinstantiateKDFwithSHAKE-256
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,reliesonAESandSHA-2.
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 Prefix-freeness 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 Tag-KEM 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[Tag-KEM/DEM Composition Theorem] If the Tag-KEM is CCA secure and theDEM is one-time 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 Tag-KEM?
-