0
$\begingroup$

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'

Improve this question
$\endgroup$
1

2 Answers 2

Reset to default
5
$\begingroup$

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)

Improve this answer
$\endgroup$
4
  • $\begingroup$ 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? $\endgroup$
    – Maarten Bodewes ♦
    Commented Dec 26, 2015 at 22:57
  • $\begingroup$ @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.) ... $\endgroup$
    – dave_thompson_085
    Commented Dec 27, 2015 at 17:24
  • $\begingroup$ ... 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. $\endgroup$
    – dave_thompson_085
    Commented Dec 27, 2015 at 17:30
  • $\begingroup$ Yeah ok, for really secure passwords it is secure. $\endgroup$
    – Maarten Bodewes ♦
    Commented Dec 27, 2015 at 19:37
2
$\begingroup$

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.

Improve this answer
$\endgroup$
4
  • $\begingroup$ 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. $\endgroup$
    – e-sushi
    Commented Dec 26, 2015 at 18:10
  • $\begingroup$ 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. $\endgroup$
    – zaph
    Commented Dec 26, 2015 at 18:48
  • $\begingroup$ Thanks… that helps me understand how you got there. (Btw,; Merry Xmas) $\endgroup$
    – e-sushi
    Commented Dec 26, 2015 at 18:50
  • $\begingroup$ 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. $\endgroup$
    – dave_thompson_085
    Commented Dec 26, 2015 at 21:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.