Why is unauthenticated encryption insecure? | Hacker News Reader

Why is unauthenticated encryption insecure?

cybergibbons.com

63 pointstodsacerdoti38 comments

It's worse than this article depicts. Without authentication, you can't even be sure you have confidentiality. Case in point: in the CBC scheme contemplated here, you can do more than change words in the plaintext; you can recover the entire plaintext, by feeding the decrypter a series of blocks with strategically corrupted padding.

I considered using a padding oracle attack in the post, but it's aimed at a very basic level of understanding. I find padding oracles are much harder to describe to newcomers.

Also, the XOR malleability issue is present in lots of block modes of operation.

You can read downthread commenters on this post taking away the message that when you select cryptographic building blocks, you need to determine "if you care about" message tampering. Which is, of course, not the message people need to hear.

Another note would be to point out that the limited attack you presented is a lot simpler to understand and execute in CTR mode (and has the benefit also of being more common in practice).

I've added a section on padding oracle attacks towards the bottom.

I don't think there's a significant different in ease of understanding between most of the modes. I used CBC as it's one of the most common and familiar modes, and because it's where I have seen this issue many times. I don't see CTR used in the wild very often.

I also tend to use CBC for other demos as well, so it makes things consistent.

For the benefit of the thread: the variant of the CBC bitflipping attack that applies to the more common CTR stream cipher mode is: you simply XOR in whatever data you want, directly to the bytes you want to alter, and that's the end of the attack.

Is CTR more common?

It is much more common. It's also much easier to use.

Note that the common AEAD modes, AES-GCM and ChaCha20-Poly1305, are CTR + MAC. The most common style of MAC is Carter Wegman MAC, the second most common is CCM and EAX and the like, after that HMAC. Nothing new uses CBC or CFB or OFB or any of those.

Would AES-CTR [edited] with deterministic encryption via using the hash of the encrypted value as IV be secure under such schemes?

Are you meaning to say "RSA-CTR", as in, RSA as a direct stream cipher? Never do that.

Actually meant AES-CTR with hash-of-value as IV. Workable if deterministic encryption is a requirement?

Why not? Speed?

The hash of the encrypted value encrypted using what?

>Without authentication, you can't even be sure you have confidentiality.

Sure you can: a classic XOR one-time pad has no authentication and it's the definition of confidentiality-preserving.

It's true that malleability makes it easier to attack certain protocols which can then result in a loss of the confidentiality property. Your padding oracle example is a case in point, and there's seldom a reason to avoid an authenticated encryption mode for a message that's sitting inside a TCP packet.

On the other hand, sometimes malleability is a desirable property, and authentication is harmful. The APCO Project 25 radio standard, intended for use in the mobile radio world, has encryption as an option. The priority is to maintain confidentiality and to degrade gracefully in a hostile RF environment.

Encryption is applied after error-correcting codes using OFB mode, and so effects of interference apply bitwise within the data stream on decryption. An authenticating mode would be a disaster as a single bit error would result in the loss of an entire transmission.

Don't you need authentication to get the one-time pad in the first place?

No they are sent by snailmail.

Any offline method works. Transfer by handshake, travel with it in your bag from the main office, or injected as a chip under your skin since birth, any such method. :)

Don't you offload the authentication to the postal service in this case?

Key material distribution is a completely separate problem from authentication of a message.

Even if you use an authenticated encryption mode, you still have the problem of "how does this symmetric key get shared with only the intended parties?".

This is a little like saying unauthenticated CBC mode is fine as long as all you're doing is blitting out the raw ciphertext, padding (or otherwise) included, for a human being to read in a hexdump.

Any step you take past that is a computer program that holds a secret key acting on ciphertext chosen by an attacker and thus revealing some kind of behavior to them. There have been surprising "oracles" found in a variety of constructions beyond CBC mode. Modern cryptography chooses to avoid this problem entirely.

So encryption is insecure because encryption is not signing?

Basically, yeah, although "insecure" is a bit too broad; unauthenticated encryption is insecure in some contexts, like sending messages to another person. But if you're encrypting your own backups, and all you care about is that the NSA can't see what you're storing, then there's no insecurity: encryption alone is sufficient.

By the same token, sometimes authentication alone is sufficient, like if you just want to verify that some person did indeed "authorize" a particular message -- for example, a public forum post with an attached PGP signature.

Malleable backups are not secure when they need to be restored, something that could be necessary if by some chance a server of yours became dead suddenly.

If modification of your backups is possible then you should just sign them. Then it doesn't matter if your encryption is malleable or not. Why have just an integrity check when you can have an authenticity check as well?

That's not what they're saying. The point is that common block-encryption modes are exploitable, and many of these exploits can be mitigated with message authentication (or by using authenticated block modes, like AES-GCM.)

No; the point is that confidentiality and integrity of communication are different concepts and that some choices of encryption algorithm will only provide the former. If you care about being able to detect message tampering in a robust way you need to make the right design choices.

Authenticated encryption isn't the same as signing encrypted data.

Even when you don't generally care about the properties digital signatures provide you almost always need authentication w/ encryption because block cipher modes make the behaviour of the encryption differ in surprising and important ways from an idealized black box.

Concretely:

Imagine I setup a service that accepts commands through encrypted messages with a static key. Only authorized parties know the keys.

Each (encrypted) command sent to the services includes a user and password.

At first glance you might consider this setup reasonably secure but if authenticated encryption is not used a MITM can modify the ciphertext to cause predictable modifications to the plain text, preserving the user and password but changing the command or its parameters.

Eg. Imagine the cipher used is AES-CTR, the attacker can just xor whatever he wants into the plaintext. If a CBC mode is used, the attacker has a little less flexibility but still a lot.

Beyond breaking control the lack of authentication can also break confidentiality: For example, if the service provides different error behaviours for different corrupted inputs, I could replay a message with many different corruptions to determine it's content.

Yes, if you augmented this protocol with a digital signature it could accomplish authentication (if implemented correctly!); but since the protocol has no particular need for a digital signature otherwise the signature is an extremely slow way to accomplish authenticated encryption (compared to a proper authenticated encryption mode). An authenticated block cipher mode can be made pretty much just as fast as unauthenticated (at least for longer messages, and only (say) a 2x slow down for the shortest messages... one or more orders magnitude better than a digital signature).

It is very hard to design secure cryptographic protocols and systems and even harder to have a good basis to believe that they're secure. Whenever the primitives we use have subtle behaviour that differs from an idealized version that job becomes significantly harder. Authenticated encryption works a lot more like a simple black box "ideal encryption" than non-authenticated ciphers.

Secure systems could use either, but non-auth is a LOT easier to end up with an insecure protocol by surprise.

And that doesn't even touch on replay attacks.

If you have a door lock that accepts "lock", "unlock" and "report status", a MITM attacker only needs to capture the encrypted & signed "unlock" command, then replay it later.

Many workarounds were developed to mitigate this such as random values, incrementing values and timestamps, but most were found insecure. Challenge-response systems with a short validity period are one of the better systems in use, but require bi-directional communication which can make some products (ex: garage door openers) more expensive.

What about using a time based one time password algorithm instead of a challenge-response mechanism? Most embedded systems have a real time clock. Would it make sense to use this technology for that? https://en.m.wikipedia.org/wiki/Time-based_One-time_Password...

RTCs are actually quite rare, especially in a lot of the lower power RF SoCs.

Drift would also be an issue - most move at least 10 minutes a year. That's with good temperatures, not being left in a hot car or at body temp.

If you could solve the drift issue then it would be pretty good I think, it's an interesting idea.

Maybe you could use the secure connection to resync the time or some other clock with the authenticated server. I guess that’s just another request / response type of arrangement though. And then any breakdown of communication for an extended period of time would brick the whole thing.

EDIT: Maybe the time based one time password algorithm can be configured to be made less time granular (say daily) so that it can handle clock drift.

Actually, why doesn't signing a time-stamped unlock work?

That's one of the other popular strategies, but relies on both devices have accurate clocks. With computers and servers (where the strategy is used quite a bit, sometimes in combination with challenge-response), it's quite easy. If you're working with something non-networked or battery powered like a garage door opener, clock drift becomes a serious issue.

Secure systems cannot use either a signature or authenticated encryption. Signing a message is not sufficient to prevent tampering that leads to an attacker reading the message by seeing errors in processing the tampered message. You need either authenticated encryption or signcryption.

Suppose your format is ciphertext || signature. An attacker can strip off the signature, modify the ciphertext, and then sign the modified ciphertext as coming from an attacker controlled account. The recipient will then accept the ciphertext, decrypt it, and parse it. Errors on decrypting or parsing induced by mutations can then be used to get the plaintext.

This isn't theoretical. It happened to iMessage[1] and GPG[2] And no, you cannot just include the sender inside the ciphertext. iMessage tried that. It didn't work. In general, there are two problems 1) the ciphertext is malleable and the id can be changed. 2) the error could happen before you can read the sender id from the ciphertext.

Signing and authenticated encryption really don't do the same thing. [1]https://www.usenix.org/system/files/conference/usenixsecurit... [2]https://efail.de/

Isn't that why HMAC exists?

This is the best example of an attack against PGP encryption malleability that I have come across. It uses the modification to enhance social engineering and make it more likely you could get someone to decrypt a message and then return the decrypted message to them:

* https://www.schneier.com/academic/archives/2000/08/a_chosen_...

EFAIL is a poor example of this sort of thing. EFAIL was based on the information leak from HTML emails. The malleable encryption angle was quite forced:

* https://articles.59.ca/doku.php?id=pgpfan:efail

In an email context a missing signature or a signature from someone you do not know counts as an invalid signature. A signature does in fact detect both of these to the extent that authenticated encryption could.

>Errors on decrypting or parsing induced by mutations can then be used to get the plaintext.

That sort of oracle attack can't really work in practice with a one way medium like email.

>But not authenticating your encryption can lead to worse issues. A type of attack called padding oracle attacks can let an attacker obtain the encryption key by sending a large number of specially crafted packets.

I believe that's wrong. I don't think a padding oracle attack will leak the key. It will leak the plaintext only.

Yes, sorry, added that bit on my phone when out and about and made a mistake. Corrected.

Reply on news.ycombinator.com