1
$\begingroup$

I've read/skimmed a few documents about the AES family of encryption, but haven't seen anything about what exactly it protects against. There are many ways to "encrypt" things, and not all of them provide the same set of guarantees. For example:

  1. Can an attacker, knowing the plaintext, alter the ciphertext in a way such that subsequent decryption yields a plaintext of the attacker's choosing?
  2. Can an attacker, given multiple ciphertexts encrypted with the same passphrase, calculate the key? Or reduce the security of the given ciphertexts?
  3. Take one plaintext and encrypt it into two ciphertexts, using the same passphrase. Can an attacker determine that the ciphertexts have the same plaintext?
  4. If the ciphertext is corrupted, can the decryption algorithm detect that?

Etc. There are no doubt many more attacks that could be performed. I'd like to know what AES guarantees, assuming its strength and correct implementation.

$\endgroup$
0
$\begingroup$

1: Depending on the mode that is possible, that is why we authenticate ciphertext.

2: Probably not.

3: Depends on the mode and the process used to convert the passphrase into the AES key.

4: No.

AES is a block cipher. It uses a key to encrypt 128-bit blocks of data. There are many many ways to do this. Above the cipher is the mode of operation, and above that is the scheme/protocol. Beside that is how the key is generated. All of these must me considered in a threat model.

To address specific comments relating to GPG

GNU PG uses 2 modes, puclic key mode and symmetric password based encryption mode. These generally use the same enciphering mode, but the key and authentication is different.

Public key mode uses CFB mode with full block feedback and a random IV, then it signs the ciphertext. It uses a random key for each message. The key is then encrypted with the recipient public key so that only the recipients private key can recover the encryption key and decrypt the ciphertext.

Symmetric key mode derives the key from the password, the default is 65536 iterations of SHA-1 with an 8 byte salt, that salt may only be 48-bits but that is not bad. The iteration count however, you can manually increase that within limits, I would go to at least 16 million. Note that in some versions the iteration count may be calculated based on system performance, and vary between 65536 and 65011712, which is 31 * 2$^{21}$, the maximum allowed iteration count. The algorithm used is SimpleS2K, which is used for backwards compatibility with the OpenPGP standard.

I am not sure on the defaults, but I believe the symmetric mode does have an authentication code, and the default should generate a unique encryption key for every message, so recovering the key will not expose other ciphertexts with the same password. The password is much easier to recover however, which is why you want more iterations or a better password.

Going back to the original questions but specific for GPG symmetric:

1: Not if the ciphertext is authenticated

2: No.

3: No.

4: No, but a message signature will, I suggest signing all ciphertexts.

$\endgroup$
8
  • $\begingroup$ In that case, then, I suppose my true question is "what does GPG's use of AES in symmetric encryption mode defend against?" If you have a brief answer or link to relevant data, that would be appreciated, but otherwise I may open a new question. $\endgroup$ – Erhannis Sep 10 '19 at 0:15
  • 1
    $\begingroup$ @Erhannis GPG uses CFB mode with full block feedback and a random IV, then it signs the ciphertext, which should provide authentication. Explicit details are defined in the OpenPGP message format RFC tools.ietf.org/html/rfc4880 $\endgroup$ – Richie Frame Sep 10 '19 at 0:41
  • $\begingroup$ @Erhannis Also GPG uses a new random key for each message, not a password derived key, so there is no issue of key recovery attacking other messages $\endgroup$ – Richie Frame Sep 10 '19 at 0:43
  • $\begingroup$ Number 2 should be "no", not "probably not". AES is still considered very secure. $\endgroup$ – forest Sep 10 '19 at 7:37
  • $\begingroup$ @RichieFrame Well, the key has to be derived from the password at some level, because otherwise you wouldn't be able to use the password to decrypt the ciphertext, yeah? $\endgroup$ – Erhannis Sep 10 '19 at 20:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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