# Password in first line of file for AES-256 encryption

I'm using openssl with aes-256-cbc encryption to encrypt a file. The password is on the first line of the file and the encryption script automatically reads the first line of the file for encryption. Is this procedure secure? OpenSSL stores the salt at the first 8 bytes of the file.

The file looks like this: 1: randomly_generated_password 2: data 3: data ...

And the command to encrypt the file is as follows:

openssl aes-256-cbc -a -salt -in data.txt -out data.txt.enc -k 'head -n 1 data.txt'

• To be exact you are using openssl enc; openssl does about 50 other things as well. And it stores the salt in the second 8 bytes; the first 8 bytes are the fixed string Salted__. @otus it's a different file; see -kfile in man enc or openssl.org/docs/manmaster/apps/enc.html and -pass file: in man openssl or openssl.org/docs/manmaster/apps/openssl.html . – dave_thompson_085 Dec 26 '15 at 21:16

Yes it's secure if:

• the password contains (i.e. is chosen using) sufficient entropy to resist attack. In practice this means it must be generated by a physical process (like rolling fair dice or flipping fair coins) or a good computer program (usually not the C library rand() function for example) not chosen by a human. Humans are very bad at choosing "randomly" and even when we think something "looks really random" it isn't; see also https://security.stackexchange.com/questions/79275/are-humans-a-strong-or-weak-rng . Note that PBKDFs are usually designed to be artificially costly and thereby 'stretch' a human-chosen password, but openssl enc uses only ONE iteration of MD5 and adds no strength; even in the 1990s this was not good practice.

• the pw file, and all stored and/or (edit) transmitted copies of it, are never available to an attacker but conversely the password data in the file is never lost (unless all the data encrypted using it is also discarded or lost so it is no longer needed)

• Funny enough the OpenSSL API documentation tells us the single iteration / non-PBKDF2, proprietary BytesToKey function is not secure if I'm not mistaken. But I don't think there is any way to force it to use PBKDF2 and a number of iterations on the command line. Can you confirm this? – Maarten - reinstate Monica Dec 26 '15 at 22:57
• @MaartenBodewes EVP_BytesToKey itself supports up to INT_MAX (usually 2^31-1) iterations, and better hashes. The manpage has long said "[usually] nonstandard ... Newer applications should use more standard algorithms such as PKCS#5 v2.0" and since 1.0.2e (a few months ago) expanded slightly to "... a more modern algorithm such as PBKDF2 as defined in PKCS#5v2.1 ..." but never "insecure". It is commandline enc that unwisely fixes niter=1. (enc can use a different hash but that offers little benefit -- and there's no metadata so you must remember it externally.) ... – dave_thompson_085 Dec 27 '15 at 17:24
• ... Commandline pkcs8 in contrast can do I'm pretty sure all PKCS#12-PBE and PBKDF2, except that niter is still fixed at 2048; a change to allow overriding that is in trunk and presumably will be in 1.1.0. But pkcs8 only does privatekeys not user data. – dave_thompson_085 Dec 27 '15 at 17:30
• Yeah ok, for really secure passwords it is secure. – Maarten - reinstate Monica Dec 27 '15 at 19:37

The salt (probably the iv) does not need to be secret and should not be the same as the encryption key. The salt (iv) is often prepended to the encrypted data, it is often random bytes the decrypted would need to know.

• Since plaintext != ciphertext and IV != key, could you please clarify how this answers the question? Besides that, the question clearly asks (quote) Is this procedure secure? while your answer does not contain a single word about the security (or insecurity) of the described scenario. – e-sushi Dec 26 '15 at 18:10
• My guess is that the first line of the file is not the password but the iv, but the question is unclear. Unfortunately I have seen several instances recently that are using the key for the iv as well. If the first text is the iv and not the password and that the iv does not have to be secret that does answer the security aspect. But the question is not clear so my answer might be worthless or worse in which case I would delete or correct it. – zaph Dec 26 '15 at 18:48
• Thanks… that helps me understand how you got there. (Btw,; Merry Xmas) – e-sushi Dec 26 '15 at 18:50
• Actually it is salt. openssl enc does Password-Based Encryption, using a supplied password plus (random) salt that is included in the encrypted file. For CBC ciphers, which use IV, it derives both the key and the IV from pw+salt. Although not good practice now, that was the original PKCS#5 standard (now retronymed PBKDF1) which was current when enc was defined. – dave_thompson_085 Dec 26 '15 at 21:19