0

I'm researching ways to make the most secure encryption for additional fixed drives to protect against unknown vulnerabilities, side channel attacks, etc.

Basically, securing the data beyond just a single password on ALL drives. The OS utilizes a TPM and has secondary input measures such as a PIN.

It was my hypothesis that adding another layer of safeguards, such as an encrypted container within that, would provide substantially higher security. Not only would the drive encryption need to be broken, but also a separate container.

Yes, perhaps brute-force will take "trillions" of years to break, but one vulnerability can have it broken in a minute.

Matt
  • 11
  • 1
  • 2
    Explain us what you mean by "the best encryption". The best performance? The best maintainability? The best resistance to side channel attacks? Anything else? – mentallurg Aug 17 '19 at 00:06
  • 1
    Agree with @mentallurg. Why double encrypt? Don’t see the point. If you think 128 isn’t strong enough for the threat agent and duration you are protecting against up it to 256. Some may say double encrypting gives better “security” but if you research academically there is little to no evidence to support that – ISMSDEV Aug 17 '19 at 06:30
  • VeraCrypt's use of extensive PBKDF2 password strengthening probably makes it superior. – forest Aug 17 '19 at 06:34
  • 1
    What threats do you want to counter? Full disk encryption and volume encryption protect against very different things. – schroeder Aug 17 '19 at 07:16
  • 1
    Your edit doesn't improve the question much or answer the questions in comments. "Best encryption set up" for *what*? – schroeder Aug 20 '19 at 22:48

2 Answers2

1

Conclusion:

Just use stronger encryption.

Discussion:

I don't think that a locked home with a safe in it is a good analogy for double encryption.

The security on most homes is similar to the security that rot13(*) provides: It keeps honest people honest, but a brick through a window or boot to a door provides access.

Double encrypting would be like putting a bank vault inside of another bank vault.

One thing that many people who talk about cryptography like to discuss, is how many operations it takes, on average, to decrypt something... Or more generally, how long it takes.

Safes (and locks, doors, and other physical security) are also rated for how long they can keep professional locksmiths out. I.e., your door lock can be picked in under a minute. A personal safe's lock mechanism can be drilled through, or the door itself pried off in 15 minutes. There are ways to engineer a safe to increase the time it takes, such as a layer of glass that, if it shatters, locks the bolts in place, making it far more difficult to drill through the mechanism. The walls can be reinforced and made thicker. Etc.

Rather than having a bank vault within a bank vault, people generally just increase the difficulty to access the outer vault, and make sure to secure the keys and combinations. After all, if the attacker knows how to get into one vault, the already know how (and have had recent practice) to get into the second vault.

If your outer password is compromised, then it's best to assume that both of your passwords were compromised. Either the attacker has physical access to your device, or has access to your password manager.

Having two 128-bit keys is not the same as having a single 256-bit key.

If I angered a nation-state, who decided to throw a million GPU cores at my data, where each core could attempt a trillion operations each second, my first 128-bit key will fall in an average of 1 quadrillion (1 * 10^12) years. My second key will fall about 1 quadrillion years later. Effectively, I have a 129-bit key.

However, if I have a 256-bit key, it would be expected to last 300 quindecillion (300 * 10^48) years against the same nation-state. That is several times the projected lifetime of the universe. In fact, if every star were converted into a Matrioshka Brain and put to the task of decrypting the data, then there might be a very slim chance to crack it. Bruce Schneier, of course, would be able to crack it in an afternoon with nothing but a stick of charcoal and the back of an envelope.

(*) rot13, for those who might not know, is simply shifting over your plaintext by 13 characters, in the basic English alphabet. It makes text unreadable, but it is trivial to figure out the plaintext.

Ghedipunk
  • 5,766
  • 2
  • 23
  • 34
-2

Let's say you have an encryption method A, that maps your input to B; Applying another encryption method, let's say X, that maps B to C will not help, because there must exist a function Z that maps A direct to C.

A(input) => B
then
X(B) => C

or directly:

Z(input) => C

In other words, mathematically it may be a little more secure, but not effectively secure as you may think.

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • -1 While technically correct that such a function exists, your conclusion **is incorrect**. – forest Aug 21 '19 at 06:14