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.
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:
Questions and issues
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?
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.)
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.)
Is the method I outlined sensible, from a security standpoint?