❌ Software Removal | AES Crypt #805

New Issue

2019-04-01T01:29:00Z

skeeto commented

2019-04-01 01:29:00 +00:00

(Migrated from github.com)

AES Crypt does not completely authenticate its input. An attacker who can manipulate encrypted data has some limited control over the plaintext file length. This could be used, for example, to truncate the end of the file without being detected. This issue was discovered in 2012 but was never fixed because it requires changing the file format. I discovered it independently today: proof of concept and informal security audit.

I believe it is not appropriate to recommend this software as long as it has this particular flaw. Since it's part of the file format, all implementations are vulnerable.

AES Crypt does not completely authenticate its input. An attacker who can manipulate encrypted data has some limited control over the plaintext file length. This could be used, for example, to truncate the end of the file without being detected. This issue [was discovered in 2012](https://web.archive.org/web/20121029141517/https://www.aescrypt.com/wishlist.html) but was never fixed because it requires changing the file format. I discovered it independently today: [proof of concept](https://github.com/paulej/AESCrypt/issues/23) and [informal security audit](https://old.reddit.com/r/privacytoolsIO/comments/b7riov/aes_crypt_security_audit_1_serious_issue_found/). I believe it is not appropriate to recommend this software as long as it has this particular flaw. Since it's part of the file format, all implementations are vulnerable.

👍 2

jonah commented

2019-04-01 01:38:22 +00:00

From the issue you linked:

The solution is simple, but making the change breaks backward compatibility. Given the primary objective of AES Crypt is to secure data, the balance between privacy and fixing this (which does not affect privacy, but just annoying) was to leave it alone.

Could you explain to me (a person who is not a cryptographer necessarily) why this is a big deal, and why the developers of this program don't seem to think it's a big deal?

I don't really see why this couldn't be removed from the site necessarily, since it's just in a "worth mentioning" slot, I'm just not entirely clear on what the implications of this are, since it sounds like an attacker would need to have access to the plain text file in the first place?

From the issue you linked: > The solution is simple, but making the change breaks backward compatibility. Given the primary objective of AES Crypt is to secure data, the balance between privacy and fixing this (**which does not affect privacy**, but just annoying) was to leave it alone. Could you explain to me (a person who is not a cryptographer necessarily) why this is a big deal, and why the developers of this program don't seem to think it's a big deal? I don't really see why this couldn't be removed from the site necessarily, since it's just in a "worth mentioning" slot, I'm just not entirely clear on what the implications of this are, since it sounds like an attacker would need to have access to the plain text file in the first place?

jonah commented

2019-04-01 01:51:50 +00:00

From re-reading what you said and everything you linked, that all makes sense. I don't think it should be something we're recommending on PTIO.

skeeto commented

2019-04-01 13:59:15 +00:00

(Migrated from github.com)

Could you explain to me (a person who is not a cryptographer necessarily) why this is a big deal, and why the developers of this program don't seem to think it's a big deal?

The reason you would encrypt a piece of data is because it's going to pass through an untrusted medium. You want to ensure both the confidentiality and the integrity of the data. The first prevents someone from reading your data. The second prevents someone from modifying your data. There are lots of schemes that make strong guarantees about confidentiality but do nothing for integrity. In fact, confidentiality is actually the easiest part to get right.

For example, stream ciphers, which work by XORing the plaintext with the output from a cryptographically secure pseudo-random number generator (CSPRNG), are very malleable. Anyone who can modify the ciphertext can trivially flip any bit in the plaintext without knowing the key or the plaintext. With a little bit of knowledge about the plaintext — something that's quite common since the protocol being encrypted has deterministic structure — an attacker could very easily change the meaning of a message while keeping it valid for the protocol.

The situation with AES Crypt isn't nearly that bad. The sky isn't falling, and confidentiality is still intact. That's why its authors aren't worried. The ciphertext itself is properly authenticated, and so there's no publicly known way to manipulate the plaintext bits without knowing the key. However, the file length isn't authenticated, so the attacker can control it inside of a 16-byte window. My proof of concept included a dramatic example showing how even that this small amount of control can change the meaning of a message. As another example, consider an shell script like this that's encrypted with AES Crypt:

#!/bin/sh
rm -rf $HOME/trash

Using this flaw, an attacker could truncate trash from the end of the script (again, without the key!). The victim might later decrypt this and run the script without inspecting it, getting a nasty surprise. After all, why inspect it if AES Crypt ensures the integrity? Well, you still need double check since AES Crypt drops the ball!

For decades authentication has been considered an indispensable and essential component of any cryptographic scheme. There's no excuse not to use authentication, and nobody should ever be using a scheme that doesn't authenticate its ciphertext. AES Crypt almost gets it right, but since it misses the mark, it shouldn't be used. There are lots of other choices out there without this flaw.

> Could you explain to me (a person who is not a cryptographer necessarily) why this is a big deal, and why the developers of this program don't seem to think it's a big deal? The reason you would encrypt a piece of data is because it's going to pass through an untrusted medium. You want to ensure both the *confidentiality* and the *integrity* of the data. The first prevents someone from reading your data. The second prevents someone from modifying your data. There are lots of schemes that make strong guarantees about confidentiality but do nothing for integrity. In fact, confidentiality is actually the easiest part to get right. For example, stream ciphers, which work by XORing the plaintext with the output from a cryptographically secure pseudo-random number generator (CSPRNG), are very malleable. Anyone who can modify the ciphertext can trivially flip any bit in the plaintext without knowing the key or the plaintext. With a little bit of knowledge about the plaintext — something that's quite common since the protocol being encrypted has deterministic structure — an attacker could very easily change the meaning of a message while keeping it valid for the protocol. The situation with AES Crypt isn't nearly that bad. The sky isn't falling, and *confidentiality* is still intact. That's why its authors aren't worried. The ciphertext itself is properly authenticated, and so there's no publicly known way to manipulate the plaintext bits without knowing the key. However, the file length isn't authenticated, so the attacker can control it inside of a 16-byte window. My proof of concept included a dramatic example showing how even that this small amount of control can change the meaning of a message. As another example, consider an shell script like this that's encrypted with AES Crypt: #!/bin/sh rm -rf $HOME/trash Using this flaw, an attacker could truncate `trash` from the end of the script (again, without the key!). The victim might later decrypt this and run the script without inspecting it, getting a nasty surprise. After all, why inspect it if AES Crypt ensures the integrity? Well, you still need double check since AES Crypt drops the ball! For decades authentication has been considered an indispensable and essential component of any cryptographic scheme. There's no excuse not to use authentication, and nobody should ever be using a scheme that doesn't authenticate its ciphertext. AES Crypt *almost* gets it right, but since it misses the mark, it shouldn't be used. There are lots of other choices out there without this flaw.

❤️ 1

jonah commented

2019-04-01 18:01:54 +00:00

My proof of concept included a dramatic example showing how even that this small amount of control can change the meaning of a message.

Yep, that totally made sense to me which is why I sent through the PR. Good catch, nice work 😄

>My proof of concept included a dramatic example showing how even that this small amount of control can change the meaning of a message. Yep, that totally made sense to me which is why I sent through the PR. Good catch, nice work 😄

This repo is archived. You cannot comment on issues.

1 Participants

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: privacyguides/privacytools.io#805