Hot answers tagged

23

In the beginning SSL handshake, the client sends a list of supported ciphersuites (among other things). The server then picks one of the ciphersuites, based on a ranking, and tells the client which one they will be using. This step is the one that determines whether or not the future connection will have perfect forward secrecy. Note that, at this point, ...


11

Yes, you are correct. The simplest way without stepping outside NaCl would be to have both create an ephemeral, random crypto_box_keypair, then exchange public keys using their long term keys. Further communication would use that new keypair for crypto_box during that session. After they are done with the session, delete those ephemeral keys from memory. ...


11

OTR can provide forward secrecy because both partners create fresh ephemeral (one-time-use) keys, which are discarded afterwards, so they can't be recovered by later attackers. The long-term public keys are only used to authenticate them, to avoid any man-in-the-middle attack. For offline communication like e-mails this is not easily possible, since the ...


6

The Integrated Encryption Scheme offers no qualitative advantage (in term of cryptographic service offered) compared to hybrid encryption using RSA. In particular, neither provides Forward Secrecy: if the private key of the recipient leaks, past cyphertexts can be deciphered. All there is to do is apply the decryption algorithm. This contrasts with ...


5

Yes and yes and it already (almost) does. Forward secrecy is defined with regards to the notion of "long-term secret". The idea is that any secret that is stored for a long time is potentially amenable to ulterior theft. Forward secrecy is obtained when stealing long-term secrets does not allow breaking past communications, and the easiest way to achieve ...


5

Assuming you are talking TLS_PSK without DH or RSA (which are an option), if an attacker compromises the PSK and watches the nonces go past in the clear, yes the attacker can easily compute the master secret. Section 2 of RFC4279 details how the premaster secret is computed. Without DH or RSA, there is no, indeed can be no*, additional entropy added. The ...


5

Ephemerality does not refer to "a new session key being made each time a new session is set up", it refers to both parties' key pairs (and group elements) being freshly chosen. ​These Diffie-Hellman key pairs are should be ephemeral for forward secrecy; the session key is always ephemeral, even if static-static Diffie-Hellman is applied. Any nonces are used ...


4

The simplest index-calculus attack on discrete logarithms is the following. You have a generator $g$, a target $y$ and a bunch of small primes $\ell_1, \dots, \ell_k$. The computation proceeds in three phases. First generate lots of relations of the form $$g^{r_i} = \prod_j \ell_j^{s_{ij}}.$$ These relations give you a set of linear equations in $r_i$, ...


3

Yes, the example you present meets the recent definition of Perfect Forward Secrecy. However, I believe the recent definitions created in the wake of surveillance scandals fail to address one feature of forward secrecy that older definitions contained. Some older definitions included the requirement that neither party in the exchange could force the other ...


3

A possible deficiency is that if the use made of any $K_j$ allows it to leak, all later security is lost. That makes $K_j$ plain unsuitable in some uses, e.g. directly as keystream for short messages. The $K_j$ must be wide enough that it is extremely unlikely that a cycle is ever reached in deriving them. For plausible parameters that translates to ...


3

Here is a good guide for deploying forward secrecy on your SSL server. Here's another good guide that describes how to deploy forward secrecy for Apache, Nginx, and OpenSSL. To answer your specific questions: As far as I know, you should be able to use any CA. The choice of forward secrecy doesn't come from the certificate; it comes from the list of ...


3

I don't believe there is any way to achieve what you want, within your constraints. You stated as a requirement that a user must be able to get all of their data from the server, without storing anything other than their private key. If an attacker learns the private key, the attacker then knows everything that the user does, so of course the attacker can ...


2

The difference between weak and strong perfect forward secrecy lies in the capabilities of the attacker. Perfect forward secrecy is strong if it remains secure in the face of an active attacker, while weak perfect forward secrecy's security claim only covers passive attackers. If I'm not mistaken weak perfect forward secrecy (wPFS) is a term introduced to ...


2

Do you have a specific application domain in mind? I do not know of any formal definition that spans multiple application domains. A formal definition of Perfect Forward Secrecy for the domain of key exchange protocols is included in this paper: Beyond eCK: Perfect Forward Secrecy under Actor Compromise and Ephemeral-Key Reveal


2

$Adversary\:$ receives $C^1_{publ}$ $Adversary\:$ adaptively queries an oracle that implements: take $C^2$ as input, generate $S^1_{publ}$, set $\: k_{adv} = KDF\left(\left(C_2\right)^{S^0_{priv}},label_0\right) \:$, $\:$ output $\: AE_{k_{adv}}\left(S^1_{publ}\right)$ Note that $\:Adversary\:$ can (with, heuristically, overwhelming accuracy) test whether ...


2

To make key exchange protocols (providing perfect forward-secrecy) robust against quantum computers they need to rely on assumptions that are not susceptible to quantum attacks (post-quantum crypto) like hash based, lattice based or multivariate-quadratic-equations based. Clearly, quantum key distribution is a candidate for key exchange with all the ...


2

The paper Quantum Key Distribution in the Classical Authenticated Key Exchange Framework gives a key exchange protocol for which the property you describe holds. The paper On Everlasting Security in the Hybrid Bounded Storage Model is about the possibility that your described level of security holds against adversaries whose available memory is strictly ...


2

Your proposal is theoretically sound. If an attacker gets $K_5$ the only way to get previous keys would be to "rollback" the hash. If the hash function is secure, this should not be feasible. You could probably even prove it using the random oracle model, for example.


2

Properly speaking, forward secrecy is a property of a protocol. The protocol is forward secret if compromise of the long term keys does not allow an attacker to decipher any past communications. (Occasionally a distinction is made between that and perfect forward secrecy, with the latter secure when the attacker also knows e.g. all other session keys.) You ...


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

Does that meet the definition of Perfect Forward Secrecy? If you discard this freshly generated key directly after usage: yes. Perfect forward secrecy means that an attacker can't learn anything about future session if he breaks the confidentiality of a key of the current session. Applied to this scenario that means that compromise of the ephemeral RSA ...


1

Keeping a complete history of messages/keys Perfect forward secrecy is great to protect "stream kind" of messages, but that does not really fit what OpenPGP is (mostly) used for. Often, OpenPGP messages are sent and read from different machines, at different times, in different order. While OTR (offering perfect forward secrecy) does not rely on external ...


1

I've finally found a solution - some variants of key ratcheting, e.g. the one used in SCIMP, provide perfect forward secrecy assuming an initial shared secret is established without any asymmetric crypto, and they don't even require a secure random number generator on any of the endpoints! In this case all we need for an authenticated and encrypted protocol ...


1

I'm going to describe two options that you have. There may be more that I don't know about. The first is to use long-term signing keys to sign public diffie-hellman keys. Upload a bunch of those to the cloud. Then when someone wants to share a file with you, they: download your "next" signed public diffie-hellman key verify the signature using OpenPGP, ...


1

This only works if you are absolutely certain that you're properly erasing the old private keys. This is harder than it seems; you have to be sure that you're leaving no traces anywhere, including on backup media or scattered around your hard drive. With proper forward secrecy methods, the keys never leave RAM, which makes erasing them securely much, much ...


1

I generate a derived key for every document via KD=KDF∗KM∗filename where KDF and filename are known to the public. If I brute-force a document and get the correct KD, I know 3 out of 4 variables and therefore know KM. As a result, I’m able to derive every KD. The main problem here is, that you assume the existence of a function, which can calculate the ...


1

Yes, key derivation with known parameters can add to security. For a start, in the scenario of the question (understood as a real-world scenario, with PDF encryption used in step 4), when key derivation is used, you can hand one encrypted PDF document and its derived key to a person, and that won't enable her to decipher other enciphered documents; this ...


1

I have figured out a way to use TLS with only a EC key by using DSA instead of RSA. I had not realized you could do DSA with a EC key. My mistake was trying to use RSA to sign the certificate. Now I can generate my certificate and self-sign it only with the EC key. The peer will simply check to make sure the certificate was signed by the appropriate node ID ...


1

No, because Bob cannot know for sure who send the public key in the first place. So impersonation may still be an issue, even if man-in-the-middle attacks are not possible. If the communication is over a channel that can only be eavesdropped by Eve (i.e. Even cannot send anything to Bob within Bob knowing it is not from Alice), then this is secure. But ...


1

Maybe instead of trying to design your protocol you should first take a look at TLS 1.2 (http://en.wikipedia.org/wiki/Secure_Sockets_Layer), which seems to provide exactly what you need, when Diffie-Hellman is negotiated. You could easily force the client/server to use a predefined set of ciphersuites or abort. Also you could force the client/server not to ...



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