-1
$\begingroup$

I am looking for a way to securely encrypt files on Mac and Debian. OpenSSL comes pre-installed on Mac OSX and Debian/Ubuntu. Therefore, is this a safe/recommended way of encrypting individual files? (or gzipped folders?)

openssl aes-256-cbc -a -e -salt -in "foo" -out "foo.aes"

and then decrypting them later:

openssl aes-256-cbc -a -d -salt -in "foo.aes" -out "foo"

Update: OSX doesn't seem to support GCM.

openssl:Error: 'aes-256-gcm' is an invalid command.

Standard commands
asn1parse      ca             ciphers        crl            crl2pkcs7      
dgst           dh             dhparam        dsa            dsaparam       
ec             ecparam        enc            engine         errstr         
gendh          gendsa         genrsa         nseq           ocsp           
passwd         pkcs12         pkcs7          pkcs8          prime          
rand           req            rsa            rsautl         s_client       
s_server       s_time         sess_id        smime          speed          
spkac          verify         version        x509           

Message Digest commands (see the `dgst' command for more details)
md2            md4            md5            mdc2           rmd160         
sha            sha1           

Cipher commands (see the `enc' command for more details)
aes-128-cbc    aes-128-ecb    aes-192-cbc    aes-192-ecb    aes-256-cbc    
aes-256-ecb    base64         bf             bf-cbc         bf-cfb         
bf-ecb         bf-ofb         cast           cast-cbc       cast5-cbc      
cast5-cfb      cast5-ecb      cast5-ofb      des            des-cbc        
des-cfb        des-ecb        des-ede        des-ede-cbc    des-ede-cfb    
des-ede-ofb    des-ede3       des-ede3-cbc   des-ede3-cfb   des-ede3-ofb   
des-ofb        des3           desx           rc2            rc2-40-cbc     
rc2-64-cbc     rc2-cbc        rc2-cfb        rc2-ecb        rc2-ofb        
rc4            rc4-40         rc5            rc5-cbc        rc5-cfb        
rc5-ecb        rc5-ofb        seed           seed-cbc       seed-cfb       
seed-ecb       seed-ofb
Improve this question
$\endgroup$
8
  • $\begingroup$ Found a related question on superuser $\endgroup$
    – Xeoncross
    Commented Jan 21, 2015 at 20:50
  • $\begingroup$ If detection of tampering is important to you, use GCM mode instead of CBC. Also, 256-bit AES will be somewhat slower, and is likely overkill for your scenario. Also, if you keep the key on the same media as the encrypted file, you aren't actually gaining much (if anything). For OSX, you may want to look into encrypted sparseimages which can be made with Disk Utility, but aren't accessible cross-platform. $\endgroup$
    – Stephen Touset
    Commented Jan 21, 2015 at 23:27
  • $\begingroup$ @StephenTouset when you say "key" I'm assuming you mean the symmetric password used and not a keypair right? I learned about CBC > EBC a while ago. I haven't heard about GCM yet. Also, I'm not worried about 256-bit AES being overkill since this is for sensitive small text documents, configs, or keys mostly. I just need something for daily use on OSX and Linux. $\endgroup$
    – Xeoncross
    Commented Jan 22, 2015 at 4:03
  • $\begingroup$ Symmetric encryption algorithms do not work on passwords; they work on keys, which are expected to be random bytes (256 bits worth in the case of AES-256). In the optimal case, you simply store this random key separate from the data it's encrypting. If you want a "password" to protect the data, the two typical approaches are 1) to use a KDF like PBKDF2 to "stretch" the password to increase its effective entropy and distribute its entropy evenly across the number of bits expected by the algorithm, or 2) to use the password (and a KDF) to encrypt an actually random key, a la the first approach. $\endgroup$
    – Stephen Touset
    Commented Jan 22, 2015 at 22:13
  • $\begingroup$ Why not use PGP? $\endgroup$
    – mikeazo
    Commented Jan 26, 2015 at 15:29

4 Answers 4

Reset to default
2
$\begingroup$

Why not using VeraCrypt http://en.wikipedia.org/wiki/VeraCrypt, which is a successor of the famous discontinuited TrueCrypt. VeraCrypt is open source, and was developped by M. Idrassi an crypto-expert, take a look at https://github.com/veracrypt/VeraCrypt . There was controversy about the TrueCrypt, mysterious stoping. VeraCrypt corrected some know flaws and enhance security with respect all the standards.

Improve this answer
$\endgroup$
3
  • 1
    $\begingroup$ 1) TrueCrypt (and derivatives) concern me. 2) VeraCrypt/TrueCrypt has an intresting license. 3) TrueCrypt 7.1a is being audited while VeraCrypt hasn't been. With that said though, certainly worth looking into. :) $\endgroup$
    – Xeoncross
    Commented Jan 22, 2015 at 14:25
  • $\begingroup$ Even FIPS-approved or other government agency, a crypto protocol or tool can overnight be weakened. Many example in the history of modern crypto can confirm. The mystery surrounding the sudden and unilateral withdrawal, TrueCrypt is open and asked credible one. To my knowledge VeraCrypt corrected some historical weaknesses and improve the robustness of the protocol. If in doubt, I indicated the link to the sources, just waiting for your cryptanalysis. $\endgroup$
    – Robert NACIRI
    Commented Jan 22, 2015 at 14:35
  • $\begingroup$ As a novice, you should be orders of magnitude more worried about something you've implemented yourself by stringing together commands with OpenSSL than in weaknesses in something high-level that tries to make correct decisions for you like VeraCrypt/TrueCrypt. Choosing "good" primitives like AES is only one of many variables that need to be picked correctly. $\endgroup$
    – Stephen Touset
    Commented Jan 22, 2015 at 22:15
1
$\begingroup$

Not a definite answer but too much for comments:

That help msg shows that OpenSSL on OSX is an old version (<= 0.9.8) before GCM was added. (Probably =; 0.9.7 end-of-lifed around 2008. -salt has been the default since about 2004 so anyone who claims you need to specify it should be treated very skeptically.) You could add HMAC on top of AES-CBC encryption using dgst -sha512 -hmac keystring (or other supported hash of your choice); although not as modern and math-proven as GCM this should be enough for files stored locally, not transmitted over a hostile (e.g. public) network. (MAC after encrypt, and verify before decrypt, please; there are several questions and answers on why MAC first is too often a poor idea.)

openssl enc in most cases, including this one, does Password Based Encryption aka PBE, as @Stephen describes, but poor PBE: it uses a variant of PBKDF1 not 2 (medium bad) with salt (good) but iterations = 1 (VERY bad). These issues involve a routine named EVP_BytesToKey and searching on that will find you probably a dozen questions (and answers). TLDR: not recommended unless you use a password that is as strong as a key (at least 100 bits of entropy) and that will only work if you have some way to remember the "passwords" because humans can't do that much entropy. A custom commandline app that does PBE right (PBKDF2 and iterations in the high thousands or millions) could be about 30-50 lines of C (or C++ or ObjC), if you want to go that way.

Asides:

If the files are stored and copied only on your local disks, you don't need -a which encodes to base64 and decodes back; this used to be important for data to be transferred though things designed for text like email, but it is (a hair more than) 1/3 larger for no benefit on a local filesystem.

You can't gzip a folder. You can tar (or some other rarer things) a group of files including folder(s) or subtree(s) into a single file, and gzip (or bzip2 or lzma or otherwise compress) the tar file. GNU tar (not sure about availability on OSX) can do this as a single command like tar cz ... and tar xz ... which does the combination for you under the covers. You can also zip a group of files; zip is approximately the same algorithm as gzip but a (quite) different format, nowadays more popular on Windows (although historically it was fairly popular on pre-X Macs, as well as many Unixes and lots of systems forgotten today).

Improve this answer
$\endgroup$
0
$\begingroup$

In theory, aes-256-cbc cipher is safe for encrypting building blocks of the file you are trying to encrypt, with appropriate padding and IV random generation.

However, you may wish to note that: you need to securely erase the unencrypted file after you encrypt it. rm -rf filename does not erase the cleartext file, use srm instead.

Improve this answer
$\endgroup$
0
$\begingroup$

Have you tried eCryptfs? It's the default encryption method of home folder in Ubuntu. You should give a try!

Improve this answer
$\endgroup$
1
  • 1
    $\begingroup$ I was using the eCryptFS for about two years. It forks, but it has some caveats. First, it leaks some information about the structure (file count, file sizes etc.). Second, long file names aren't supported. This wasn't an issue for many cases, but Scala compiler generates sometimes too long filenames. Third, eCryptFS is poor on performance. While it might be OK for some particular use cases (including the Xeoncross's use case), switching to dm-crypt brought a significant performance gain. (But eCrypyFS might be more comfortable for some use cases.) $\endgroup$
    – v6ak
    Commented Jan 22, 2015 at 9:22

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