5 ms·

So encryption is insecure because encryption is not signing?

nemo1618 6y ago
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.
- eurg 6y ago
  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.
  - upofadown 6y ago
    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?
zeroxfe 6y ago
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.)
NovemberWhiskey 6y ago
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.
nullc 6y ago
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.
- PowerBar 6y ago
  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.

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.

eurg 6y ago
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.
- upofadown 6y ago
  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?

zeroxfe 6y ago

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.)

NovemberWhiskey 6y ago

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.

nullc 6y ago

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.

PowerBar 6y ago
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.