What can one do when encryption methods fail?

Question

I'm in search of an expert to answer my curiosity. Suppose that methods like AES/DES, SSH, PGP, RSA, etc. can be cracked or fail somehow. In other words, suppose that it's possible to determine one key for a given security method. I mean to say, that somehow a hacker has enough power to compute a key.

Are there any methods of security that can effectively deal with compromised keys? I'm attempting to consider a model where a potential hacker/hijacker has considerable computational power at their disposal. What can be done to prevent a security breach, if anything? Are there methods available that deal with this?

Answer 1

The model you are using can be described as: "the attacker loans God's own computer". His computing abilities are infinite.

Most of cryptography falls down in the face of such a foe. However, there are a select few algorithms which still have some strength in that situation; the branch of cryptography which deals with that is called information theoretic security. A classic example is One-Time Pad, which is a symmetric encryption system where the key is as long as the message, and used only once (hence "one-time"): security relies on the idea that even if the attacker can try all possible keys, he has no way to know whether he found the right one or not. A more usable information-theoretic algorithm is Shamir's secret sharing scheme.

Practical usefulness of such algorithms is, to say the least, questionable: an attacker who has unlimited power would also prove wrong two centuries of mathematicians, physicists and other scientists, including the foundation of every technological advance since the steam engine. At that point, you should have more pressing worries than what could happen to your keys. Also, why an entity with such god-like power would even bother attacking your system ?

Answer 2

The most important thing to know is that, if you use modern cryptographic algorithms appropriately, the crypto algorithm is very unlikely to be the weakest link in your system. It's almost certain that other attacks (e.g., social engineering, attacking the human, malware, implementation vulnerabilities) will be easier than breaking the crypto.

Therefore, from an engineering perspective, it's very likely that your energy and effort is better spent defending against those other threats, which are much more likely to occur. Unless you've already put an awful lot of attention into securing the other parts of your system (in which case you probably wouldn't need to ask this question here), I wouldn't waste your time worrying too much about what happens if the crypto gets broken.

Answer 3

I'm a little confused as to what you're asking. Encryption fails all the time; an overwhelming percentage of the time because of side channels, and often also because of flawed implementations. Once in every long while, an algorithm like the original 56-bit DES becomes either broken or surpassed by Moore's Law.

At that point, anything protected using only that algorithm is no longer adequately protected--but that doesn't mean there's nothing you can do; that just means that there's nothing as general as an encryption algorithm that you can do.

If you're a government, and you've been using DES to encrypt your telephone calls and network traffic, you commission a new algorithm, stop using the old encryption devices, and buy a set of new ones. If you've been using DES for data-at-rest encryption, you migrate your data to new storage devices or volumes with stronger encryption. If you used DES to protect parts of a software authentication mechanism, you rewrite the software with newer algorithms.

If you put your most sensitive files out on public FTP sites, trusting in DES to keep them safe, well, you're screwed.

Ify you're asking what you can do when designing a system to protect against the possibility that the encryption algorithm you're using becomes broken, you're asking the wrong question for all practical purposes; the encryption algorithm is by far the strongest part of your system. It's not the standardized adamantium door you need to worry about, it's the wood doorframe you built around it and the bespoke brickwork in the walls.

If you still want to know what you can do, purely for theoretical purposes, the differing environments and uses for encryption are where you'd need to start; but there's always other things you can do--strong authentication and access control, steganography, etc.

Answer 4

Alright, I don't believe anyone hit on this yet, but encryption is one layer of the security onion.

There are may other layers, pertaining to network/host-side scanning, behavioral analysis, etc...

Another point worth mentioning is the idea of two-factor authentication. Using methods as image recognition, biometrics, RSA keys (or, with their current situation, another company like nTrust).

If you are housing this data yourself and you have not looked much into other security perspectives other than encryption, look into IDS/IPS systems and SIM/SEM systems.

Physical security must also be taken into account.

The real question here is where this encryption is... Will this be encrypted company data that can sit behind 3 layers of firewalls within a data-center that has 3-factor authentication, is it being shipped around on thumb-drives, or is it just sitting on an open FTP server that a college kid has running under his desk?

Additionally, as I understand it, all the major encryption algorithms have been approved by the US government (as they stand now) and therefore I would just take it for granted that, at least at the governmental level, encryption is not an obstacle. It's been a while since I've studied the history/legislation surrounding encryption schemes, so please correct me if I'm wrong.

P.S. this questions has such a wide breath of possible answers.... covering almost every aspect of security. It may be beneficial to add some clarity to your question, that is unless you've already been given an acceptable answer.

Answer 5

Are there any methods of security that can effectively deal with compromised keys?

To some extent, yes. For example there are confidentiality schemes which are designed to offer perfect forward secrecy even in the face of compromise of (some of) the involved keys.

When engineering a system using crypto it is also a good idea to make your algorithms pluggable so that you can at least replace an obsoleted / compromised algorithm without having to re-engineer everything. In other words, don't hardwire the algorithm into your system/protocol (just as you generally shouldn't hardwire a key into it).