# Tag Info

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

For ordinary key exchange, leaking Alice's private key obviously allows the adversary to impersonate Alice to other people, but should not allow the adversary to (e.g.) impersonate Bob to Alice, or compromise sessions from the past. I am not familiar with identity-based key exchange, but I would expect something similar to apply. After the key has leaked, ...

2

Disclaimer: I am not familiar with Identity-Based Key Exchange, know only the most basic Identity-Based Encryption setup, and restrict to that. For other than trivialities, I refer to Ricky Demer's answer. The defining property of Identity-Based Encryption is: a user's ID and the KGC's public key is all it takes to encipher; and a user gets from a Key ...

2

There are plenty of papers on forward-secure IBE, one could just google that term. Here, I will focus on IBE with a property that I would call "key forgetting", and work toward a candidate construction for depth-O(1) HIBE with that property. One could apply either of the sections "Random Oracles, depth-O(1) adaptive-ID security, and (lack of) ...

1

All this work is done modulo the prime $p$ (which is 11 in your toy example); in this field, addition, subtraction and multiplication is done in the usual way (except you do a modulo $p$ at the end); however division is defined differently. We define $x = 6/4\ (\bmod 11)$ to be that value such that $x \times 4 = 6\ (\bmod 11)$. Now, we see that $7 \times ... 0 Bob's side seems to be "secure", because Bob generates the session-key which is encrypted with a preshared key (which obviously is not transmitted over an insecure channel). If you dismiss the possibility the easiness of a known plaintext attack the last step saves Bob side. This just saves the messages from Bob to Alice. For the rest of the communication ... 1 If a weak cipher is being used, it could be a possibility that an attacker could gather information about k(R1) and k(R2) and derive the k value. Following which, S could be decrypted with the derived k value. Eavesdropping could take place too. Similarly, a MITM would be possible too. 1 A MITM could note Rn and k(Rn) from one round of this session or a previous session, then replace Bob's k(S) with k(Rn), and continue talking with Alice using Rn as the session key. 1 Under some algorithms, if you are just encrypting (not authenticating with a MAC) S may be manipulated by the adversary and thus he would be able to see all data sent from Alice (he could impersonate Bob). 1 Obvious, but not serious weakness that numbers R1 and R2 will be sent in plain text. This means that MITM is able to modify R1 or R2 so that Alice or Bob will always be failed at authentication, although they have legal key K. I have one suggestion how you can improve this protocol. Just because in the last step of protocol, Bob send only encrypted S, MITM ... 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 ... 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.

Top 50 recent answers are included