Tag Info

Hot answers tagged

20

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, ...


6

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 ...


5

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. ...


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

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

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

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

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 ...


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

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 ...


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 ...


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 ...



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