Papers

1. Secure Privacy, Authenticity, and Confidentiality (SPAC)
2. PAC Trilemma
3. Privacy and Confidentiality
4. Privacy as Protection Against Exploitation
5. Effective Privacy
6. Cold War versus Hot War
7. Three-Party Exploitation Model
8. Exploiters
9. Identity Theft: Threats and Mitigations.
10. Threats
11. Mitigations
12. Aggregation: Threats and Mitigations
13. Summary Threats and Mitigations
14. Unbounded-Term AIDs instead of Long-Term Public Keys
15. End-Verifiabilty and End-Only-Viewability
16. Adoptabllity via Dumb Crypto
17. Best Authenticity (Public Key Signing)
18. Best Confidentiality (Public Key Encryption)
19. Best Combined Authenticity and Confidentiality
20. Modified ESSR a. Baseline KERI ESSR B. Plaintext Sourceless Variant v. Sourceless Variant
21. Destinationless Variant
22. Replay Attack Protection
23. KERI ESSR Summary
24. Relationships
25. Basics
26. Relationship Graphs
27. Syntax
28. AIDs
29. Signatures
30. Ciphertext
31. Messages
32. Header
33. Transport (IP) Addresses and Header
34. 00B Setup
35. Baseline Protocols.
36. Direct
37. Direct Protocol as Wrapper
38. Relationship Formation Protocol
39. One Shared Intermediary
40. Non-Shared Intermediaries a. First hop from A to C: B. Next hop from C to D: V. Last hop from D to B

41. Discussion

42. Interaction Non-Content Metadata 01.iSAIDs as lIDs

43. Privacy by Isolating Interaction Contexts
44. Interaction Context Syntax
45. Cross Relationship Context Interaction Contexts
46. Shorthand Notation
47. Three-Level Nested Protocol a. First Hop B. Next Hop v. Last hop
48. Combined Source Vector and Table Routing as Dead Drop
49. Multi-sig Extension
50. Sustainable Privacy, Authenticity, and Confidentiality a. Time Value of Information B. Sustainable Management of Contexts . Re-ldentification
51. Contextual Linkability Re-identification Attack
52. Relationship Discovery Protocols 21.CESR
53. Appendix DDOS
54. DDOS Protection Efficiency
55. Security-by-obscurity
56. Amplification Attacks
57. Appendix: Using Crypto in a way that is Too-Clever-By-Half
58. Appendix: 1st Party Non-Viewability Secure Privacy, Authenticity, and Confidentiality (SPAC) The Best Privacy Possible Given the Strongest Authenticity and Confidentiality Version 0.4.5 (Original draft 2023/03/25) Copyright 2023 Samuel M. Smith PAC Trilemma In my opinion, the three properties, authenticity, confidentiality, and privacy inhabit a trade space. | have posited the PAC Theorem or PAC Trilemma to qualify this trade space. The PAC theorem/trilemma states: One can have any two of the three (privacy, authenticity, confidentiality) at the highest level but not all three. The trilemma insists that one must make a trade-off by prioritizing one or two properties over a third.

The TolP design goals reflect that trade-off and provide an order of importance. The design goals indicate that one should start with high authenticity, then high confidentiality, and then as high as possible privacy, given there is no trade-off concerning the other two. The properties are defined as follows: Concerning the first design goal, establishing trust between parties requires that each party develop confidence in the following properties of their relationship: 1. Authenticity: is the receiver of a communication able to verify that it originated from the sender and has not been tampered with? 2. Confidentiality: are the contents of a communication protected so that only authorized parties have access? 3. Privacy: will the expectations of each party with respect to the usage of shared information be honored by the other parties? Note that, in some trust relationships, confidentiality and privacy may be optional. Thus our design goal with the TolP stack is to achieve these three properties in the order listed. The prioritization of authenticity first, confidentiality second, and privacy third does not mean that when constructing a message, the order of layering of mechanisms in the message that contribute to authenticity, confidentiality, and privacy protection must or should follow that same order. Indeed, it may be best in some protocols if they don't share the same ordering. To be clear, the ordering of the TolP design goals w.rt. authenticity, confidentiality, and privacy may be different from the ordering of layers that employ these three in a given protocol. This distinction, | believe, is a source of much confusion in prior discussions and one of the reasons | provided the overlay spiral diagrams. The purpose of the overlay spiral is to illustrate that multiple layerings of authenticity, confidentiality, and privacy protection mechanisms may appear in different orders, both in-band (1B) and out-of-band (OOB), with respect to the setup for and the eventual transmission of a message over a given communication channel or channels.

Authenticity [ src ) __/ ] r(s) 00B Setup 1BTX BTX o = / N\ = % dst | — ]

N\ = < ~T =4 ) Z itr(s) | 1B Setup Privacy Layered Security Overlay Spiral SecurityOverlaySpiral Diagram: Security Overlay Spiral From a practical perspective, | use the following elaborations to help refine how | think about the three properties + Authentic and Authenticity: The origin and content of any statement by a party to a conversation are provable to any other party. Authenticity is primarily about control over the key state needed to prove who said what in the conversation via digital signatures. In other words, it is about secure attribution. + Confidential and Confidentiality:

All statements in a conversation are only known by the parties to that conversation.

Confidentiality is primarily about control over the disclosure of what (content data) was said in the

conversation and to whom it was said (partitioning). Confidentiality is about control over the key state

needed to hide content via encryption vis-a-vis the intended parties.

« Private and Privacy:

The parties to a conversation are only known by the parties to that conversation.

Privacy is primarily about control over the disclosure of who participated in the conversation (non-

content meta-data = identifiers). More specifically, privacy is about managing exploitably correlatable

identifiers, not merely identifiers of who but also any other type of identifier in non-content metadata,

including conversation (interaction) identifiers. Privacy and Confidentiality There are also two fundamentally different but complementary definitions of privacy that are relevant to protocol design. The first (TolP) definition is about the receiver respecting the data privacy concerns of the sender with respect to the content disclosed to the receiver. The protection of sender data privacy is a responsibility placed on the receiver. The receiver protects the data privacy rights of the sender once the receiver has received that data. This first type of privacy protection may be achieved independently of how private the communications channel was that resulted in the receiver obtaining the disclosure of the content. The second definition is about the correlatability of the publically viewable metadata included in the ccommunication. This is called non-content meta-data by the surveillance community. This definition distinguishes between confidential data (meta-data or otherwise) that is not publicly viewable, where public means any third party not a party to the conversation. Typically confidentiality protection comes from encryption (i.e., cipher text vs. plain text). But an out-of-band (OOB) exchange of information is confidential (not viewable) by a third-party surveillor of an in-band (IB) channel, thus making the OOB exchange confidential without encryption. The terms, confidential and private, also have distinct legal definitions. The legal definition of confidentiality, however, is consistent with the surveillance definition above as well as the definition used by the TolP properties above. Confidentiality law is about contractual agreements governing the disclosure of data by o

ne party to another. The legal definition of privacy, on the other hand, is not so consistent. The regulatory surveillance law definition is different from the regulatory privacy rights law definition. The former is about drawing the line between non-content metadata and content data in order to be classified as searchable or not (see content-metadata-line, It's Too Complicated, Expectation of Privacy, and surveillance) and the latter is mainly about protecting personal data rights by data holders, controllers, and processors (see GDPR). We. could call the former surveillance (correlation) privacy and the latter data-rights privacy. Of interest is the fact that confidentiality law can be used better to protect personal data rights. For example, the well-known concept called chain-link confidentiality, circa 2012, details how one can protect the data privacy concerns of the sender via contractual confidentiality law. ACDCs ACDC Spec, for example, use the

well-known Riccardian Contract formalism, circa 1996, to support chain-link-confidential through what is called contractually protected disclosure. What this paper also demonstrates is that nested confidential contexts can also be used to better protect surveillance (correlation) privacy. To summarize: * Physical Search: (analogy to Constitutionally protected physical search) Inside of home vs. Outside of home (see Curtilage vs. Open Field). The address is a public identifier used for routing and taxing. Viewing who enters the home from outside via public street is unprotected. (subpoena) Viewing what happens behind closed doors inside the home is protected. (warrant) « Information Search: Relatively weak legal protection (subpoena) for identifiers, (non-content meta-data) because identifiers are needed for public routing and billing. Relatively strong legal protection (warrant) for content because the content is not needed for public routing and billing. But for the purposes of protacol design the definitions of confidentiality and privacy that are most suitable are the surveillance definitions. To clarify, privacy is about the leakage of exploitably correlatable metadata about the parties to the conversation and confidentiality is about restricting the viewability of the content of the conversation to the intended parties to the conversation. In simple terms, privacy is about protecting the knowledge of who is a party to a given conversation and confidentiality is about protecting the knowledge of what was said in that conversation. The surveillance distinction between privacy and confidentiality has a very practical basis. Recall that for the purpose of protocol design, we defined privacy as protecting knowledge about the parties to a conversation (exchange of data). A primary use case for identifiers in communication protocols is to address the parties to the conversation. Indeed the practical need for identifiers to support addressing often makes the privacy protection of knowledge of identifiers as metadata to conversations particularly (in many cases pathologically) difficult. Historically, an address of any kind (including the original postal address) exists for two main purposes. 1. So that stuff can get routed (delivered) to that address as a destination via public roads. 2. So that legitimate parties can tax or bill efficiently other parties at any or all addresses. In the electronic communication world, the same applies. Addresses need to be pu

blic so that communications can be routed to destinations over multiple disparately owned, controlled, and regulated communications infrastructures (largely public-regulated monopolies). Likewise, the main mechanism for billing for communication services rendered is address based. So addresses have to be public, not confidential, not only 50 that stuff can get routed to those addresses but also so they can be the destination for bills to pay for the communication itself. So pragmatically, the legal surveillance world respects that these two purposes (routing and billing) require identifiers (addresses) that must need be public and eaves-droppable.

This is merely a logical, practical extension of property rights w.r.t. unreasonable search. The right to be protected from search only extends to what is not viewable behind closed doors. Anything viewable from a public street is fair game with no protection. Likewise to some extent an automobile or delivery van. What's locked in the trunk or the back of the van (unless it's making noise hearable by a bystander) may be protected. Where it goes on a public street is not protected, and its license plate is a publically viewable address proxy. As a result, both practically and legally, all routing and billing mechanisms assume to a large degree that addresses are not private. Anyone trying to build a house and then telling the post office, that it can't assign them a public address, or expecting that anyone will build infrastructure to support getting stuff delivered but not using public streets will likely fail. Imagine the cost of supplanting public streets with a totally private conveyance system (air-space, sea-space, and space-space are public already). If one wanted to build a totally private alternative to the public road network then maybe automobiles and vans on private roads wouldn't need license plates (oh wait these are called toll roads, and they need a billing address) so not.

So the analogy holds. We can have strong authenticity and strong confidentiality (of anything but addresses) but weaker privacy w.r.t addresses (identifiers). Beyond a certain point, better privacy over addresses becomes impractical because the world needs addresses for routing and billing on public infrastructure and will always need them. So privacy, as non-correlatable identifiers (metadata) will always be difficult. Whereas, privacy as control over one's data rights is easier because it's not about routing or billing. But we don't have to give up completely on privacy as non-correlatable identifiers if we better qualify it to be privacy as protection against the exploitation of correlatable identifiers (metadata). In simple terms, the goal becomes limiting the exploitation via exploitably correlatable identifiers.

Privacy as Protection Against Exploitation

Effective Privacy

To better manage this difficult trade-off between the need to address the parties to a conversation and the need to restrict the disclosure of knowledge of those parties to the parties themselves (i.e., privacy) we focus our attention on managing exploitably correlatable non-content metadata, s

pecifically exploitably correlatable identifiers. Thus if we can protect against exploitation derived from the correlation of identifiers we may achieve effective privacy.

Protection against exploitation via correlation provides a more gentle trade space than mere protection against correlation. The former is practical and amenable to cost-benefit analysis, but the latter is largely impractical. Let's return to our public road delivery analogy. We can achieve effective privacy over public roads if we use a delivery service. The delivery service uses public roads, but the contents of the delivery vans are not viewable by bystanders (third-party observers). Although a bystander can see the van enter and leave our property they can't see the boxes the van delivered or picked up from our property. The van has a public address (its license plate). The boxes the van picks up or delivers all have public addresses. But the addresses on the boxes and the contents of the boxes are not viewable by the bystander. The van makes stops at many houses in the neighborhood which provides herd privacy with respect to correlating van deliveries and pickups to boxes.

Analogously the contents of the van may be considered content whereas the van itself is non-content metadata. The van provides a virtual private delivery network over public roads. The closest analogy in the communication world is a Virtual Private Network, (VPN). The limitation is that we have to trust the delivery driver of the van not to tell our neighbors the address information on the boxes delivered or picked up from our address. The driver can't tell what's in the boxes, merely who they came from or who they are being sent to. Let's extend the delivery driver analogy. Suppose that a malicious adversary replaced the driver with one of its own so that it could view all the addresses of all the boxes inside that delivery van and maybe even open the boxes to view their contents. Now any trust in the delivery van service is broken because of the malicious impersonation of the delivery van driver. We must be careful not to mistake this as a privacy problem but to see it as an authenticity and confidentiality problem. If the delivery van driver is not impersonatable because any entity at any pickup address can securely authenticate the driver then the adversary will not be able to pick up boxes much less view their addresses or contents. The exploitability of the public addresses on the boxes is derived from the exploitability of the delivery service's authenticity and confidentiality, not the inherent correlatability of the boxes' public addresses.

At first blush, it seems that the solution to protecting address privacy is not a private road network but un- impersonatable delivery van drivers with really secure delivery vans and really secure boxes inside the delivery vans. We would be better off building more secure more trustworthy delivery services (VPNs) that use public roads than building something more complicated and harder to adopt like replacing public roads with private roads (distributed private communication networks). For example, the WireGuard VPN protocol is a best practices VPN from the standpoint of modern pre-quantum security with a path to post-quantum security. It is open source and uses libsodium constructs. We should not reinvent that wheel.

Cold War versus Hot War

In a strong sense, given the definitions above, authenticity and confidentiality protection are in a different class or regime from privacy protection.

Authenticity and confidentiality are like a cold war. Authenticity overlays based on public key digital signatures pr

ovide arbitrarily strong protection with minimal resources. Likewise, confidentiality overlays based on public key encryption provide arbitrarily strong protection with minimal resources. To reiterate, the reason authenticity and confidentiality are analogous to a cold war is that we have existing tooling that enables cost-effective cryptographic strength authenticity (as in end-verifiable attributability to an AID) via digital signatures and cost-effective cryptographic strength confidentiality (as in secure end only viewability by an AID) via asymmetric en-de-cryption. This strength is such that attack is computationally infeasible against the crypto and the only weakness is in the strength of the key management of the associated key pairs. So there need be no casualties in this cold war. The only looming vulnerability is that a secret weapon might be developed (aka a quantum computer) which would break the existing crypto. But given that we now have quantum-safe, signatures and asymmetric encryption, as long as the key management system is sufficiently agile and post- quantum proof (like KERI), it will remain a cold war because one just switches to the quantum-safe crypto once someone has built a quantum computer capable of breaking the existing crypto.

In comparison, privacy is like a hot war. Rapidly evolving tactics and technology make privacy protection like a resource-constrained war of attrition against vastly superior opponents. We have to be careful because decreasing the privacy attack surface may actually increase the net total harm due to lost value capture opportunities. To reiterate, the reason privacy (as exploitable correlatability of identifiers) is a hot war is that casualties are unavoidable. The strategy, tactics, techniques, resources, and incentives to expend those resources for correlation are a function of the particular adversary. So the protection tactics and strategy are specific to the type of adversary. It becomes more about minimizing the casualties and the expended resources 50 as not to lose the war.

Suppose we want to build a communications channel that is not exploitable via correlation of the identifiers. Because the communications must be routed between end-points, all of the routing identifiers, the routing tables, and every intermediary are all attack surfaces for correlation. The receiver and sender are each themselves an attack surface for correlation independent of the channel.

The channel defines the boundary between in-band and out-of-band. For some adversaries even out-of-band mechanisms are correlatable. So if our protection must account for any and all correlation mechanisms from any and all types of adversaries including those with virtually unlimited resources to correlate both in-band and out-of-band then there is no practical solution to the privacy protection problem. One can always play the equivalent of a trump card that says, here is a way some adversary given enough resources can correlate, and 50 the protocol is broken in terms of privacy. This is why the qualifier exploitable correlatability is used. The type and degree of exploitability depend on the adversary.

As a result, we must make risk mitigation trade-offs between exploitable harm and protection cost by focusing on the exploitable correlatability of identifiers used to convey information over a communications channel. Let's use a related war analogy, suppose one is designing a tank and needs to select the thickness of the tank's armor. One can't determine the armor thickness needed until and unless they scope the types of attacks that the tank must be able to withstand. If one of the allowed attacks is a nuclear bomb, then the tank designer has an impossible trade-off because a tank by def

inition is a type of mobile artilery. Therefore, any armor thick enough to protect against a nuclear bomb would be too heavy to move.

In the hot war of privacy, we have to Pareto optimize protection mechanisms. Notwithstanding the limited resources at our disposal, we can still protect against many types of attacks from many types of adversaries but not all attacks from all adversaries.

One way to approach this is to use a risk mitigation rating and ranking process. I critical systems, one standard process rates and ranks risks by quantifying the magnitude of the harm for a given risk and then multiplies it by the likelihood of the harm. Risks with high harm and high likelihood are ranked ahead of risks with high harm but a lower likelihood.

A cost-benefit analysis is then performed on the relative cost of any mitigation measures as a percentage of all available resources to mitigate all harms from all risks. A comet striking the earth, for example, might have very very high harm but its likelihood is so small and the cost of mitigation so high that it's not a risk worth mitigating

In any resource-constrained decision problem, we have to make trade-offs, and we need to understand the trade space well if we want to make optimized trade-offs. In a later section, we will discuss threats and mitigations to better understand that trade space.

On the other hand, in the cold war of authenticity and confidentiality, even with limited resources, we can protect against almost all attacks from all adversaries. In the next section, we will detail specifically what the strongest practical authenticity and confidentiality protection looks like.

Three-Party Exploitation Model

For this analysis, we use the three-party disclosure and correlation exploitation model. The 1st and 2nd parties represent the parties to a conversation or exchange. The 1st party discloses data to a 2nd party. The 1st and 2nd parties have knowledge of each other via their identifiers. The 1st party as discloser has knowledge of the disclosed data (content). As a result of the disclosure the 2nd party as disclosee also has knowledge of the disclosed data (content). The identifiers are non-content meta-data, and the disclosed data is content data. A 3rd party is any party that is not either a 1st or 2nd party. An intermediary may be considered a 1st, 2nd, or 3rd party depending on how and by whom it is trusted or not.

Privacy with respect to the 3rd party is protected if the 3rd party has no knowledge of the identifiers used by the 1st and 2nd parties for the conversation (disclosure). Confidentiality with respect to the 3rd party is protected if the 3rd party has no knowledge of the disclosed data (the content data disclosed). A 3rd party may directly break privacy by observing messages that contain the identifiers of the 1st and 2nd parties. A 3rd party may directly break confidentiality by observing the content of messages between the 1st and 2nd parties. In addition, the 3rd party may indirectly break both privacy and confidentiality by collusion with the 1st or 2nd party or via collusion with an intermediary. This is diagrammed below.

intermediary o) V third party first party 4# second party first party second party support support

ExploitationModel

Diagram: Three Party Exploitation Model

Exploiters

The three main classes of potential exploiters are as follows:

1. State Actors (3rd party) The primary incentives for state actors are political, but some like North Korea are also monetary. North Korea i responsible for a significant percentage of ransomware attacks (see NK Ransomware, NK Success). State actors may use any combination of attacks to surveil, regulate, and persecute all first parties, second parties, and intermediaries with virtually unlimited resources and the ability to cause harm. Because of the virtually unlimited resources and techniques that state actors can apply we will treat them as out of scope for mitigation for the time being. That does not mean we will not consider state-actor resistant mitigations but to attempt state-actor proof mitigations would likely take us down rabbit holes that we can never return from.
2. Identity Thieves (3rd party):

The primary incentive for identity thieves is monetization through asset theft. Typically either directly through the capture of access credentials to assets or indirectly through the sale of personally identifying information (PII) that may be used to capture access credentials. Another primary monetization strategy is ransomware of either access credentials or Pll that may be used to capture access credentials or simply sensitive PIl such as health data.

1. Aggregators (3rd party, 2nd party, 1st party): The primary incentive for aggregators is to sell data to advertisers. This means profiling groups of potential customers in attractive demographics. This profiling may be entirely statistical. There are several classes of aggregators. These include: o Intermediaries (3rd party): = Search as an aggregator = Cloud provider as an aggregator = ISP as an aggregator o Platforms (2nd party) » Colluding 2nd parties as aggregators o Inadvertent (1st party) = Inadvertent colluding 1st party as an aggregator via web cookies Identity Theft: Threats and Mitigations Threats For this analysis, we assume that content data is confidentially encrypted between 1st parties and 2nd parties when sent over the wire. The identity thief cannot view this data without first compromising st party or 2nd party credentials in order to either decrypt the data or view it in its unencrypted state on a storage device. The ultimate target is a treasure trove of sensitive data held by a 2nd party. This may be health or other data that may be captured as ransomware, or it may be credentialing information that enables first-party impersonation in order to either directly capture st party assets or may be sold to secondary thieves who then use it to capture st party assets. Another target is the asset access credentials of high-value 1st parties. Notable is that identity thieves do not monetize aggregated content data or metadata (anonymized or not) by selling it to advertisers. The return on investment for data aggregation is too low for identity thieves in general. The primary attack mechanism is labeled differently in different venues but may be described as a multi-step recursive privilege escalation attack (authentication and authorization) Priviledge Escalation, Priviledge Escalation Attack. Simply stated, in a privilege escalation attack, the attacker compromises weak access credentials on low-value targets that allow it to escalate its privileges in order to compromise a higher-value target until it finally has the access credentials of a treasure trove. An example of this would be to compromise the VPN login of some customer or employee of some company that allows an attacker to compromise some other employee's VPN login to a connected company and so on until it captures access credentials to a connected company's treasure trove. It starts with what is called an edge attack on the weakest company. The escalation mechanism often leverage

s what is called a BOLA or BUA vulnerability in the access API of a given company. These vulnerabilities singularly or in combination allow an adversary to escalate their access privileges (see BOLA Explained. The OWASP project lists in order the primary API vulnerabilities that enable a recursive privilege escalation attack. These are not privacy weaknesses but authentication-based authorization weaknesses.

This is described thusly: Hackers can use data stolen from companies with weak security to target employees and systems at other companies, including those with strong security protocols. ... the data ecosystem has become so vast and interconnected that people are only as safe as the least secure company that interacts with any company that has access to their data. That “least secure company” does not even need to have access to the consumer’s data. ... There were 5,212 confirmed breaches in 2021, which exposed 1.1 billion personal records across the globe” (see data security) To summarize, a given trust domain is only as strong as the weakest connected trust domain (in which connected is recursively applied). A recursive privilege escalation attack usually starts with a 2nd party impersonation using phishing or smishing to steal 1st party credentials by spoofing an impersonated 2nd party. Now that the attacker has 1st party access they can leverage that to discover other Ist parties that have access to higher value connected clients, then rinse and repeat. A related escalation attack is to attack a weak intermediary which may be used to stage a more sophisticated 2nd party impersonation attack. The classic DNS hijack is such an example. An adversary hijacks (using cache poisoning or some other mechanism) the DNS server of some 2nd party. The adversary then requests a new DNS certificate from a CA. The CA verifies control of that DNS domain by querying the DNS Zone file for the impersonated 2nd party secret provided for authentication. The hijacked DNS returns the secret thereby fooling the CA into issuing a valid certificate to the adversary. The adversary then hijacks the DNS server of a first party so that when they go to login to the 2nd party host they are redirected to a host under the control of the adversary. The 1st party verifies the valid DNS credential miss-issued to the adversary and then logs in thereby allowing the adversary to steal the 1st party credentials. The adversary then logs into the 2nd party host with 1st party access. This can be repeated. A related attack is to first compromise an intermediary using either a direct or combined attack and then leverage the surveillance of first-party to second-party traffic via the now compromised intermediary to mount attacks on the second-party in order to escalate to first-party credentials. A more sophisticated attack is a code supply chain (intermediary) attack that creates a back door to c

apture first-party credentials. Mitigations + Use strong authentication by 2nd parties of any first party at any step along a multi-step recursive privilege escalation attack. In any multistep recursive privilege escalation attack any step that has strong authentication with individually signed requests for authorization will stop the attack from proceeding. + Use strong authentication by any 2nd party of any 1st party for any exploitable use of first-party credentials, whether those credentials be credit card, bank account, or access to sensitive data. + Use strong authentication (zero-trust data in motion and at rest) at any party holding a treasure trove. Strong authentication is also state-actor resistant. + Getrid of treasure troves of access credentials by using decentralized trust domains (DPKI). This means: passwordless security with strong key rotation mechanisms. This is also state actor resistant.

Aggregation: Threats and Mitigations For this analysis, we assume that content data is confidentially encrypted between 1st parties and 2nd parties when sent over the wire. The aggregator must either merely aggregate the correlatable information contained in the non-content meta-data such as identifiers or must be a 2nd or 1st party with access to st party data. The aggregator needs voluminous data in order to provide sufficient monetization via advertising. This means attacks to compromise 1st or 2nd party credentials are too costly given the amount of data captured by such attacks. Moreover, advertisers generally are legitimate companies ‘that would incur a huge legal liability should they engage in direct attacks on 1st party credentials. Their primary mode of operation is to incentivize first parties to disclose exploitable information either simply as. correlatable metadata or as content data. Typically, data may be anonymized and then re-correlated to demographic pool sizes appropriate for advertising campaigns. As mentioned above there are several classes of aggregators each with a different exploit mechanism. + Intermediaries as Aggregators i. Search as an intermediary (3rd party). In this case, an internet search engine is able to track the click-throughs of a successful search result. This enables the search engine to monetize the 1st party searcher by correlating the meta- data of the incoming client browser with the 2nd party endpoint resulting from the search. + Mechanisms: = 1st party permissioned surveillance of first party metadata collected by 3rd party search intermediary and sold to other 3rd parties + Mitigations: = Use VPN in combination with a partitioned 1st party identifier such as a random email address = Use a search engine that contractually protects 1st party search metadata. ii. Cloud data storage provider as an intermediary (3rd party). In this case, all 1st party content data stored in the cloud may be anonymized and re-correlated to provide monetizable advertising campaign pools. + Mechanisms: = First-party permissioned surveillance of first-party content data by 3rd party cloud provider intermediary and sold to other 3rd parties. + Mitigations: = Use cloud storage providers that use end-to-end encryption (first-party confidential content data) = Use cloud storage providers that contractually protect 1st party content data. iii. Internet Service Provider (ISP) as an intermediary (3rd party). In this case, ISP has access to a

ll traffic routed through it for 1st party client connections to any 2nd party. ISP can anonymize and then re-correlate into monetizable advertising campaign pools. = Mechanisms: = Non-content Metadata (routing and billing) identifiers. In the USA for example any anonymized data (both metadata & content) is aggregation permissible for any ISP. = Mobile device location tracking.

» Mitigations:

= Use an ISP that contractually protects user metadata

= Use VPN that contractually protects user metadata. A VPN provides herd privacy relative to ISP tracking of the source to 2nd party destinations.

= There s no mitigation for mobile device tracking by mobile service providers except to turn off the mobile device.

= Use distributed decentralized confidential network overlay to make metadata harder to correlate. This could include onion or mix network routing such as TOR, Elixxir, MainFrame, and DIDComm Routing. In general, a decentralized network overlay is difficult to incentivize and as a result, may have relatively low adoptability when compared to a VPN,

= Use information-theoretic secure routing. An example would be random walk routing Of all the mitigations, this one is state actor resistant. Information-theoretic secure routing, however, has similar adoptability problems as a decentralized confidential network overlay.

iv. Platform as an aggregator (2nd party). In this case, the platform is a 2nd party with access to all the st party data disclosed to it. This includes both non-content metadata and content data. The platform anonymizes the data and re- correlates it into monetizable pools for advertising on the platform itself. A related approach is for smaller 2nd parties to collect their data and sell it to 3rd party data aggregators, who then package it for 3rd party advertisers. Statistical techniques like regression enable monetizable aggregation even with weakly correlatable data given enough 2nd party data. (see 1st party data correlation), Oth party data

• Mechanisms:

• First-party permissioned content data and non-content metadata are anonymized and then statistically regressed to form monetizable advertising campaign pools. Even ‘anonymized 1st party data without correlatable identifiers have sufficient exploitable correlatabilty for monetization. Privacy-protected metadata (identifiers) are insufficient to protect against exploitation. Data anonymization is not protective (fallacy of K- Anonymity)

• Mitigations:

• Don'tinteract with 2nd parties that aggregate without permission.

• Interact only using contractually protected disclosure alone o in combination with contingent or selective disclosure.

v. Inadvertent 1st party as aggregator (st party, 2nd party, 3rd party). In this case, the Tst party uses web browser cookies or other permissioned mechanisms that make the st party itself the tracker that may be ex

ploited by either 2nd parties or 3rd parties that may glean data from the tracking mechanisms. The data is typically metadata but may also be content data depending on the invasiveness of the cookies. - Mechanisms:

• Browser cookies make first-party browsers an inadvertent permissioned intermediary that can leak both non-content metadata and content data to 2nd parties andjor 3rd party intermediaries. This enables those parties to aggregate st party data and

monetize it for advertising campaigns. » Mitigations: = Don't use browsers in a way that supports tracking first-party data via cookies by 2nd parties or 3rd party intermediaries. All the major browsers now support a type of incognito mode that prevents the use of cookies for tracking. Most 2nd party websites support disabling most cookie-based tracking. = Use browsers that contractually protect st party data and anonymize the st party source identifiers. = Use VPNs that contractually protect 1st party data and anonymize the 1st party source identifiers. Summary Threats and Mitigations As the analysis above shows the most fruitful application of TSP-based protocols with regards to exploitably correlatable identifiers may be in improving VPN to limit aggregation for advertising by 3rd parties or in providing TSP-based protocols that enable VPN like trusted intermediaries for herd privacy against 3rd party aggregators. Whereas protection from 2nd party aggregators may be best provided by higher layer protocols that provide contractually protected disclosure of 1st party data to 2nd parties. Finally, protection from identity theft may be best provided with TSP-based protocols that provide strong authenticity and confidentiality independent of correlatable identifiers. Proper full zero-trust (verify everything) approaches with cryptographic roots-of-trust for authentication, and authorization simplifies API design and may mitigate the most common vulnerabilities (including BOLA and BUA). Unbounded-Term AIDs instead of Long-Term Public Keys KERI AIDs (autonomic identifiers) have a novel and unique feature called persistent controllability. With KERI the controlling key pairs of an AID may change via rotation o in other words the control is transferable to a new set of controlling key pairs. This enables the controller to maintain persistent control over the AID in spite of the compromise of the controlling key pairs. Specifically, the KERI pre-rotation mechanism uses one-time pre- rotated rotation keys to recover control of the AID by transferring that control to a new un-compromised set of key pairs. Because the pre-rotated keys are not exposed they are much harder to attack. At inception, a persistable (transferable) AID makes a forward commitment to the rotation key pairs via cryptographic digests of the public keys. These keys are never used until and unless there is a rotation. Only the pre-rotated keys will verify against their digests. With each rotation

, a forward commitment is made to a new set of one-time-only pre-rotated keys thereby always staying one step ahead of an attacker. KERI's pre-rotation may be characterized as what many in the academic literature now label a meta- cryptographic system. KERI itself only uses well-established cryptographic operations, like digests and digital signatures but uses them within a system that provides useful features like transferable or persistent control over an identifier.

Many public key cryptographic algorithms employ the concept of fong-term public keys and short-term public keys. Often long-term keys have less exposure than short-term keys so they can maintain their cryptographic strength longer. Typically this is to better manage the friction of key exchange where higher friction authentication of long-term keys is used to enable or bootstrap cryptographic operations using short-term or ephemeral keys.

A long-term public key is often used as the primary identifier for a party in an interaction or exchange. With this usage the long-term public key may be called the address of the party. The problematic limitation of using long-term public keys as party identifiers (addresses) is that the public key is only long-term not unbounded- term. Eventually, any long-term public key must be abandoned due to exposure. NIST recommends that public authentication keys have a cryptoperiod (time before key must be replaced) of no more than 1 to 2 years. This means that any authentication or reputation associated with a public key (address) by a relying party (a public key as an identifier for a given party) must also be abandoned. This forces the two parties to start over by re- authenticating or re-registering a new public key as a replacement address or identifier. Moreover, there is no inherent way for a relying party to know that some other party has abandoned its public key as an identifier. This exposes the two parties to attacks that exploit this uncertainty via the use of stale public keys andjor attacks on the re-registration process.

This is one of the reasons why we consider key rotation the hard problem of key management. KERI solves the hard problem of key rotation using key pre-rotation in combination with a cryptographically verifiable append- only data structure based on a cryptographic root of trust that provides proof of key state for any persistable (transferable) AID. This data structure is called a Key Event Log (KEL). A controller publishes its current key state via its KEL, thereby enabling any relying party to verify the current state and also to detect when a key has been rotated (abandoned). Stale usage of compromised keys by adversaries is thereby detectable. Pre- rotation protects the re-registration process. Identifiers (addresses) therefore maintain their reputation in spite of key rotations. Indeed transactions can be securely bound to the key state by anchoring them in the KEL Another significant advant

age of using unbounded-term AIDs instead of long-term public keys is post-quantum safe cryptographic agility. KERIs pre-rotation mechanism is post-quantum safe because cryptographic strength digests such as Blake3, Blake2b, and Sha3 are also strong against quantum attack Hash Collisions. This means that pre-rotated keys are protected from quantum attack exposure and inversion by their digests. This provides sufficient cryptographic agility to be able to rotate to post-quantum safe digital signatures and public keys. This makes the pre-rotated keys safe from surprise quantum attacks. In contrast, long-term public keys as identifiers are vulnerable to surprise quantum attacks.

With KER, AIDs as primary identifiers may be valid for an unbounded-term instead of merely long-term. This changes the way meta-cryptographic operations that provide authenticity and confidentiality may be expressed. In the following development, in many cases, where a long-term public key would normally be used, we may use an AID with unbounded-term instead. Given the AID, its latest public key may be looked up from its KEL. This applies to both signing public keys and encrypting public keys. Moreover, with certain caveats, the encrypting public key may be cryptographically derived from the signing public key so only the signing public key needs to be managed in the KEL.

Using an unbounded-term AID with a KEL solves the problem of the un-detectability of abandoned long-term public keys. If the provided message is using stale keys for a given AID the associated cryptographic operations will fail against the current key state, and the relying party can drop the message. Likewise, when the controller updates its key state and uses new keys in a message, but the relying party has a stale copy of the KEL, the associated cryptographic operations will also fail, which indicates to the relying party the need to update its copy of the key state. The controller can also send a hint of its current key state along with any message. One simplification that results from this approach is that many protocols can be simplified to remove repeated setups using ephemeral (short-term) keys whose purpose is to reduce the exposure of the long-term keys. End-Verifiabilty and End-Only-Viewability One of the key principles to building secure systems is to minimize the number of different attack vulnerabilities and for those that remain make them as invulnerable as is practically possible. The approach that KERI takes is o minimize the attack vulnerabilities to key management and nothing else and then to make that key management as strong as possible. The principle makes it so that in any exchange of data (communication): + If the edges (ends) are secure, then the security of the middle doesn't matter. The corollary to that is that: « It's much easier to protect one's private keys than to protect all internet infrastructure. This is shown in the following diagram: o Midde - G el ) | Middle b +[ Middle . - - — ~ @ g data /“" — [ e T TMidde +—aua—+ Midde > ——don——+| End ™ . h — — h wa T Middie b G Middle »

End2EndNetwork Diagram: End-to-End Network For authenticity, the way to remove vulnerabilities in the middle is called end-to-end verifiabilty of authenticity or end-verifiability for short. This naturally leads to what we call ambient verifiability where any-data can be verified any-where, any-time by any-body. There is a dual property for confidentiality. For confidentiality, the way to remove vulnerabilities in the middle is called only-at-end viewability for confidentiality or end-only viewability for short. This naturally leads to the concept that anyone’s confidential

data is only viewable one-where, one-time by one-other-body. Together these properties mean we only have to secure key management at the ends (edges) not everywhere in between. Insisting on these principles greatly simplifies and strengthens any protocols we may choose to build. To reiterate, a confidentiality overlay is the dual of an authenticity overlay. An end-verifiable authenticity overlay is based on one or more asymmetric key pairs for signing, where only the end with the private key can sign, and any end with the public key can verify. To clarify, only the key pair controller can sign with the private key, any recipient can verify with the public key. An end-only-viewable confidentiality overlay is based on one asymmetric key pair for en-de-cryption, where any end with the public key can encrypt, and only the end with the private key can decrypt. To clarify, only the key pair controller can decrypt with the private key, any sender can encrypt with the public key. Any identifier can have a key state that includes both an asymmetric signing key pair and an asymmetric decryption key pair. Either the key pairs can be the same, or the decryption key pair can be derived from the signing key pair Thus an efficient approach is one where only one key state, the signing key state, needs to be maintained (with caveats). Given the identifier and the security overlay's mapping to look up key state, any other party, can either verify with the signing public key that a message was non-repudiably sourced by the controller of the identifier (authenticity) (non-repudiable any-end-verifiable ) or can encrypt a message using the encryption public key to ensure that only the controller of the identifier can view it (confidentiality) (restricted only-end-viewable) To analyze confidentiality we use a 3-party model where the 1st party is the sender, the 2nd party is the intended receiver, and the 3rd party is any unintended receiver. A system with strong end-only viewable confidentiality may have the following properties:

« 3rd party non-viewability

« 1st party non-viewability (this protects 1st party from liability wrt to 2nd party and protects 2nd party

from exploit by 1st party) (see appendix for a more detailed description of this property)

• 2nd party partition-ability by 1st party

• Detectable leakage (2nd party to 3rd party)

• Detectable collusion of 2nd party against 1st party (2nd party with 2nd party, or 2nd party with 3rd party)

« Detectable collusion o

f 1st party against 2nd party (1st party with another 1st party relative to same 2nd

party or 1st party with 3rd party)

Adoptability via Dumb Crypto There is an explosion of activity toward developing new cryptographic algorithms. Elliptic curve cryptography has proven to be both highly secure and highly performant compared to other approaches. Unfortunately, new cryptographic algorithms take time to season, as it were, that is, to be battle-tested for weaknesses and exploits. Likewise, it takes time for new cryptographic algorithms to be supported widely across programming

languages and operating systems. It does not help much, practically speaking, to design a protocol that needs advanced crypto that is not yet readily available or sufficiently adoptable for some time. It becomes a theoretical protocol, not a very usable one. Hence, a design criterion we employ is that only highly adoptable, well-proven, cryptographic operations from broadly supported libraries be used. If a required cryptographic operation is not in those libraries then it's not a viable candidate for the protocol The best example, of best practices in highly adoptable crypto algorithms, is NaCL. The most popular implementation of NaCL is the libsodium library which is supported almost universally across programming languages and operating systems. This does not mean that other equivalently adoptable libraries are ruled out but merely that we use libsodium as a starting baseline or departure point. Furthermore, the signing and encryption algorithms in NaCL (Ed25519 and X25519) have been accepted into NIST's roadmap for approved government use (see Curve25519), In this work, we only consider pre-quantum safe algorithms. We assume the encoding of any cryptographic primitive supports sufficient agility. If we can design a protocol that only needs the operations found in libsodium then we have a practically adoptable baseline for that protocol. Best Authenticity (Public Key Signing) The standard for strong public key signing algorithms is SUF-CMA (Strong UnForgeability under Chosen Message Attack). When a digital signature has SUF-CMA with at least 128 bits of cryptographic strength then it is computationally infeasible to forge a signature or to discover the private key by choosing messages. The Libsodium implementation of the NaCL Ed25519 signature scheme has SUF-CMA Provable Security of Ed25519. So this is our baseline. In comparison, the popular ECDSA signature scheme only has the weaker EUF-CMA (Existential UnForgeability under Chosen Message Attack). Any scheme with SUF-SMA also has EUF-CMA This relative weakness of ECDSA has already been exploited in bitcoin. Consequently, some additional care must be taken when using signature schemes, like ECDSA, that are not SUF-CMA. The Ed25519 in libsodium has some additional security properties that make it a good starting baseline. The following table lists those properties.

scheme EUF-CMA SUF-CMA S-UEO M-S-UEO MBS

Ed25519-LibS X X X X X In addition to SUF-CMA, the S-UEO (Strong Universal Exclusive Ownership)

and M-S-UEO (Malicious Strong Universal Exclusive Ownership) properties provide additional resiliency against key substitution attacks. Whereas the MBS (Message Bound Security) property ensures a given signature verifies a unique message even for malicious keys. In addition, Ed25519 avoids private key memory leakage attacks, and its key clamping mechanism makes the re-use of a Ed25519 key pair for its bi-rationally equivalent X25519 encryption key pair resistant to key leakage attacks via the X25519 key pair.

In summary, the baseline for strong authenticity is to use the libsodium Ed25519 signature scheme

Best Confidentiality (Public Key Encryption)

The standard for strong public key encryption (PKE) algorithm is IND-CCA2 (Indistinguishability under Adaptive Chosen Ciphertext Attack). A scheme that has IND-CCA2 also has the weaker IND-CCA (Indistinguishability under Chosen Ciphertext Attack) which also has the weaker still IND-CPA (Indistinguishability under Chosen Plaintext Attack). What IND-CCA2 means is that an adversary can't submit ciphertexts in such a way as to discover the private key used to decipher those texts even when the adversary has access to an oracle that tells the adversary whether or not the ciphertext was a valid ciphertext. In addition, an adversary can't construct a valid ciphertext unless the adversary is aware of the associated plaintext.

For amore in depth description of IND-CCA2 see IND-CCA?2 part 1, and IND-CCA2 part 2

Earlier forms of public key encryption (PKE) only had IND-CPA or IND-CCA. Getting IND-CCA2 requires what is called an Integrated Encryption System (IES) that provides a public key encryption scheme. An IES that uses an elliptic curve is called an ECIES. A notable example of an ECIES that provides a public key encryption scheme with IND-CCA2 is the NaCL/Libsodium sealed box. What is special about an ECIES like NaCL's sealed box is that it provides the performance of symmetric encryption but with the end-only viewability of asymmetric public key encryption. What we mean by end-only viewability is that only the recipient to whom the box is sealed can decrypt the ciphertext. The sender cannot. The way sealed box does this is that it creates a non-interactive Diffie-Hellman (DH) en-de-cryption key using an ephemeral X25619 key pair with the long-term X25519 public key of the recipient. The sender never sees the ephemeral X25519 private key so it can't reconstruct the DH en-de-decryption key. The sealed box includes the ephemeral X25519 public key so that the recipient can reconstruct the DH en-de-cryption key using its own long-term X25519 private key and the provided ephemeral X25519 public key. The ciphertext is encrypted using symmetric encryption so it's high performant and only the holder of the long-term X25519 private key for the long-term X25519 public used in the sealed box to encrypt, can decrypt the ciphertext.

The following references might be helpful. ECIES properties, ECIES, IES, IES More,

ECIES is IND-C

CA2, Crypto Box Seal is ECIES

More recently the more descriptive term HPKE (Hybrid Public Key Encryption) has been used to describe IES that support public key encryption (PKE). This is memorialized in the IETF RFC-9180. RFC-9180 extends basic HPKE with 4 modes of operation in a standardized approach. The Libsodium sealed box has equivalent properties to RFC-9180 base mode [HPKE Analysis](

https:/feprint.iacr.org/2020/243.pdf ). For a good introduction to HPKE see HPKE and HPKE Blog

Unfortunately, implementations of RFC-9180 are not yet broadly available. So our baseline for IND-CCA2 is the Libsodium Crypto Box Seal or Sealed Box. This uses the X25519 key pairs and the venerable high-performant XSalsa20 stream cipher with the Poly1305 MAC that together provide the XSalsa20-Poly1305 AEAD that underlies the sealed box HPKE.

Furthermore, IND-CCAZ2, by itself, is insufficient to provide strong authenticity of the ciphertext. As section 9.1.1 of RFC-9180 points out, all variants are vulnerable to key-compromise impersonation attacks that may arise from a compromise of the recipient's private key (see KCI). RFC-9180 suggests that applications that require resistance against key-compromise impersonation should take extra steps to prevent this attack such as using a digital signature generated with the sender’s private key over the HPKE container, which means signing the sealed box (when using Libsodium). Essentially a KCI attack enables a compromise of the recipient’s keys to impersonate the recipient and perform a type of MITM (man-in-the-middle) attack when performing a key exchange where they substitute a different keypair from that intended by the sender. As a result, the sender may not detect the impersonation and therefore will encrypt to an impersonated key-pair see (KCI explained, Pandora’s Box). This also allows the attacker to purport that the confidential information was meant for the impersonated key pair thus also breaking authenticity.

Best Combined Authenticity and Confidentiality

As developed above for combined strong authenticity and confidentiality we need both hybrid public key encryption to the receiver’s key pair (with IND-CCA2) and public key signing from the sender’s key pair (with SUF-CMA). There are several ways to combine a cipher text and a signature. In order to protect against key- compromise impersonation attacks we must sign the encryption with the recipient's public key in plaintext. This is called encrypt-then-sign. But merely signing the encryption does not provide complete protection against all attacks. An attacker can strip the signature and resign the ciphertext with the attacker’s key but has never seen the plaintext of the cipher. In some circumstances, this might lead the recipient to falsely believe that the sender had knowledge of the plain text when it did not. For that, we must not only bind the recipient's public key to the signature in plaintext but also bind the sender’s public key inside the ciphertext.

Modified ESSR

An approach that protects against both KCI and sender impersonation of the ciphertext is called ESSR for Encrypt Sender's key and then Sign Receiver's key. The ESSR approach is detailed here ESSR. For a more accessible explanation see the following PKAE1, PKAE2, PKAE3

The properties that protect against key comprom

ise impersonation attacks are called TUF-PTXT (Third-party UnForgeability of PlainText), TUF-CTXT (Third-party UnForgeability of CipherText), RUF-PTXT (Receiver UnForgeability of PlainText), RUF-CTXT (Receiver UnForgeability of CipherText). Simply using the encrypt then sign approach provides TUF-PTXT, TUF-CTXT, and RUF-CTXT but not RUF-PTXT.

Signing the receiver's public key in plaintext outside the ciphertext portion of the message binds the receiver’s public key making a key substitution attack on the underlying plaintext to the signed ciphertext detectable which gives RUF-PTXT. One weakness of encrypt then sign in the case of a malicious receiver is that if the receiver can substitute a new key pair it can encrypt any message using the sender’s public key to the new keypair and purport that the sender intended to encrypt to that new key pair. Signing the ciphertext still leaves amalicious receiver free to find a combination of plaintext and receiver key pair that produces the same ciphertext. This is hard but not computationally infeasible. So we need a way to limit how malicious ciphertexts may be generated, and the ESSR way to do that is to bind the intended receiver’s public encryption key to the

sender’s signature. This way the ciphertext must decrypt using the intended receiver’s key pair, or it's invalid. The security of an encryption system ensures that it is computationally infeasible that given the same key two different plaintexts do not encrypt to or decrypt from the same ciphertext, i.e., a given plaintext must roundtrip through the cryptosystem given the same key. This is a property of a secure stream cipher such as xSalsa20 used for sealed-box (see XSalsa20). This is shown in the following table: (see ESSR)

scheme TUF-PTXT TUF-CTXT RUF-PTXT RUF-CTXT

Encrypt-then-Sign X X X

ESSR x x x X In summary, as a result of binding the senders public key inside the ciphertext and binding the receiver's public key in the enclosing signed plain text an adversary is prevented from forging messages that compromise either authenticity or confidentiality. Thus ESSR provides both strong authenticity and strong confidentiality. Baseline KERI ESSR We apply ESSR to KERI by modifying the basic ESSR approach to support unbounded-term identifiers by replacing the senders long-term public key with its AID and the receiver's long-term public key with its AID. The public keys are then securely looked up from the respective KELS of the sender and receiver. This is diagrammed below.

Baseline ESSR Message Verifiable Payload Restricted Payload Cipher-Data srcidentifier | | dst identifier | | src identifier data m ESSRBaselineMessage

Diagram: Baseline ESSR Message Plaintext Sourceless Variant As shown in the diagram above, the sender's AID appears both in the verifiable payload plaintext and the restricted payload ciphertext portion. The first appearance in the plaintext portion is so that the receiver or any party can validate the signature without first decrypting the ciphertext. This is essential for upstream DDOS protection using load balancers and firewalls which do not have access to the receiver's private decryption key

and therefore can't make a drop decision based on the sender via a whitelist or blacklist. To reiterate sharing the private decryption key with a load balancer or firewall upstream of the recipient in order to discover the sender’s public verification key would break confidentiality. Another limitation of removing the plain-text Sender AID is that the message's ciphertext is not publically verifiable. This means the authenticity of the ciphertext is not verifiable merely using public information. In some cases, a 3rd party may need to verify the authenticity of the ciphertext without seeing the plaintext from which the ciphertext was generated. That said there may be some applications where upstream DDOS andjor firewall protection and/or public verifiability is not needed. Because the sender AID appears twice, once in plain text and once in ciphertext if DDOS protection or public verifiability is not needed then the plaintext appearance could be removed without harming authenticity. In that case, DDOS or firewall protection (security) could be traded for not exposing the sender’s AID (privacy) without compromising the authenticity or confidentiality of the message. The following diagram shows the message without the sender’s AID in plaintext only in the ciphertext. Plaintext Sourceless Variant ESSR Message Verifiable Payload Restricted Payload Cipher-Data dst identifier | | src identifier data m ESSRPTSrclessMessage

Diagram: Plaintext Sourceless Variant ESSR Message In the case where the receiver follows the policy of only one relationship identifier (OORI) then it may be possible to maintain public verifiability without the sender AID in plaintext. With this policy, OORI, a given receiver AID, is only used for one given sender AID. The receiver can then store the sender’s AID for each of its OORI AIDS. This means that the receiver can assume that there is only one possible sender for each of its receiver AIDs. As a result, the sender AID in the message plaintext may not be necessary. With an OORI policy, ‘the receiver only accepts messages to a given receiver AID from a given sender AID that it looks up based on the receiver AID in the message plaintext. If the signature does not verify against the looked-up sender AID then the message is dropped. This unique mapping between receiver AID and sender AID can be shared upstream with a load balancer or intermediary so that they can do public verification of incoming messages. With an OORI policy, the message

diagrammed above would be publically verifiable in spite of not providing the src identifier in plaintext. Sourceless Variant

As described above, with an OORI policy, the receiver only accepts messages to a given receiver AID from a given sender AID. This policy may remove the need to include the sender’s AID in the ciphertext as well. When areceiver follows the OORI policy, it means that any other sender besides the one associated with the receiver AID can not strip the signature for a given ciphertext to the given receiver AID and replace it with its own because the receiver will drop it if the signature does not correspond to the sender AID allowed for that receiver AID. Notwithstanding the former, removing the ciphertext source AID, even with an OORI policy, still exposes the receiver to an attack when the approved sender is malicious. In this attack, the approved sender provides ciphertext for plaintext it has never seen but purports that it has seen it. Thus an OORI policy does not completely protect the receiver. But some applications may want to make this tradeoff. This variant is diagrammed below.

Sourceless Variant ESSR Message

Verifiable Payload

Restricted Payload

Cipher-Data ESSRSrclessMessage

Diagram: Sourceless Variant ESSR Message Destinationless Variant A subtle advantage of using AIDs instead of public keys is that it may make receiver key compromise impersonation more difficult. This allows us to make modifications to the baseline ESSR approach. This is because the only valid receiver's keys are those in the receiver's KEL. An attacker can't substitute a different key, not in the KEL; it must use a stale key. To elaborate, using AlDs, an attacker can't purport any plaintext to have been encrypted to a different key pair other than the one that appears in the receiver's KEL. So any ciphertext must decrypt using one of the receiver's keypairs, either the current one or a stale one. A malicious receiver can't encrypt any plaintext with any keypair it chooses. The malicious receiver must either find a combination of stale key pair and plaintext that generates the same signed ciphertext as its current keypair or confuse the sender into signing ciphertext generated by the receiver with its current encryption keypair for plain text not yet seen by the sender.