4

I cannot come up with a case where there is only one of them.

When there is integrity, a random person cannot modify the message without being noticed. That is, an unauthenticated user cannot modify the message without being noticed. Therefore there is authentication.

When there is authentication, nobody except the sender can change the message after MAC or signature is added. Therefore there is integrity.

Am I missing something?

Ruminateer
  • 41
  • 2
  • authentication isn't "nobody except the sender can change the message". It's actually, "you are sure that the message has been sent by a particular agent from which the message claims to be". – Vineet Menon Oct 28 '19 at 05:46
  • 1
    @VineetMenon That's authenticity, not authentication. In cryptography at least, a MAC provides authentication (integrity), not authenticity. That's why cipher constructions that natively provide integrity are called AE ciphers, for Authenticated Encryption (sometimes AEAD, for Authenticated Encryption with Associated Data, for authentication of data that is transmitted in cleartext, like IVs). In traditional infosec, authentication has a totally different meaning and refers more to policy and permissions. – forest Oct 28 '19 at 06:09
  • 1
    *"When there is authentication, nobody except the sender can change the message after MAC or signature is added. Therefore there is integrity."* - This argument essentially that __if a proper integrity check is added__ (i.e. MAC or proper signature which include the full message) __then there is integrity__. Only, authentication does not mandate that such integrity check is added, i.e. one can have authentication without integrity. – Steffen Ullrich Oct 28 '19 at 06:32
  • 1
    Although not an exact duplicate, this question has already been asked and answered:[Difference between authentication, integrity and data origin authentication](https://security.stackexchange.com/questions/93322/difference-between-authentication-integrity-and-data-origin-authentication) – s h a a n Oct 28 '19 at 06:55
  • You can also have a look at my answer [on the crypto site](https://crypto.stackexchange.com/a/29085/1172) to a related question that also comes down to the same thing. – Maarten Bodewes Nov 07 '19 at 15:39
  • See https://security.stackexchange.com/questions/33569/why-do-you-need-message-authentication-in-addition-to-encryption. Near the end of the answer by Polynomial, he quotes Thomas Pornin, who said, *"There's a tricky definition point there. Integrity is that you get the "right data", but according to what notion of "right" ? How comes the data from the attacker is not "right" ? If you answer "because that's from the attacker, not from the right client" then you are doing authentication..."* That basically sums it up. – mti2935 Dec 04 '20 at 11:56

3 Answers3

2

You are not missing anything. There is no meaningful distinction in cryptography between ‘integrity’ and ‘authentication’ of data on a channel between two parties. Any attempts at distinction in the context of an adversary wallow in confusion of epistemology without a difference. (If you really like the cute acronym CIA for spook stuff, maybe use the A for ‘availability’ instead!)

The words are not entirely synonymous, of course—for example, a dishonest politician does not lack ‘authentication’, and logging into your bank's web site is not doing ‘integrity’—but it sounds like you're asking how they apply a protocol in which there are three things:

  • A sender; call her Alice.
  • A channel or medium for exchanging messages, such as the internet, or a disk for storing and retrieving files.
  • A receiver; call him Bob.

Alice's goal is to transmit a message to Bob using the channel. Presumably, the channel is subject to malicious tampering by an adversary; otherwise there's no security question here. Presumably, Alice and Bob know something about one another a priori; otherwise when Bob receives a message there is necessarily no way he can distinguish a message Alice sent from a message the adversary sent!

Under what circumstances, then, does the protocol have authentication or integrity? Either way, what it means is that—whatever steps Alice takes to send a message, and however Bob verifies the authenticity of a message—the probability that an adversary succeeds in fooling Bob into accepting a forgery is negligible.

In cryptography, we formalize the notion of ‘authentication’ or ‘integrity’ with the EUF-CMA game—existential unforgeability under chosen-message attack. In the EUF-CMA game, Mallory, our heroic adversary, can ask Alice to send any message of Mallory's choice, in order to study how Alice is authenticating messages. Mallory wins the game if they can fool Bob into accepting any message Alice didn't send. Mallory would win the game even if the message is totally meaningless to Bob. The protocol is said to provide EUF-CMA security if the probability that Mallory wins this game is negligible no matter how clever they are.

The EUF-CMA criterion applies to both symmetric-key authenticators, also known as message authentication codes, and public-key signatures; the main difference between authenticators and signatures is whether the power to send a message is the same as the power to verify a message, or whether the powers are asymmetric so that when Alice signs a message, anyone—Bob or any third party—can verify it too.

Outside cryptography, one might reasonably consider a sort of unintelligent adversary—a channel with random noise—and one might use an error-detecting or error-correcting code to provide integrity, meaning that the probability of undetected corruption is substantially smaller with the code, whereas the term authentication doesn't really come up in coding theory at all, so there's no contrast to make between the terms in that context. One might even use a ‘cryptographic hash function’ like SHA-256, truncated if you have limited bandwidth, but one would be better off with a CRC.

Squeamish Ossifrage
  • 2,636
  • 8
  • 17
0

Example of integrity without authentication

You download a file and a corresponding checksum over HTTP, and an attacker intercepts both the file, and the checksum. You compare the checksum of the received file with the expected checksum, and it correctly shows that the file is intact. It shows you received what you were intended to receive, but not that the sender is authentic.

Example of authentication, but without integrity

You download a file via HTTPS using TLS (no checksum), but there is an I/O read error on the sender's side prior to transmission, and you receive a corrupted file. In this case you can be sure the sender is authentic, yet there is no integrity of what you received.

Summary

Integrity shows that you received what you were intended to receive (by whomever). Authentication shows that the sender is who he says he is.

Community
  • 1
ig-dev
  • 1,118
  • 5
  • 13
  • 1
    This is a distinction without a difference. In example 1, it is silly to call this ‘integrity’ because _an adversary forged the document_. In example 2, there is integrity/authentication between the ‘sender’ and the receiver, but not between the _author of the document_ and the receiver. Rather than sweep this into the confusing nomenclature ‘integrity _vs._ authentication’, which nobody can agree on a difference between, it is clearer to just identify the parties and channels: server⟶(network)⟶adversary⟶(more network)⟶you, author⟶(disk)⟶sender⟶(network)⟶receiver. – Squeamish Ossifrage Nov 09 '19 at 14:38
  • "It is silly to call this ‘integrity’ because an adversary forged the document" An integrity check does not include authentication of the sender, only that you received the information in one piece - which is partly the point of this answer. – ig-dev Nov 09 '19 at 23:01
  • That's not a meaningful distinction. In example 1, there's no authentication/integrity from the server to you _or_ from any particular adversary to you—if one adversary can forge a message then so can any other adversary, so it's silly to say there's ‘integrity’; you're really just saying that _one_ adversary's message got through _by accident_. – Squeamish Ossifrage Nov 09 '19 at 23:08
  • Or maybe you're drawing a distinction between integrity against an intelligent adversary who knows how to recompute SHA-256, _vs._ integrity against a dumb adversary like a cosmic ray who just flips bits out of anger—in which case you're not talking about integrity _vs._ authentication, but rather about intelligent adversaries _vs._ independent random bit errors in transit, and you should say that instead of abusing the terms ‘integrity’ and ‘authentication’. – Squeamish Ossifrage Nov 09 '19 at 23:10
  • "In example 1, there's no integrity from any particular adversary to you" Maybe that's where the misunderstanding lies - did you see that the example included a checksum (e.g. sha256) that was intercepted by the attacker? If you redefine that integrity is only integrity if it's coming from an authentic source, then yes, there is little distinction between integrity and authentication. – ig-dev Nov 09 '19 at 23:17
  • How do you define integrity _without_ reference to the source of the data? – Squeamish Ossifrage Nov 10 '19 at 01:15
  • @SqueamishOssifrage I did some quick research and, actually, you are right that the common definition of "integrity" precludes modification by an attacker. – ig-dev Nov 11 '19 at 07:10
0

Storage, not communication

There's a serious overlap between integrity and authentication in the context of exchanging messages, as the other answers correctly note.

However, look at the risks that apply to data in rest (not data in transit) - for a database, the authentication risks (an unauthorised user being able to read and/or write what they should not be able to) are quite separate from the integrity risks, which include all kinds of data corruption caused by accidental software bugs or hardware failures, and these risks need to be properly accounted and mitigated in rather different ways.

Peteris
  • 8,369
  • 1
  • 26
  • 35