Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Is openssl enc a good choice for file encryption?

news.ycombinator.com

Post reply on HN
Print view View original

11–17 of 17 posts

Re: Ask HN: Is openssl enc a good choice for file encryption?

#11

Post by Canada »

caivvoacmh wrote: post #10
Canada wrote: post #7

Earlier quoted context omitted.

CBC mode is malleable. I can modify a block and the previous blocks won't be corrupted. The blocks I modify will silently decrypt, although I won't know what the output will be. Regardless, the decrypted output may still do something harmful. The solution is to generate a hash or a MAC after encrypting. A plain hash would have to be kept locally because the malicious server could modify it if stored there. A MAC coul…

Do I follow correctly that the issue with using `openssl enc` is the cipher `aes-256-cbc` not providing integrity of the encrypted file? Even if you wanted to use a more secure cipher according to [this]( https://security.stackexchange.com/questions/128883/basic-qu... ) `openssl enc` does not support the more secure ciphers that openssl tls does. Is this the reason to avoid openssl for file encryption?

TLS and AES-CBC aren't comparable.

AES-CBC is just a block cipher mode of operation. TLS is a protocol that takes care of negotiating algorithms for key exchange, bulk encryption (which may be a block cipher using some mode), authentication, etc. All of these things combined is the "suite" of ciphers. Implementations provide decent tooling for managing keys and preferences.

Like TLS, GPG uses a suite of ciphers to do its job and provides tools to manage it without getting caught up in extremely low level details. Like TLS, the default suite of algorithms it prefers change with the times, but from a user perspective it stays the same.

Re: Ask HN: Is openssl enc a good choice for file encryption?

#12

Post by Canada »

caivvoacmh wrote: post #9
Canada wrote: post #2

One problem is there's no authentication. The malicious server could modify your backup. Another scary thing about this is the fact that you have to keep track of the AES key for the backup as well as your private RSA key and its password. That's going to get nasty for more than a couple of files. If you're going to do backups like this you're better off just sticking with GPG.

When I read "authentication" I think of the process of providing a username/password to authenticate with an online service, e.g. facebook. Is authentication wrt to encryption not when you provide the password to encrypt/decrypt?

No, it's not. Authentication means ensuring the data is not tampered with between the time it's encrypted and decrypted.

Re: Ask HN: Is openssl enc a good choice for file encryption?

#13

Post by bwackwat »

Canada wrote: post #11
caivvoacmh wrote: post #10

Earlier quoted context omitted.

Do I follow correctly that the issue with using `openssl enc` is the cipher `aes-256-cbc` not providing integrity of the encrypted file? Even if you wanted to use a more secure cipher according to [this]( https://security.stackexchange.com/questions/128883/basic-qu... ) `openssl enc` does not support the more secure ciphers that openssl tls does. Is this the reason to avoid openssl for file encryption?

TLS and AES-CBC aren't comparable. AES-CBC is just a block cipher mode of operation. TLS is a protocol that takes care of negotiating algorithms for key exchange, bulk encryption (which may be a block cipher using some mode), authentication, etc. All of these things combined is the "suite" of ciphers. Implementations provide decent tooling for managing keys and preferences. Like TLS, GPG uses a suite of ciphers to do…

Ok so I guess the resulting lesson from Canada for me is that having a HASH or MAC for encrypted files is the most critical part of any secure system OP is interested in.

Furthermore, Canada, what about privately managed machines communicating via TCP and AES 256 CBC symmetrically encrypted messages? I also use a random salt and a transaction number.

Until now, I was thinking that successfully decrypted data would be safe. Is the case for TCP encrypted data the same? I need to have a MAC for each message and verify that between ACK's or something?

EDIT: Did some research: https://en.wikipedia.org/wiki/Authenticated_encryption

It looks like incorporating a MAC within or alongside the encrypted data is not as insecure or as complex as I was afraid.

Can both my TCP encryption and OP's file encryption problem by solved by just appending a HASH of the encrypted data to the end of the encrypted data (EtM), or appending a HASH of the plaintext data to the end of the plaintext data and then encrypting that (MtE)?

Re: Ask HN: Is openssl enc a good choice for file encryption?

#14

Post by Canada »

bwackwat wrote: post #13
Canada wrote: post #11

Earlier quoted context omitted.

TLS and AES-CBC aren't comparable. AES-CBC is just a block cipher mode of operation. TLS is a protocol that takes care of negotiating algorithms for key exchange, bulk encryption (which may be a block cipher using some mode), authentication, etc. All of these things combined is the "suite" of ciphers. Implementations provide decent tooling for managing keys and preferences. Like TLS, GPG uses a suite of ciphers to do…

Ok so I guess the resulting lesson from Canada for me is that having a HASH or MAC for encrypted files is the most critical part of any secure system OP is interested in. Furthermore, Canada, what about privately managed machines communicating via TCP and AES 256 CBC symmetrically encrypted messages? I also use a random salt and a transaction number. Until now, I was thinking that successfully decrypted data would be…

I think EtM is better than the alternatives. As for the rest of it, you need to explicitly describe your protocol and what security you think it guarantees. Then you should ask for review wherever you can. Same for your implementation.

Re: Ask HN: Is openssl enc a good choice for file encryption?

#15

Post by scottpiper »

Canada wrote: post #11
caivvoacmh wrote: post #10

Earlier quoted context omitted.

Do I follow correctly that the issue with using `openssl enc` is the cipher `aes-256-cbc` not providing integrity of the encrypted file? Even if you wanted to use a more secure cipher according to [this]( https://security.stackexchange.com/questions/128883/basic-qu... ) `openssl enc` does not support the more secure ciphers that openssl tls does. Is this the reason to avoid openssl for file encryption?

TLS and AES-CBC aren't comparable. AES-CBC is just a block cipher mode of operation. TLS is a protocol that takes care of negotiating algorithms for key exchange, bulk encryption (which may be a block cipher using some mode), authentication, etc. All of these things combined is the "suite" of ciphers. Implementations provide decent tooling for managing keys and preferences. Like TLS, GPG uses a suite of ciphers to do…

I'm the author of the blog post in question (and have no idea why HN won't let me reply to the original post). For some clarity here, the "untrusted" third party is Google, whom I don't want to read my data, but I trust that they will not modify my backups. However, in the article I do gzip the files before encrypting them, and gzip has a CRC-32 check, so if the files were modified, then after decryption when you attempted to gunzip them, it would error.

I used openssl because I find GPG on servers is awkward to use.

The full article is more clear that I have only one private key, and for all the nightly backups I'm generating AES keys and encrypting them with the public key.

Re: Ask HN: Is openssl enc a good choice for file encryption?

#16

Post by Canada »

scottpiper wrote: post #15
Canada wrote: post #11

Earlier quoted context omitted.

TLS and AES-CBC aren't comparable. AES-CBC is just a block cipher mode of operation. TLS is a protocol that takes care of negotiating algorithms for key exchange, bulk encryption (which may be a block cipher using some mode), authentication, etc. All of these things combined is the "suite" of ciphers. Implementations provide decent tooling for managing keys and preferences. Like TLS, GPG uses a suite of ciphers to do…

I'm the author of the blog post in question (and have no idea why HN won't let me reply to the original post). For some clarity here, the "untrusted" third party is Google, whom I don't want to read my data, but I trust that they will not modify my backups. However, in the article I do gzip the files before encrypting them, and gzip has a CRC-32 check, so if the files were modified, then after decryption when you att…

I don't know why HN disallows reply in certain circumstances. If you replied to the original post I never would have seen your reply.

If you don't care if the third party can modify your data, then OK. If you did care though, does this checksum stop "tar xvzf foo.tgz" from writing modified data immediately? Or does it just tell you at the end?

Re: Ask HN: Is openssl enc a good choice for file encryption?

#17

Post by scottpiper »

Canada wrote: post #16
scottpiper wrote: post #15

Earlier quoted context omitted.

I'm the author of the blog post in question (and have no idea why HN won't let me reply to the original post). For some clarity here, the "untrusted" third party is Google, whom I don't want to read my data, but I trust that they will not modify my backups. However, in the article I do gzip the files before encrypting them, and gzip has a CRC-32 check, so if the files were modified, then after decryption when you att…

I don't know why HN disallows reply in certain circumstances. If you replied to the original post I never would have seen your reply. If you don't care if the third party can modify your data, then OK. If you did care though, does this checksum stop "tar xvzf foo.tgz" from writing modified data immediately? Or does it just tell you at the end?

Probably just at the end. My goal is disaster recovery (AWS disappears as a service to the world because an Amazon employee accidentally `rm -rf` everything, or my own admin `rm -rf`'s my account on accident) so for those situations, I'm going to need to extract out the data somewhere and then rebuild, so checking at the end of the extraction and unzip is fine for my needs.
Post reply on HN