❌ Software Removal | AES Crypt #805
Labels
No Label
🔍🤖 Search Engines
approved
dependencies
duplicate
feedback wanted
high priority
I2P
iOS
low priority
OS
Self-contained networks
Social media
stale
streaming
todo
Tor
WIP
wontfix
XMPP
[m]
₿ cryptocurrency
ℹ️ help wanted
↔️ file sharing
⚙️ web extensions
✨ enhancement
❌ software removal
💬 discussion
🤖 Android
🐛 bug
💢 conflicting
📝 correction
🆘 critical
📧 email
🔒 file encryption
📁 file storage
🦊 Firefox
💻 hardware
🌐 hosting
🏠 housekeeping
🔐 password managers
🧰 productivity tools
🔎 research required
🌐 Social News Aggregators
🆕 software suggestion
👥 team chat
🔒 VPN
🌐 website issue
🚫 Windows
👁️ browsers
🖊️ digital notebooks
🗄️ DNS
🗨️ instant messaging (im)
🇦🇶 translations
No Milestone
No Assignees
1 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: privacyguides/privacytools.io#805
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.
From the issue you linked:
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 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.
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:
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.
Yep, that totally made sense to me which is why I sent through the PR. Good catch, nice work 😄