I'm trying to make a simple encryption tool for Debian-like systems. I would simply hash a password, use it to lock/unlock a file, and it would never be stored on the drive. My dad threw out the idea that a randomly generated hash-like string be made and stored on the system, thereby assuming the key would be a concatenation of the string and a password hash.
Does this make sense to anybody? I don't see the point, but my father was a forensics analyst.
There are lots of sensible ways to do key derivation. Key derivation functions are a kind of hash functions, but normal cryptographic hash functions are often insufficient. Normal hash functions are designed to be fast on large inputs, whereas we want a one-way function that is very expensive even on small inputs, as to make cracking infeasible.
Your general idea is sound. Given some key derivation function H, we can compute an encryption key H(password).
If the password is strong enough, then this is perfectly fine. For example, if we want to use AES-256 as encryption, our key needs 256 bits of entropy. That is 32 bytes. But passwords are comparatively low entropy, and would need to be much longer to achieve this level of security.
So, an alternative is to derive the key from two parts: a partial key with the purpose of providing enough entropy to secure the encryption, and a human-friendly password. Both of these parts are crucial. Both must be kept secure since they could aid with cracking the key, but either part alone is not sufficient for performing decryption. You can think of the partial key as a salt for the hash function.
Of course, storing the partial key together with the encrypted file would be problematic, but this depends on the exact threat model. Example use cases for such a split key:
A password manager uses an encrypted vault. The vault may fall into the wrong hands. To open the vault on a new computer, I need a key file that I must separately transfer to that computer, and a password. Once the key file is installed, I will only need the password to subsequently unlock the vault. This strategy is widely used, e.g. by 1Password and optionally by Keepass.
A backup tool stores encrypted backups remotely on an untrusted server. I need to provide an encryption password, from which a key is derived. But to prevent weak keys from being used (for example, by reusing server credentials for encryption), the backup tools generates a cryptographically random partial key. I must store this key separately, and will need it together with my password to make and restore backups.
So, both you and your dad are having sensible ideas here. It would be useful to think about your threat model, about what data an attacker may be able to access, and about what security level is needed. In some cases, relying on a key derivation function might be sufficient. In other cases, you might want to combine the password with some random data to generate a stronger key. But unless you rely on frequent manual entry of the human-readable password part, it might be easier to just generate a strong password/key from the start.
I would simply hash a password ... My dad threw out the idea that a randomly generated hash-like string be made and stored on the system, thereby assuming the key would be a concatenation of the string and a password hash.
The difference between the approaches is roughly* to hash a password or to hash a password together with a random salt.
Hashing only the password means that an attacker could precompute the hashes for common passwords and then quickly try if the file was encrypted with a common password. Adding a random salt makes such precomputation infeasible because now lots of different hashes are generated for the same password, depending on the random salt.
Of course, making precomputation infeasible is only helpful if the computation of the hash is way more costly then doing a lookup in a precomputed table. Therefore the proper way is to both use a random salt and to have a slow function to derive the encryption key. Common password based key derivation functions do exactly this. Thus don't invent your own, use something established instead.
* The concatenation of hashed password with random string would not help. Instead the random string (salt) would need to be included in the hash to make precomputation infeasible. I'm assuming that your dad actually meant this.
Adding some contenxt on @Steffen Ullrich's answer:
Assuming that your father actually meant to use a random value like this:
encryption_key = hash(random_value + password)
then what he suggested was to use a password salt. Salts are used mainly to differentiate the output of the same password when used by different users. For example, if I were to use the password weakpassword in order to encrypt the file, and you used the same password then the encryption key used by you and me would be the same (since the same input will produce the same hash value).
However, if a different salt was appended to the passwords before they are hashed, the produced keys would differ significantly, even though the passwords are the same.
This technique is used to prevent password cracking attacks, especially based on rainbow tables.
A question you may have is, how can an attacker benefit from not using a salt when it comes to an encrypted file, because what was described above was mainly refering to password cracking for access credentials (username/password, e.g. see here). The answer depends on some other factors that play their part; the encryption mode used and whether we have any idea about the contents of the file. ECB mode with known plaintext, even partially, can make finding the password a lot easier.
For example, if a salt is not used, I know that we have partially the same contents in a file and I know the password to my file, by using ECB as an encryption mode you allow me to look for identical file blocks between our files (that correspond to the same plaintext); if I find any, it means that you're using the same password as I do.
