2

This is the definition of an equivalence relation according to Wikipedia:

In mathematics, an equivalence relation is the relation that holds between two elements if and only if they are members of the same cell within a set that has been partitioned into cells such that every element of the set is a member of one and only one cell of the partition. The intersection of any two different cells is empty; the union of all the cells equals the original set. These cells are formally called equivalence classes.

My question is: In the context of security engineering, is trust an equivalence relation?

1 Answers1

5

TL;DR: No, it's not.

The definition of "equivalence relation" that I'm familiar with in mathematics is, while equivalent to yours, much simpler to use to evaluate if something is or isn't an equivalence relation. An relation ~ is an equivalence relation if and only if it is:

  • Reflexive: A ~ A for all A. In this case, it means "A trusts A." This is generally the case (it's not always the case, but people generally trust themselves to not be malicious to themselves).
  • Transitive: If A ~ B and B ~ C then A ~ C. This is sometimes true for trust, but not always. I might trust that my friend won't lie to me, but just because he trusts someone who trusts you doesn't mean I trust you at all. This is a key concern of public-key crypto, as you can't directly trust everyone's key who you want to communicate with. Trust transitivity is complicated, and doesn't really hold in full generality (hence why PGP doesn't make "trusted introducer" transitive - your trusted introducer's trusted introducer isn't automatically trusted by you). Part of the issue with the CA system for TLS is it treats trust as transitive (if you trust someone to be a CA, and they trust someone else to be a CA, your browser automatically considers the someone else a valid CA). This is very much a "maybe" then, but it certainly doesn't exist to the degree required of an equivalence relation (for an equivalence relation, if A ~ B ~ C ~ ... ~ Z, then A ~ Z; the same is not true for trust).
  • Symmetric: A ~ B if and only if B ~ A for all A,B. This is definitely not true of trust: you might well trust someone else who doesn't trust you. You implicitly trust your bank to some degree to manage money; they trust you far less (consider how much they pay you to keep your money and how much you pay them to borrow their money). You might trust Google with your data, but they aren't about to repay the favor.

(Your definition is equivalent to this: A ~ B if and only if A and B are in the same equivalence class. The definition I used is used to show something is an equivalence relation, because it's nice to work with that way. Once you've shown something is an equivalence relation, then you break out your definition and divide some set into equivalence classes using it.)

Lastly, there's a technical requirement that trust doesn't satisfy:

  • Excluded middle: For an equivalence relation (in fact, for the more general class of binary relation), either A ~ B or !(A ~ B). There is no middle ground. This is certainly not true of trust: You trust different people different amounts; you might trust your spouse completely, trust a friend for the most part, and trust a drinking buddy only a little bit. So trust isn't really even in the class of things that can be an equivalence relation. The problem of transitivity is partly due to this -- transitivity means if A ~ B and B ~ C then A ~ C, and does not allow A to only sort of ~ C. You might trust a friend of a friend, but less than you'd trust that friend; at 10 degrees of separation, there's basically no trust left over.

So trust not only doesn't fulfill the technical requirements to be conceivably an equivalence relation, it doesn't fulfill two of the substantive requirements (it's not really transitive within the meaning of an equivalence relation, and certainly isn't symmetric).

cpast
  • 7,413
  • 1
  • 31
  • 35