What is stopping someone from saving encrypted info, and decoding it later?

Question

When I send encrypted data to a website, using public key encryption, what is stopping someone who is listening from storing my encrypted data, and decryption it in a few years after they have determined the private key?

From my understanding, private keys can be discovered after a few years using a fast computer. Are there any time-sensitive safeguards used with public key encryption so that my info won't be useful in a few years?

Answer 1

What is stopping someone from saving encrypted info, and decoding it later?

Nothing. That's exactly why certain three letter institutions build large data centers... Waiting for the first large quantum computer to be built or for new attack techniques that allow to break e.g. RSA for the key sizes used today.

Are there any time-sensitive safeguards used with public key encryption so that my info won't be useful in a few years?

No, and obviously this is also not really possible if you think of something like a self-destruction mechanism. The attacker can copy the data today, store it and prevent any execution of integrated code for example.

The only things you can do to protect data from such an attack are either

• preventing adversarial access, i.e. you must not send the data on a public wire / store it on a publicly accessible device (which includes web servers, cloud services etc.pp.), or

• use information theoretically secure encryption like the one-time pad. (Remember this requires the keys to have the same length as your data AND there are only secret key schemes for this setting).

Summing up: There are solutions but they are not really practical. So far we simply failed to provide a reasonable solution for this issue.

Answer 2

First, let me address the assumption that private keys will be found in a few years using a fast computer. Unless there are serious algorithmic improvements in the cryptanalysis of a scheme, this simply is not true. Of course, the length of the key is of importance, and if you need security for the far future then you should be using 4096-bit keys (or even more), but 2048 are expected to secure for a very long time. Note that plaintexts encrypted with 3DES 20 years ago remain perfectly safe today, and our expectation is that the same will be true of AES encryptions 20, 30 and even 50 years from now (at least for AES-256). There are recommendations made by both NIST and ENISA for key lengths, factoring in how long you want security to hold for. These are all very conservative estimates, and it isn't that we really think that the algorithms can be broken in this time. So, no - unless something surprising happens, we strongly expect our encryption schemes to give security for a very long time.

Having said the above, when you talk about interacting with a web server, if forward secure protocols are used, then even if the server's RSA key is broken (or stolen), it is still necessary to break the Diffie-Hellman key exchange for each session separately. This provides good security for a very long time into the future, unless something really surprising happens (that DH can be broken very fast or likewise AES which is used to encrypt with the session-key generated by the DH key exchange).

Answer 3

Decoding information within a time frame is of absolute importance.

Say X is an terrorist, the information of his attack will be useful today, not years after the attack has happened. And similarly decoding your message is important today, not years later. Also there might be a possibility that when somebody has decoded your key for future use, you might have already changed it.

Answer 4

Seems like the correct answer to the question, as initially asked by the poster, is forward secrecy.

"Nothing" is the wrong answer.

Assuming Alice (with public key $PK_A$) and Bob (with public key $PK_B$) know each other's public keys, then they can exchange an ephemeral key $k$. The ephemeral key $k$ can be exchanged in such a fashion that its security is independent of private key compromise.

Alice and Bob can negotiate a session key as follows:

1. Alice and Bob agree on a group $G$ and a generator $g$ for $G$. For instance, $G$ can be $G \subset \mathbb{Z}_p, |G| = q$, where $p = 2q+1$, $p$ and $q$ are both prime.
2. Next, they can perform an authenticated Diffie-Hellman (DH) key exchange.
3. Alice picks a random $a \in \mathbb{Z}_q$ (DH secret)
4. Alice computes $g^a \pmod p$ (DH public key)
5. Bob picks a random $b \in \mathbb{Z}_q$ (DH secret)
6. Bob computes $g^b \pmod p$ (DH public key)
7. Alice sends Bob, $g^a$ and a signature on it $\mathsf{Sign}_{SK_A}(g^a, \text{"Alice"}, \text{"Bob"})$
8. Bob sends Alice, $g^b$ and a signature on it $\mathsf{Sign}_{SK_B}(g^b, \text{"Alice"}, \text{"Bob"})$
9. (Some additional freshness info should probably be included in the signature, to avoid reuse.)
10. Alice and Bob can compute $g^{ab}$ as $(g^a)^b$ and $(g^b)^a$ respectively.
11. Next, a key derivation function should be used on $g^{ab}$, obtaining the final key $k = \mathsf{KDF}(g^{ab})$

The signatures on the DH public keys prevent man in the middle attacks.

Compromise of the secret key $SK_A$ and/or $SK_B$ will not lead to compromise of $k$.

If Alice and Bob's keypairs should not be used to sign[1], or if deniable authentication is a goal for the key exchange, then you can look at the SKEME key-exchange protocol, which, if I recall correctly does not use signatures but maintains forward secrecy.

[1] Maybe because they are encrypt-only keypairs, as signing and encrypting with the same keypair can be disastrous.