# Tag Info

34

This doesn't add new security as much as it just shifts it. Encryption algorithms are carefully studied. Hmm... I didn't make that emphatic enough. Encryption algorithms are C A R E F U L L Y studied. There. That's better. There are all sorts of tiny nuances to be had when designing an algorithm. A famous example were some of the S-Boxes in DES which ...

26

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

22

Forward secrecy is a confusing term that should be abandoned, especially the meaningless but value-loaded variant ‘perfect forward secrecy’. It is especially confusing because it is often associated with any protocol that does ephemeral DH key agreement, like TLS—even if, as in TLS<1.3 session resumption, the keys capable of decrypting transcripts of ...

20

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

19

Suppose you have two cryptosystems $A$ and $B$ with $n$-bit keys. Maybe they're both secure at what they aim to do; maybe they aren't. Say they both take about the same cost to implement. You are proposing using an $(n + 1)$-bit key, where the extra bit selects between $A$ or $B$. You have now doubled the cost to implement your system. Does this add any ...

13

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

10

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

10

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

8

Since I am at the source of the original quote, I might as well respond... Technically, forward secrecy is overhyped because it is recommended almost everywhere. In some contexts it makes sense and is a valuable property. In many other contexts it makes less sense and, while harmless from a security point of view, it may induce performance-related issues. ...

7

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 $n^2<... 7 Suppose that one of your cipher suites has some weaknesses. Then the adversary can play with your network to force you to select the weak cipher to exploit the weakness. This is highly done in TLS. Therefore your system can turn into a single case during an attack. Also, the attacker can store all off your communication. If somehow they can break one of ... 6 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 ... 6 The "advantage" of static DH is that the server doesn't need to compute an exponentiation each time. This advantage is, however, not worth it, in the sense that the static DH problem is easier than the DLOG problem (to the best of our knowledge). In the paper The Static Diffie-Hellman Problem (PS) by Brown and Gallant, they show an attack on the static DH ... 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 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$,$s_{...

5

In cryptography, forward secrecy = perfect forward secrecy, backward secrecy = future secrecy. First, recall some background. The above terms are often discussed in the setting of secure channel establishment protocols, e.g., TLS, Signal, etc. In such a protocol, consider two parties, a client and a server, try to communicate with each other securely. The ...

5

What does 'forward secrecy' mean in the context of hash based signatures? Well, what that term means is that we have a hash based signature scheme with an evolving key, that is, the private key is constantly being updated, and on a state compromise (at state $N$), you cannot get the private keys used prior to state $N$. I personally don't see that as a ...

4

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

4

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

Forward secrecy: When a node (user) leaves the network, it must not read any future messages after its departure. Backward secrecy: When a new node (user) joins in the network, it must not read any previously transmitted message. Crytographics properties Perfect Forward Secrecy : Perfect forward secrecy means that a piece of an encryption system ...

4

Is it possible to achieve perfect secrecy, unbreakable, unguessable, uncrackable by using a totally secret cypher? There are two different questions: Can you obtain perfect secrecy, and can you obtain an encryption algorithm that cannot be broken. Perfect Secrecy The One Time Pad is already a well known construction; Supposing that any construction that ...

4

Actually, for any group operator $\odot$, we see that $x \odot y$ gives perfect security, assuming that $y$ is uniformly random over all possible group members. The $\equiv$ operation is a group operation, with the group members being $\{0, 1\}$, with $1$ being the identity. Hence, yes, it gives perfect security.

4

Can we do better? Yes. See: On Ends-to-Ends Encryption: Asynchronous Group Messaging with Strong Security Guarantees. To support significantly larger groups? Our results demonstrate that ART is practical for reasonably-sized groups, with key tree setup and message sending both taking a few milliseconds for groups of size ten and on the order of one ...

4

So why would we still want to use standard DH? Are there any benefits to this? The party / parties with the static key can just pre-compute their public DH key and thus save one scalar multiplication / exponentiation per key exchange. If a static DH key is used, it can be used for identification, eg if you do an ephemeral agreement with a static key and ...

4

How often should I replace the key? The SUPERCOP implementation replaces the 32-byte key every 768 bytes. It's a latency/throughput tradeoff. Generating a longer batch of output raises the maximum latency of any query to the PRNG but also increases the throughput by using proportionally more CPU cycles for generating data and fewer for generating ...

4

Some limitations of the proposed protocol: It only applies when both parties have a private key, not in the common browser-connects-to-server scenario. As noted by others, it is not true Forward Secrecy, for it does not protect from leak of both private keys. Authentication of parties is not provided before knowledge of $K_{ep}$ is demonstrated, in a step ...

3

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

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

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

3

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

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