So encryption is insecure because encryption is not signing?
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.
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.
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.
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.
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/
* 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.
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.