Papers

SPAC (Secure Privacy, Authenticity, and Confidentiality) Privacy Given Strongest Authenticity and Confidentiality Samuel M. Smith Ph.D. sam@keri.one https://keri.one 2023/06/17

Whitepaper https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/SPAC_Message.md

PAC Theorem One can have any two of the three (privacy, authenticity, confidentiality) at the highest level but not all three. Authentic Tradespace

3 g g Trade-offs required!

TolP Design Goals

Establishing trust between parties requires that each party develop confidence in the following properties of their relationship: Authenticity

Is the receiver of a communication able to verify that it originated from the sender and has not been tampered with? Confidentiality

Are the contents of acommunication protected so that only authorized parties have access?

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 TolP design goals 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 with respect to the other two. https://github.com/trustoverip/TechArch/blob/main/spec.md#61-design-goals

Privacy versus Confidentiality

There are also two fundamentally different but complementary definitions of privacy that are relevant to protocol

design.

• The first definition is about the recipient respecting the data privacy concerns of the sender w.r.t. the content disclosed to the recipient. The protection comes from the recipient protecting the data privacy rights of the sender once the recipient has received that data. This first type of privacy protection may be achieved independently of the privacy of the communications channel itself that conveys the content to the receiver.

• The second definition is about the correlatability of the publicly viewable metadata included in the communication. This is called non-content meta-data by the surveillance community. This definition distinguishes between confidential data (meta-data or otherwise) that is not viewable by 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 the in-band (1) channel, thus making the 0B exchange itself confidential without encryption.

• Cryptographic solutions alone cannot sustainably protect privacy, w.r.t. either individual data rights or surveillance.

• Acomprehensive approach that combines cryptography and legal liability is required.

• Ultimately, accountability on the receiver is necessary to protect the privacy of the discloser in a sustainable fashion.

Privacy and Confidentiality Legalese The terms confidential and private also have distinct legal definitions. The legal definition of confidentiality, however, is consistent with both the surveillance definition and the design goal definitions above. Confidentiality law is about contractual agreements governing the disclosure of data by one party to another. The legal definition of privacy, on the other hand, is not so consistent. The regulatory surveillance law definition differs from the privacy rights regulatory law definition. The former is about drawing the line between non-content metadata and content data in order to be classified as either searchable or not (see https://www.lawfareblog.comrelative-vs-absolute-approaches-contentmetadata-line and https:// www.pogo.org/analysisf2019/06/the-history-and-future-of-mass-metadata-surveillance/) The latter is mainly about protecting personal data rights by data holders, controllers, and processors such as GDPR (see https:/fgdpr-info.eu). Confidentiality law can be used better to protect personal data rights. For example, the well-known concept called chain-ink confidentiality, circa 2012, details how one can protect the data privacy concerns of the sender via contractual confidentiality law. ACDCs, for example, use the well-known Riccardian Contract formalism, circa 1996, to support chain-ink-confidential through what is called contractually protected disclosure.

Survelliance Legalese Physical Search A physical 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.

Surveillance Privacy Problem We can have strong authenticity and 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. Privacy, as non-correlatable identifiers (metadata) will always be difficult. Whereas, privacy as control over one's data rights s easier because it's not about routing or billing. For the purposes of protocol design the definitions of confidentiality and privacy that are most suitable are the surveillance definitions because these are primary to the trade-space of PAC.

Historically, an address of any kind (including the original postal address) exists for two main purposes.

1.50 that stuff can get routed (delivered) to that address as a destination via public roads.

2.50 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 public 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 so that stuff can get routed to those addresses but also so they can be the destination for bills to pay for the communication tself. 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 public street is not protected, and its license plate is a publically viewable address proxy.

Asaresult, 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 willikely 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 altenative 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.

Practical Elaborations 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 Protection as Protection from Exploitation We define privacy protection as protection against the exploitation of correlatable identifiers (metadata). The goal becomes limiting the exploitation via exploitably correlatable identifiers (metadata). 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.

Privacy Authenticity and confidentiality are a cold war ... Proposed authenticity/confidentiality security overlays provide arbitrarily strong protection even with minimal resources Privacy is a hot war ... Rapidly evolving tactics and tech, resource-constrained war of attrition against vastly superior opponents Reduction in potential harm by decreasing privacy attack surface may net increase actual harm due to lost value capture opportunities Focus on exploitably correlatable identifiers Make risk mitigation trade-off between exploitable harm and protection cost {

The 15t and 2nd parties represent the parties to a conversation or

exchange. ! e <

The 15t party discloses data to a 2nd party.

The 15t and 2nd parties have knowledge of each other via their

identifiers. The tst party as discloser has knowledge of the disclosed |t pary

data (content). v v Asaresult of the disclosure the 2nd party as disclosee also has frotparty €—— O cocond pary knowledge of the disclosed data (content). A A The identifiers are non-content meta-data, and the disclosed datais stpary pr—— content data. A 3rd party is any party that is not either a 1st or 2nd Support support party. An intermediary may be considered a 1st, 2nd, or 3rd party

depending on how and by whom it s 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 %% intermediry |<-—————

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

A3rd party may directly break privacy by directly observing messages v v

that contain the identifiers of the 1st and 2nd parties. Trtpory > secondpary

A3rd party may directly break confidentiality by directly observing the A Iy

content of messages between the 1st and 2nd parties. —— —L g . i st perty second party

The 3rd party may indirectly break both privacy and confidentiality by | support support

collusion with the 1st or 2nd party or via collusion with an intermediary.

AIDs as Unbounded Term Identifiers Long-term public keys and short-term public keys. Many public key cryptographic algorithms employ the concept of long-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. 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.

Dual End Verifiability and End-Only Viewability End-to-End Verifiability of Authenticity Only-at-End Viewability via Confidentiality « Middie o data ,'d = Middle F [ Middle - End | :\M\dd\epm—»:mdme} ez End = - w Sl g e Ambient Verifiability: any-data, any-where, any-time by any-body End only Viewability: one-data, one-where, one-time by one-body If the edges are secure, the security of the middle doesn’t matter. Zero-Trust-Computing Its much easier to protect one’s private keys than to protect all internet infrastructure

Strong End-Only-Viewable Confidentiality Use the 3-party model where: 1st party is the sender, 2nd party is the intended receiver 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 of 1st party against 2nd party (1st party with another 1st party relative to same 2nd party or 1st party with 3rd party)

Best Authenticity (Secure Attribution) SUF-CMA 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 itis 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 ( See Provable Security of Ed25519 https://eprint.iacr.org/2020/823.pdf). 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.

Strong Authenticity Baseline Security properties of Ed25519 in libsodium: | scheme | EUF-CMA | SUF-CMA | S-UEO | M-S-UEO | MBS | | | Ed25519-Libs | X | X | X | X | X | 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. The baseline for strong authenticity is to use the libsodium Ed25519 signature schem

Strong Confidentiality IND-CCA2 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. tpsiblog.sytogzaphyenginering {20 Soawonk postshosen ciphertent securiyin bl kepencopton art spsiblos ryptoaphyengineering comiaorlafopwork st chosemcphertext securtypublckey eneypean art2)

IND-CCA2 via ECIES, HPKE 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 s called an ECIES. Anotable 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 nonvinteractive Diffie-Hellman (DH) en-de-cryption key using an ‘ephemeral X25519 key pair with the long-term X25519 public key of the recipient. The sender never sees the ephemeral X25519 private key 5o it can't reconstruct the DH en-de-decryption key. The sealed box includes the ephemeral X25519 public key 50 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. IETF RFC-9180 has generalized ECIES with HPKE (https://wwuw.rfc-editor.org/rfc/rfcgi8o.html). RFC-9180 extends basic HPKE with 4 modes of operation ina standardized approach. The Libsodium sealed box has equivalent properties to RFC-9180 base mode

IND-CCA2 via ECIES, HPKE 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 AEAD that underlies the sealed box HPKE. https:/flibsodium.gitbook.io/doc/advancedjstream_ciphers/xsalsa20 https://en.wikipedia.orgfwiki/ChaCha20-Poly1305

IND-CCA2, by itself, s 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.

This also allows the attacker to purport that the confidential information was meant for the impersonated key pair thus also breaking authenticity.

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

https:/feprint.jacr.orgl2006/252.pdf

https:/fwwiw.rfc-editor.org/rfc/rfcg180.html#name-key-compromise-impersonatio https:/fwwiw.cryptologie.net/article/372/key-compromise-mpersonation-attacks-kci/ https:/jwww.usenix.org/system/files/conferencefwootis/wootts-paper-hlauschek.pdf

Best Combined Authenticity and Confidentiality 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.

ESSR (Encrypt Sender Sign Receiver) An approach that protects against both KCI and sender impersonation of the ciphertext is called ESSR. https:/jeprint.acr.orgl001/079) The properties that protect against key compromise 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. I scheme | TUF-PTXT | TUF-CTXT | RUF-PTXT| RUF-CTXT | A e L | Encrypt-then-Sign | x| X x| | ESSR | X | X I X X | As a result of binding the sender's 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.