Is this cumbersome strategy to produce a ridiculously strong password valid?

Question

I'm writing something where somebody wants to have a ridiculously strong password for a file and yet be sure that he will always be able to reconstruct it. The way I have thought of this might be a little cumbersome, but as long as it works and makes sense, I'm happy with it. First I'll explain how my character derives his password, and then the issues I'm having.

Password derivation

My character will start from a sentence describing something only he knows. Then he will transform it so that it wouldn't look like a sentence to anybody (remove spaces, replace letters with numbers or symbols at random places, replace syllables with similar-sounding ones, random capitalisation, etc.) leading to what we'll call the base password.

Not happy with this level of security, he wants to generate a much higher-entropy password by running the base password through an encryption algorithm a certain number of times. There are very subtle hints that will remind him what algorithm and key he needs to use, and how many times the base password needs to be run through it. The final result is the file password. (He doesn't need to open the file often so it's alright to have to go through the hassle when he does need to open it.)

I did a test using Twofish and running a base password through it a few times. I got this stuff:

rvXRimTU7jhLxCZCe+9hCafIj/5nwZ4eK4pDJOxi5+8yulVzG6h61bZBIK5E2fCcHiG65HaoybnhH9/2l2VnGjWiqH44Snr9iSGInq0vwApJUAalYMJRDwXNQh2yOr6yRtqA+CtWZrbCu86IGjLy6NB5C75ko3khsz342JW94Uj7GrZDZWKee3M2KB3O76QbXtVB8EiBhuvoHeeEOvskeJdw5qAfPw42j4aQdAdcfc6Qo1cHIh20piWy8xrnvywViXM1tpEFBezbPXHBFjCUp1vFJAFf/vDl9SMA7pD7B190jZxQHpltAJeQXJxwAoM64fvxGTNx/Cieo4s+WHnCTA==

Questions and issues

1. To me, the resulting file password looks high-entropy enough. Unless an attacker can guess the original sentence, how it was turned into the base password, and gets the hint revealing the algorithm used to scramble it, I doubt anyone could brute-force that file. Yes, they could hit the character with a wrench until he reveals how to get the file password and stuff like that, but we don't care about that. We only care whether the file password is high-entropy or not. Do you guys agree that it's high-entropy?

2. I used an online tool to do my test, and that's when I was reminded that encryption algorithms often use "salts" to make the result different each time even though you encrypt the same data with the same key. Clearly, this is a problem, because if salt is used then our character will never get the same password again. Is salt the only factor that adds randomness in Twofish, or is there other stuff I need to take into account? (I can simply assume he is using an implementation that excludes all randomness and always generates the same file password from the same base password, provided the correct key is used and the algorithm is iterated the correct number of times.)

3. I was rather disappointed to see that different online tools for text encryption are utterly incapable of correctly decrypting each other's output even with the same settings and the correct key. The result is invariably gibberish. This is going to be an extremely dumb question, but I guess this depends on the implementation, and that if we had two professional tools implementing Twofish, they should be able to decrypt each other's output given the correct key and the same settings? (If this wasn't the case, other people in the story would never be able to access the encrypted file.)

4. Is the method I outlined sensible, from a security standpoint?

Answer 1

This is a broadly sub-optimal strategy because it violates Kerckhoffs's principle: if the attacker knows as much about the steps you're describing as you do, and only lacks the core secret, then most of these steps become useless for increasing the security of the secret.

Put another way: the steps that you're describing aren't actually increasing the entropy by any significant amount.

It sounds like this use case depends on the "survival" of the secret holder - to be alive and conscious enough to be able to always produce the secret from memory? If so, the optimal strategy is probably:

• maximizing the "memorizable" entropy of the input - a randomly generated passphrase, memorized, in the style of XKCD 936, using a mnemonic narrative constructed around it after the fact to aid recall - but with more entropy (five or six words drawn from a dictionary of 20,000 words or more), in order to be bruteforce-resistant even if stored with a weak/fast hash

• maximizing the cracking resistance of the output - a true KDF like high-work-factor bcrypt or well-tuned scrypt (which are well-covered elsewhere). These are better because they are cracking-resistant even when their algorithms are public knowledge.

But really, since you often don't have control over how the input is stored (hashes), it's the first step that really matters - because even a weak hash will protect a strong password.

And if you're constrained to using the KDF that's built into the file storage format, the second step wouldn't apply at all - because you wouldn't have access to the salt because it would be hidden inside the document's hash. So you'd have to store it somewhere, which would be fragile.

So for your use case, it's probably best to let the secret (as a random passphrase) do the work.