# Tag Info

35

I've simplified the Alice random bytes to ARB and Bob random bytes to BRB. Then the protocol follows as; Alice knows $key$ and $ARB$ and sends $$C_1 = key \oplus ARB$$ Bob knows $C_1$ and $BRB$ and sends $$C_2 = C_1 \oplus BRB = key \oplus ARB \oplus BRB$$ Alice calculates $C_2 \oplus key \oplus ARB = key \oplus key \oplus ARB \oplus BRB = BRB$ Alice knows $... 14 There are two main ways to have the same symmetric key on both parties: key exchange using asymmetric crypto generate the key from a known secret (eg: a password), such as using a password-based key-derivation function The former is what you will find in TLS, where public key infrastructure is used to verify the other party's public key. The latter is used ... 14 Is this actually a viable method of key exchange? No. An eavesdropper can find the integer$b$chosen by Bob from$x$(as sent by Alice) and$b'$(as sent by Bob), and the equation$b'\,=\,b\,x\bmod 1$(meaning$\exists d\in\mathbb Z,\ b'+d=b\,x$). The shared$k$can then be determined from the$a'$sent by Alice, just as Bob does. If we take the numbers in ... 6 The responsibility of the user of Curve25519 for DHKE is Section 3; The legitimate users are assumed to generate independent uniform random secret keys. A user can, for example, generate 32 uniform random bytes, clear bits 0, 1, 2 of the first byte, clear bit 7 of the last byte, and set bit 6 of the last byte. This is a guarantee that the legitimate users ... 4 Just a quick comment on: Is the$\bmod 1$calculation as described a known one-way/symmetrical function, and is it used elsewhere? fgrieu mentions in his answer: Modular reduction modulo an integer is a common building block for one-way functions, such as (in Diffie-Hellman)$k\to g^k\bmod p$where$p$is prime,$q=(p−1)/2$is prime, and$g^q+1\bmod p=0$. ... 4 Arnaud asked me to clarify this issue. It is true that one should use an authenticated encryption mode or encrypt-then-MAC, and the paper says that explicitly. Indeed, the explanatory text in the paper following the figure shown above (Section 5.2 of https://webee.technion.ac.il/~hugo/sigma-pdf.pdf) addresses this issue. It says: We stress that the ... 4 First of all, generally, the shared secret is split in half because it consists of an X and Y coordinate. It is after all the point resulting in multiplying a public key point with a private key / vector, resulting in another point on the curve. Now the X and Y coordinate are related, so generally, only the X coordinate is used as a shared secret. Currently, ... 4 You don't transfer the key, not at least un-encrypted. There are several ways to "establish a shared key" between authenticated systems. Using key exchange schemes such as Diffie-Hellman, its elliptic-curve versions such as ECDH, X25519/X448, etc, as well as some schemes secure even if you attack it with a quantum computer such as NTRU (formerly ... 4 There is only one paper I know of which explains a post-quantum key exchange algorithm in such a way that a beginner could understand it, and that is for SIDH (Supersingular Isogeny Diffie-Hellman key exchange). The paper is called Supersingular isogeny key exchange for beginners. Abstract. This is an informal tutorial on the supersingular isogeny Diffie-... 3 If$p$and$q$are powers of two, as in Saber, then multiplying and diving by$p$and$q$amounts to simple bit shift operations. In Saber,$p = 2^{10}$and$q = 2^{13}$. Thus,$p/q = 1/2^3$and$x/8$can be computed by a right-shift of 3 bits. Using the$bits$notation,$\frac{p}{q}x = bits(x, \log(p/q), \log p)$. But we can do better, and also compute the ... 3 Yes, and Key-Encryption Keys often are symmetric. When they are, they do not bring the benefits of asymmetric cryptography; in particular, anyone with the KEK and passively eavesdropped ciphertext can decrypt the distributed keys. That does not make use of symmetric KEK pointless: KEK would typically be distributed, stored and used with more precautions (... 3 Where is the mistake in that reasoning? The problem is that would allow an attacker to test multiple passwords with the same exchange, hence losing the PAKE properties that we were trying to achieve. With dragonfly, the honest side selects a secret values$p, m$, and outputs the values$s = p+m$and$P = -m \cdot SKE$, where$SKE$is the 'secret key element'... 3 The paper you reference mentions that although both coordinates are sent, the protocol only requires the x-coordinate to be authenticated and validated. This means that the y-coordinate is free to be manipulated in implementations that do the bare minimum. As mentioned in a comment, "poor programmers and bad quality testers will not consider [this ... 3 By Multi-Prime DH, I assume you mean something analogous to Multi-Prime RSA. In Multi-Prime RSA, we pick a modulus with three (or more) prime factors; because the holder of the private key knows the factorization, he can compute (using the CRT optimization) using smaller prime modulii (and smaller exponents), yielding a moderate speed-up. Given that is what ... 3 You're right that it's not UC-secure, for exactly the reason you say. It allows offline dictionary attacks. Here's how that problem manifests in the UC model: Consider this particular environment: Environment chooses honest party's password$pw$uniformly from some known polynomial-size dictionary$\mathcal D$(without loss of generality$\mathcal{D} = \{1,...

2

AES is not irreversible, at least not when the key is known. I'd rather look at a PRF (Pseudo Random Function) rather than a PRP (Pseudo Random Permutation) such as AES. A good PRF is HMAC. HMAC also has the nice properties of having no limit to the input message and a rather large, although statically sized output. Even more specifically you might want to ...

2

but can pretend to be the client and see what the client is sending No, the eavesdropper can't see what either side is sending except the ciphertext and size of the ciphertext. To eavesdrop on any connection where the server is authenticated, the eavesdropper has to be able to convince the client that he is the server, which the eavesdropper cannot. Doesn'...

2

Am I right in thinking they should've piped the whole shared secret through the KDF to "compress" the 256 bits to 128 bits to retain 128-bit security? Using only 128 bits would not be the best practice, but does not open to attack as far as I know, for standard KDFs (which use all the entropy in their input). There's still effectively 128-bit ...

2

You're wrong. This is a difference between TLS 1.2 and 1.3. In 1.2 SignatureAndHashAlgorithm identifies only the algorithm (not curve) and hash. In 1.3 SignatureScheme does identify the curve for ECDSA, and the certificate OID for RSA-PSS. See the next to last para on page 44: [1.3] ECDSA signature schemes align with TLS 1.2's ECDSA hash/signature pairs. ...

2

The NIST post-quantum schemes mainly consist of KEMs and signature schemes due to the fact that quantum computers don't break all existing cryptography. As per Daniel Bernstein : ...there is no justification for the leap from “quantum computers destroy RSA and DSA and ECDSA” to “quantum computers destroy cryptography.” As such, there is less desire to ...

2

This is called the Socialist Millionaire Problem. A solution for it exists, as published in this paper. According to Wikipedia: It is often used as a cryptographic protocol that allows two parties to verify the identity of the remote party through the use of a shared secret, avoiding a man-in-the-middle attack without the inconvenience of manually comparing ...

2

Although it is not forward secure against client-side compromise (i.e. disclosure of the user agent's long term private key), it is forward secure against server-side compromise (i.e. disclosure of all information available to the server). Thus, for example, if ownership of the application server is transferred from one company to another and the user's ...

2

As X3DH uses elliptic curve Diffie-Hellman, I'll write things in elliptic curve notation thus if we have a curve $E$ with $q$ points and a base point $G$ we might see Alice choose a private key $a\pmod q$ and create a public key $A=aG$. It should be easy to convert to multiplicative notation if you need to. Regular Diffie-Hellman In the regular form of the ...

2

The authentication method could be a consideration. For instance, if a responder is only allowing peers to authenticate with PSK or EAP authentication, it's pretty pointless to send any CERTREQ payloads in the IKE_SA_INIT response (although, there is no real harm in it either). Similarly, is it useless to send a CERT payload when authenticating with a PSK. ...

2

Very bad things happen. Let $E' := E/〈R_A〉$ be the image curve of the isogeny $φ:E→E'$ with kernel $R_A$: $φ$ is not injective on $E[\ell_A^{e_A}]$: it maps it to a cyclic subgroup $G ⊂ E'[\ell_A^{e_A}]$; The isogeny $\hat{φ}:E' → E'/G$ is the dual isogeny of $φ$; In particular $E'/G$ is isomorphic to $E$. Thus if both $R_A$ and $R_B$ were points in \$E[\...

2

Are there any disadvantage of using it as in IKEv1? Well, there were a couple of things; the most glaring one was determining why the negotiation failed. What happened if two IKEv1 implementations tried to negotiate with different PSKs? What happened was that they derived different keys, and so it would fail - with no indication that the failure reason was ...

1

I thought device d1 can create a random number in the above mentioned range and use it as the key for Rijndael encryption of its public encryption key but without a need for padding so that all ciphertexts can be "decrypted" so that the MITM won't be able to brute force which is correct by being alerted that a wrong one is wrong. Relying on the ...

1

If you need signatures, use the signatures API. Signing key pairs may or may not be ephemeral, this depends on your use case. You'll need some way to determine that a signing keypair belongs to whoever you think it belongs to, this can't be handled by the library alone. Signing key pairs and key exchange key pairs are different data types (hydro_sign_keypair ...

1

You can assign each device its own unique certificate with a signature issued by the CA (for example, could be the manufacturer) on the certificate. So each device stores the following: its own unique certificate (its public key), its corresponding secret key, and the signature on its certificate issued by the CA. During key exchange, 2 devices would send ...

Only top voted, non community-wiki answers of a minimum length are eligible