Hot answers tagged

13

The first part of this partial self-answer uses additional information I received from Professor Simon R. Blackburn, one of the author of the recent attack. The method used to generate parameters is not public, e.g. for the matrix $m\in GL(n,\mathbb F)$ which careful choice was acknowledged critical to defeat an earlier version of the attack. The authors of ...


11

I recommend avoiding Diffie-Hellman parameter generation. Instead, use a standardized DH group with a sufficiently large modulus (2048-bit or larger). For example, group #14 or #15 from RFC3526 (see sections 3 and 4) would be a good choice. Alternatively, switch to the elliptic curve variant of Diffie-Hellman and use Curve25519. The article you linked to ...


8

You're describing a form of three-pass protocol, which is a communication mechanism where neither party needs to know each other's secret key. Wikipedia describes a helpful metaphor using a box that can be locked by two padlocks: First, Alice puts the secret message in a box, and locks the box using a padlock to which only she has a key. She then sends ...


8

Using lattices/ring-LWE, there is Lattice Cryptography for the Internet (by me), which inherits from Ring-LWE encryption, and has been implemented by Bos et al. with further improvements by Alkim et al. The underlying mechanism is conceptually DH-like, but uses completely different mathematics. We start with a uniformly random $a \in R_q = R/qR$, which can ...


6

Yes, there are a few reasons to prefer ECDH over RSA: ECDH will perform much better; ECDH can provide forward security when used with ephemeral key pairs without a large performance overhead for creating those key pairs; ECDH should be impervious to most oracle attacks, i.e. timing based padding oracle attacks on OAEP. For the forward secrecy you require ...


5

Alice also needs to first decrypt the symmetric key and then decrypt the message. It almost seems like a double work. Encrypting a short plaintext (i.e. the symmetric key) requires only one asymmetric (e.g. RSA) operation, while encrypting a longer message would in theory require many RSA operations. Suppose we want to encrypt a 1 MiB message. Using ...


5

The SNI extension is plain text in the ClientHello. This means that it is possible to passively snoop the value and redirect the traffic. This is already used in practice, i.e. haproxy has this feature for several years.


4

So is 2 the private key here ? No, it's referred to as a "shared secret" (because it is shared between Alice and Bob, and is secret to everyone else). If there were 'private' and 'public' keys (which is not the standard terminology with DH), then Alice's private key would be $a=6$, and the public key would be $g^a = 8$. In this case, the 'private key' ...


4

This is exactly where automatic protocol analysis tools can help you. For example, using the Scyther tool, the protocol description using symmetric encryption is: /* * Protocol description for Scyther * * Note we use 'K' to model 'k' since Scyther assumes 'k(.,.)' refers * to pre-shared keys between two agents. */ // The protocol description with ...


4

Some background on formal key-exchange models The goal of a key-exchange (KE) is to establish a session key between two parties. Naively, we could say that a KE is secure if no adversary will be able to figure out the session key (in full) established between two honest parties. However, in formal security models we take this a bit further and insist that ...


4

First up: it does use public keys in contrast to your claims. To be more specific – $q$ is Alice’s public key, and $f$ is Bob‘s public key. Both are transferred in public and might be intercepted by a MITM. This brings me to the next point: the system you worked out in your head is highly insecure. We'll call the message $p$ and encode it as a number. ...


4

Export ciphers date back to the time when cryptography export was regulated by governments, most notably the US government (see this answer for a good overview of the history of export restrictions). Back then, exporting cryptography with more than 56 bit strength was forbidden. For the Diffie-Hellman Key Agreement scheme, 56 bit of security meant that they ...


4

Yes, RSA encryption without padding as used by RSASVE in NIST SP800-56B is secure. The RSASVE Generate Operation in NIST SP800-56B §7.2.1.2 is given on input an RSA public key $(n,e)$; generates a random secret bitstring $Z$ uniformly distributed on range $[2,n-2]$; computes $C=Z^e\bmod n$ (as in textbook RSA encryption); outputs the secret $Z$ and the ...


4

Ed25519 is well-defined and requires you to use SHA-512 as internal hash function along with the twisted Edwards version of Curve25519, hence there's no need for a KAC when it comes to questions about the parameters. As for the integrity of the public key, there's not yet a standard for Ed25519 based certificates so there would be a custom solution needed ...


3

I think I found an answer in this thread: http://www.gossamer-threads.com/lists/gnupg/users/65236 In short: There is a packet which looks like a key revocation but it could be forged. If an OpenPGP application downloads the key from the server then it does a signature check.


3

RFC 2945 By Tom Wu the SRP inventor uses x = H(s, H(I, ":", p)) where I is the username demonstrating that can do anything you like to the stretch the password such as prefixing the username then hashing it. So stretching the user entered password before putting it into function using PBKDF2 would increase the time taken for a dictionary attack with no ...


3

That doesn't hide Bob's identity from eavesdroppers. (The OP mentioned in chat that the OP isn't trying to do that.) I can no longer spot any other problems with the key exchange part. The encryption/decryption of application level data is vulnerable to arbitrary replays and reflection and dropping. ​ The public MAC input should indicate direction and ...


3

In addition to the other answer. The "Steps of Hybrid Encryption" in the question really are steps of one form of hybrid encryption, built on top of asymmetric encryption. There are other forms of hybrid encryption (at least for the meaning of that in protocols), including some resistant to passive eavesdropping (attacks where the adversary can't send or ...


3

Douglas Stebila published: We demonstrate the practicality of post-quantum key exchange by constructing ciphersuites for the Transport Layer Security (TLS) protocol that provide key exchange based on the ring learning with errors (R-LWE) problem There is also a patch implementing it for OpenSSL 1.0.1f.


3

Sounds like a description of ECIES to me. ECIES is a hybrid cryptosystem that builds upon ECDH. Basically: the static public key of the receiver is used together with an ephemeral key pair generated at the sender. The public key of the receiver and ephemeral private key of the sender are used to generate a "shared secret" using ECDH. This shared secret is ...


3

I have never heard of this reason, and I don't quite understand it. In general, the security of Diffie-Hellman key exchange is reduced to the DDH assumption. According to this assumption, the result of the key exchange is a group element that is computationally indistinguishable from a random/uniformly distributed element in the group. However, what is ...


3

Yes, if you are using 3rd party key exchange, the 3rd party can read the messages. If that is not the security feature you want, use something else. There are many legitimate scenarios where users are fine with trusting the third party, however. For example, a system setup by my employer to allow encrypted chat between myself and our clients. My employer has ...


3

Any shared secret can be used. Securely distributed passwords and symmetric keys, for example. Alternatively, you can use asymmetric cryptography, such as public keys. For one example, SSH has for years authenticated servers using public key cryptography and users typically using either public keys or passwords. Only recently had SSH added support for ...


3

One requirement that you don't have listed is that the generator $g$ needs to generate a subgroup that's of a large prime order; here's what can go wrong if that is not true: If the order of $g$ (which we call $q$) has a factor $r$, then the attacker can, hearing $g^x$, determine $x \bmod r$ in $O(\sqrt{r})$ time. If $r$ isn't large, this immediately ...


2

$s$ is a shared secret key. It's known to both Alice and Bob. You could call is a private key, but the usual terminology is “secret key” here, for no deep reason. Alice has a private/public key pair: $a$ is her private key, $A$ is her public key. Ditto with $b$ and $B$ for Bob. These values are not useful in isolation though; in normal use, the only point ...


2

I think you're confusing some things here. The usual TLS-handshake with ECDHE (which you really should use, unless you have very good reasons) has two public keys. One of them is signed by the CA, the other one is generated on-the-fly. And before proceeding, please note: (Perfect) Forward secrecy (PFS, not security usually) only means that you don't ...


2

The protocol seems secure. Some comments below. Bob computes the DH shared secret X using his private key and Alice's static public key, and then K(X), the result of applying an appropriate key derivation function (KDF) to the combination of A, B, and X. The DH secret X already depends on both key-pairs. Including the public keys in key ...


2

That's a bit of a strange question. ECDH is a key agreement protool. ECC does not have a direct form of encryption as RSA has. ECIES is basically ECDH used to derive a symmetric key, which is then used to encrypt the plaintext. You can see it as a delayed form of key agreement. So your question is if ECIES can be used to encrypt session keys. That would ...


2

This is a very difficult question. But first the standard information: Don't roll your own crypto if anyhow possible. (which isn't the case here) No protocol should be considered secure until formally proven secure. (TLSv1.2 is) That being said I can still provide "ad-hoc" security argumentations why it's likely that your handshake is (in)secure.I can't ...


2

How they work Public and private keys work as follows. Every party who wants to communicate with others generates a private key which they keep secret. From that private key, they derive a public key, which they publish for anyone to see. For example, if we have three agents, Alice, Bob, and Charlie, they will all have a secret key S_A, S_B, and S_C and a ...



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