Cfrgtkky

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.

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.

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.

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.

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.}

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.