4 ms·

Yes Canada is right. Asymmetrical encryption is what you want. You can bake the signature into all of your hosts that need it, that way they encrypt a file with

Yes Canada is right. Asymmetrical encryption is what you want. You can bake the signature into all of your hosts that need it, that way they encrypt a file without needing to know how to decrypt it. Ask your third-party to supply a gpg public key over a secure channel, then it's very to encrypt files for them (and only them) to read.

bwackwat 10y ago
He is uploading files to an UNTRUSTED third party. I'm personally curious about the best solution... @Canada, if the "malicious"(untrusted?) server modifies the backup how could you decrypt anyway?
- Canada 10y ago
  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 could be stored on the server, but then it would be necessary to derive another key for that and store it locally. (Or store the input for deriving the encryption key and MAC key... in any case, annoying) GPG takes care of all this for you. Bottom line: Avoid OpenSSL command line for this kind of thing.
  - bwackwat 10y ago
    I agree that using the command line for this type of problem is going to be problematic. I also see clearly how hashing the encrypted data before "storing it at this 3rd party" would allow you to verify CBC block modifications. I guess I don't understand GPG well enough to see how it solves this problem better than AES CBC 256. Could you perchance provide a link? Or explain how GPG would take care of this?
  - caivvoacmh 10y ago
    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-question-regarding-openssl-and-aes-gcm 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?
    - Canada 10y ago
      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.
      - bwackwat 10y ago
        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 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)?
caivvoacmh 10y ago
The third-party is not taking part in the encryption.

bwackwat 10y ago

He is uploading files to an UNTRUSTED third party. I'm personally curious about the best solution... @Canada, if the "malicious"(untrusted?) server modifies the backup how could you decrypt anyway?

Canada 10y ago
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 could be stored on the server, but then it would be necessary to derive another key for that and store it locally. (Or store the input for deriving the encryption key and MAC key... in any case, annoying) GPG takes care of all this for you. Bottom line: Avoid OpenSSL command line for this kind of thing.
- bwackwat 10y ago
  I agree that using the command line for this type of problem is going to be problematic. I also see clearly how hashing the encrypted data before "storing it at this 3rd party" would allow you to verify CBC block modifications. I guess I don't understand GPG well enough to see how it solves this problem better than AES CBC 256. Could you perchance provide a link? Or explain how GPG would take care of this?
- caivvoacmh 10y ago
  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-question-regarding-openssl-and-aes-gcm 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?
  - Canada 10y ago
    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.
    - bwackwat 10y ago
      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 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)?

caivvoacmh 10y ago

The third-party is not taking part in the encryption.