The comments in this question debate about the added security of multi-layered encryption. There seems to be some disagreement, and I thought a proper question would be helpful here.

So, to provide some common background, consider the following two scenarios:

  1. I apply symmetric encryption to a given file, as follows:

    gpg --symmetric --cipher-algo AES256 my_file.txt

    to which I add the password "mydogisamazing"

  2. I apply four layers of encryption to a given file, as follows:

    gpg --symmetric --cipher-algo AES256 my_file.txt
    gpg --symmetric --cipher-algo AES256 my_file.txt.gpg
    gpg --symmetric --cipher-algo AES256 my_file.txt.gpg.gpg
    gpg --symmetric --cipher-algo AES256 my_file.txt.gpg.gpg.gpg

    where the passwords supply to each are, respectively: "amazing" "is" "dog" "my" (so, when I decrypt all the layers, I have entered "my" "dog" "is" "amazing")

Is option 2 more secure than option 1? Knowing almost nothing about encryption security, it seems to me it is, because anyone wanting to break in would have to run some password algorithm four times, whereas in option 1 the algorithm needs to be run 1 time only. What if different chiper-algo were used instead of the same?

All in all, it seems also obvious to me that the answer does depend on the nature of the passwords. For instance, if I have 15 layers of encryption and each layer's password is merely one letter, it seems "trivial" to break the code.

UPDATE: in response to a comment, I stress that the example above was trying to present an apparent "equivalent" case, i.e "shorter passwords + more layers" versus "longer passwords + less layers". It seems only obvious to me (maybe wrong) that merely adding more layers of identical complexity will only increase the security of the encryption (in the mere sense of taking longer to hack the passwords). Hence my stress on the varying length of passwords.

  • 57
    If you were playing Hangman, which would be harder? Guessing the word one letter at a time, or guessing the entire word each time?
    – John Wu
    Feb 19 '19 at 17:20
  • 2
    There are 2 separate questions here: One is about encrypting multiple times, and the other is about how to generate passwords. Many of the answers picked-up exclusively on the way you put your password together. Had you used long random passwords in your examples, I think you would be getting completely different answers. I recommend editing your question to clarify which point you are trying to understand.
    – Moby Disk
    Feb 20 '19 at 14:13
  • 3
    I get the impression all the answers are focusing on the specific case where scenario 2 uses a weak password for each 'layer' and missing the bigger point of whether each layer could, at least in principle, be made more secure. For example, would anything change if we assume that a strong random/high-entropy password is used for each added 'layer', since in this case, the 'hangman' analogy cannot be relied upon? It's assumed that the attacker does not know how many layers there are.
    – code_dredd
    Feb 20 '19 at 19:54
  • 1
    I would think the fact that you have a file named ....txt.gpg.gpg.gpg would be a strong hint that the file had been encrypted 4 times. This information is now known and your 4 short passwords are going to be much faster to crack (even with brute force) than one long password.
    – FreeMan
    Feb 20 '19 at 21:32
  • 2
    @RaduMurzea Door analogies can only take you so far. Coming to a conclusion about picking a door and then transferring that to computer security is not necessarily valid. For example, if I want to get through a door quickly and I don't care about getting caught, I can just use a sledge hammer. There is no equivalent in computer security. Even when we talk about "brute force" that's the equivalent of trying every possible key until you find one that works.
    – nasch
    Feb 22 '19 at 15:57

Option 1 is more secure. In option 2, we can guess each word seperately. When we guess "amazing", we get confirmation that this word is correct and we can continue to the second word. In option 1, we have to guess all four words at the same time.

You may think that one GPG offers some security, and four GPGs offer four times that security, but it doesn't work like that. GPG offers near total security, and applying it more times does not improve security.

There are uses for applying encryption multiple times, for example when both signing and encrypting, or when encrypting for multiple parties. However, encrypting things several times does not in general makes them several times more secure.

  • 8
    In addition, even if you assumed that correct intermediate decryptions are near indistinguishable from random until you have all passwords correct (making it harder to guess partial passwords), it's still weaker due to meet-in-the-middle attacks.
    – Natanael
    Feb 19 '19 at 13:38
  • 17
    @luchonacho the reason is that you only double the security AT MOST, it is NOT exponentially increased. Every additional random character in the password does however MORE than double the difficulty to crack the password.
    – Natanael
    Feb 19 '19 at 14:59
  • 4
    @luchonacho There's a scale you're just not comprehending - 4 vs 1 sounds good, but the 4 are vastly smaller than the 1. Assuming just lowercase alphabet, there are 26^8 possible 8-letter passwords. If I have to guess 4 2-letter passwords though, 26^2^4 is the ideal case - equivalent iff intermediate steps are indistinguishable from garbage. Meet-in-the-middle attacks make it so that even this "best case" of needing to guess the same number of passwords takes less time by storing intermediate values. Wikipedia has a better explanation.
    – Delioth
    Feb 19 '19 at 15:40
  • 5
    Are there encryption schemes where you cannot confirm if a guess was correct? I imagine being able to confirm a guess was correct when deciphering AES has to do with padding.
    – Vaelus
    Feb 19 '19 at 18:43
  • 4
    @Joshua it prevents attacking the passwords individually, but the meet-in-the-middle attack remains
    – Natanael
    Feb 20 '19 at 0:48

This doesn't add security, but makes it easier to guess the passphrase one word at a time (N⁴ vs. N+N+N+N, where N is the symbol count of the word list). Even when you encrypt a file or a message to multiple recipients using PGP, the payload is encrypted only once using symmetric encryption, and then the key for that is encrypted separately for every recipient. This way every recipient has equal access to the payload without multiplying the message size.

Your suggest of using layered encryption might be useful in a few scenarios, but all the passphrases should be strong in themselves.

  • You have to send a file to someone using a symmetric encryption, but you don't have a channel for trustworthy key exchange. You could send the passphrase for one layer using email, for second layer using SMS and for third layer using mail. Any of these could be stolen, but it's way harder to steal them all.

  • You have information for a group of people you can't meet, but no-one should know it before the others. You send them all the encrypted file containing the information, but a different password to each. Now they need to be together to reveal the contents. That's a fair way to leave inheritance as a Bitcoin wallet!

  • In Onion routing i.e. the Tor network the message is wrapped inside multiple layers of encryption. Every intermediate router has a key for decrypting one layer – just like peeling an onion. A node routing the packet doesn't know how many layers there has been before and how many there is left. It doesn't even know where to forward it before decrypting its own layer. Instead of passwords, the Tor network utilizes asymmetric keys, the directory node providing public key infrastructure.

  • 15
    Worth noting: The split-key group scenario is more versatilely accomplished with Shamir's Secret Sharing.
    – Michael
    Feb 19 '19 at 15:34
  • 1
    Both scenarios can be done just as well with a single passphrase? You send 3 parts and they have to combine them?
    – Falco
    Feb 21 '19 at 14:23
  • 1
    That's true, too. Feb 21 '19 at 14:24
  • 1
    @Falco secret sharing is more resistant to bruteforce with partial known password
    – Natanael
    Feb 21 '19 at 18:11
  • 2
    @Natanael you are of course right for actual secret-sharing algorithms. Although simple layered encryption as the OP describe, or as this answer depicts are not a secret-sharing alogrithm with these properties.
    – Falco
    Feb 22 '19 at 14:25

Imagine a Hollywood film where they're cracking a password or a security code, with all the spinning digits on a fancy UI, and they have elite hackers who crack one digit of the code at a time, and the good guys have to work to blow up the hackers' computer or something before they crack that last digit. Of course, in real life it isn't like that — for a reasonably secure system, you basically either know you've got the right password, or you know you've not got the right password — there's no way to see if a password is in any way "close".

What you've suggested is making your security system work like the ones in Hollywood. An attacker would be able to run a trivial dictionary attack on your encryption, and know that they've successfully decrypted the first layer immediately. They could then simply repeat this four times to recover the file. By comparison, running a trivial dictionary attack wouldn't discover your "mydogisamazing" password, and there would be absolutely no indication when the word "my" came up in their attack that this was "close" to the final password.

  • 4
    Collecting IVs from a WEP protected wireless network is a real life situation that works similarly to these Hollywood movie scenes, though. Likewise, it has nothing to do with password strength, but looks cool on the screen. Feb 19 '19 at 16:51
  • 2
    @EsaJokinen agreed, but hence "for a reasonably secure system" - wired equivalent privacy my arse!
    – Muzer
    Feb 19 '19 at 17:43
  • 2
    It's equivalent to zero privacy. Feb 19 '19 at 17:50
  • 9
    running a trivial dictionary attack wouldn't discover your "mydogisamazing" password Well, according to haveibeenpwned.com, "mydogisamazing" appeared three times in password breaks already ...
    – Dubu
    Feb 19 '19 at 18:13
  • 2
    @Dubu Apologies, I meant in terms of running an attack against a standard English dictionary like /usr/share/dict/words. I should have made my intention clearer there. In any case, mydogisamazing is a bad password. I didn't intend that to be taken in any other way.
    – Muzer
    Feb 19 '19 at 22:48

Another perspective to what the others said (that guessing single words 4 times is much less expensive than guessing a combination of 4 words at once):

In cryptography, there is the concept of having completely open algorithms, and completely closed secrets. As long as the secret stays (sic!) secret, it does not matter whether the attacker knows anything at all about the algorithm. This is the opposite of "security by obscurity", and it is well. It means that you can put up the algorithm to the scrutiny of the whole world (quite literally, in a popular scheme like AES) without compromising anything.

The algorithm "just" needs to be uncrackable; you need to convince yourself that there is neither an algorithmic or a brute force way to crack it. If you can come to that conclusion, then you're finished, and only need to care about your secret. You and me probably cannot analyze AES to this extent, but we can decide that having it an open/public algorithm with great exposure to many presumably "good" cryptanalysts makes it safe enough for us.

So. Assume you have such an algorithm. By definition, once you have a safe password, it is 100%, perfectly safe (until someone discovers a crack in the algorithm or creates a computer fast enough - both of which does, of course happen regularly, e.g., MD5).

Anything you do with the algorithm afterwards would need very thorough inspection by a large community of cryptologists. Your proposed "repeat AES 4 times" algorithm is a completely new thing. Throw it to the community (like you did here), and people immediately find weaknesses. That's why you don't (as a layman, or as a lone programmer in some company) fool around with the algorithm, and don't ever bother with security by obscurity.

In this particular case: if applying AES 4 times would increase security, then AES would already do that. This would be such a trivial change compared to the complexity of the field.

  • 1
    "if applying AES 4 times would increase security, then AES would already do that." Not really. The security of basically every cipher would be increased somewhat if you multiplied the round count by 4, but it's generally not worth the performance tradeoff to do so. Feb 21 '19 at 4:20
  • 2
    @JosephSible: the argument is this: We cannot brute-force AES*1. Yes, if and when we have enough computing power to brute-force AES*1, then doing AES*4 (or AES^4...) would help again (if we can't think of anything better by then). So the realistic, practical security gain of AES*4 is nil.
    – AnoE
    Feb 21 '19 at 12:17
  • 1
    It isn't just about brute-force. There are plenty of attacks that can break a reduced-round version of AES, but that don't work above a certain round count. It's entirely feasible that an attack on today's full AES is discovered in the future, but that it would stop working on, say, 20-round AES. Feb 21 '19 at 14:33
  • 2
    @JosephSible But is multiple-round AES the same as just running AES multiple times? I don't know in this case, but my understanding is that such algorithms often repeat only a section of the algorithm. That might be an important distinction, and a good example of the "don't roll your own" advice in this answer: if the algorithm supports a "rounds" parameter, feel free to set it high; if it doesn't, don't invent one without proper analysis of the implications.
    – IMSoP
    Feb 22 '19 at 10:50

A minor counterpoint to the other answers: More layers is technically better than fewer if and only if each individual layer is at least as secure as the combined layer you might otherwise make from combining the passwords used for each individual layer. In your example case, you used a cipher algorithm of AES256. Fundamentally, this means no matter how complicated your password gets, you have at most 256 bits of security (never mind that 256 bits of security is effectively unbreakable without a major break in AES, we'll pretend it's breakable on some level).

Therefore, any password entropy bits beyond 256 are wasted; if the password is too complex, they can just brute force the AES key directly and skip the password based key derivation entirely. So if you've reached the maximum security that layer can benefit from, in theory, making another layer out of the remainder of the password would be "more secure".

Problems with this in practice:

  1. You (the "everyone in the world" you) are bad at coming up with passwords
  2. Even when you do come up with a decent password, it has nowhere near 256 bits of entropy (or you're going to forget it)
  3. AES256 is considered unbreakable for all practical purposes, so one layer of encryption with a sufficiently complex password is already unbreakable; a second layer is just running up the score. If someone is capable of breaking one layer, it's probably because a fundamental weakness has been identified that makes breaking two layers just as easy.

So sure, it is theoretically more secure to say, encrypt once with the password Pi}t)HawiFo_%-p)R)dxbcpsUA;pyaCQXOXc7?o? then again with the password >YPou2Lg1B8be!g#Lgfor;G;H*$xzbX74fuw_yw3, each of which has 256 bits of entropy (generated in Python with base64.b85encode(os.urandom(256 // 8))) rather than encrypting once with the combined password Pi}t)HawiFo_%-p)R)dxbcpsUA;pyaCQXOXc7?o?>YPou2Lg1B8be!g#Lgfor;G;H*$xzbX74fuw_yw3 which has 512 bits of entropy, but still only produces 256 bits of protection (since the AES256 key remains attackable directly). But since the net benefit of doing so is only additive, all you're doing is increasing the attack work from 256 bits of work for one layer to 257 bits of work for two (or 258 bits for four). You feel more secure, but in practice you're just wasting resources on the additional layers that don't really protect you.

About the only reason to even consider this is if you're sufficiently security conscious/paranoid that you don't trust AES256 or GPG alone. In that case, you might consider using those two huge passwords to create two layers, one of which uses AES256, while the other uses some other cipher algorithm or a separate encryption software. Now if there turns out to be some huge weakness in the encryption scheme used by one of the layers, the extra layer is meaningful. But if AES256 is broken, there are probably a lot more interesting things for people to decrypt, so I still wouldn't worry too much.

TL;DR: One layer with a more complex password is almost always better than multiple layers with less complex password; the rare exceptions have mostly theoretical benefits that almost never arise in practice, so just use your more complex password on a single layer.

  • 4
    Be careful with assumption that combining (independent) encryption algorithms in a cascade increases (or at least preserves) security. That depends on the security properties you are after and cannot be prüfen for all.There is a whole field of research about combining encryptions to make it more robust. blog.cryptographyengineering.com/2012/02/02/multiple-encryption but generally you are much better off starting with one conventional good choice.
    – eckes
    Feb 20 '19 at 8:30

Anyone wanting to break in would have to run some password algorithm four times, whereas in option 1 the algorithm needs to be run 1 time only.

And you seem to think that the first option would take much longer, right? Let's see.

  • Assume a password cracking utility takes 1 ms to test each single combination of characters.
  • The length of mydogisamazing is 14 characters. The total number of combinations of 14 lower-case letters is 26^14 = 64,509,974,703,297,150,976 combinations. So, 64,509,974,703,297,150,976 ms to test them all.
  • The lengths of my, dog, is and amazing are 2, 3, 2 and 7 characters respectively. The total number of combinations of 2, 3 and 7 lower-case letters are 26^2 (676), 26^3 (17,576) and 26^7 (8,031,810,176). That's 8,031,829,104 ms to try every single one of those.

So cracking all 4 shorter passwords would take about 93 DAYS, whereas cracking just the long password would take more than 2 BILLION YEARS.

I tried to keep it simple. I'm using only lower-case letters; assuming worst-case times as if the password was zzzzzzzzzzzzzz; ignoring dictionary- and rule-based attacks, parallel and GPU-based processing, and distributed tools; discarding the time it takes to test shorter combinations before longer ones, etc. In Real Life™ one-word passwords would be cracked almost instantly because they are using common words.

  • I think the math may need an adjustment. To brute force a 2 character-long password you'd probably run through single-character possibilities as well. Given your assumptions, the maximum number of attempts to crack a 2-character password would be (26^1 + 26^2) = 702.
    – el_tigro
    Feb 25 '19 at 19:29
  • 1
    @catanman I already addressed that in the footnote.
    – walen
    Mar 8 '19 at 17:14

There are (at least) two historic examples how broken this method is: In WWII, Germans developed a more secure version of the Enigma machine, with four wheels instead of three. Which should have changed the time for cracking it from a day (bad) to about a month (useless).

Unfortunately, they used the same settings for the first three wheels of the four wheel machine as for the ordinary three wheel machine. So when the three wheel machine was cracked, the cracker only needed to check 26 possible settings for the fourth wheel. No meaningful increase in security.

And the 40 bit DVD encryption scheme turned out to be composed of one 25 bit key and a 16 bit key. The 40 bit key was at the time close to impossible to crack, but the 25 and 16 bit key could each be cracked in very reasonable time.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.