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 a communication 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 (1B) channel, thus making the OB 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.

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 is easier because it's not about routing o 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.

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 1st and 2nd parties represent the parties to a conversation or

s ———ofi—] The 15t party discloses data to a 2nd party.

The 1st and 2nd parties have knowledge of each other via their

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

data (content). ¢ I Asa result of the disclosure the nd party as disclosee also has st party 4 second pary knowledge of the disclosed data (content). A Iy The identifiers are non-content meta-data, and the disclosed data’s g pon, || content data. A 3rd party is any party that is not either a tst or and 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 %fl 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. frstpary - second party

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 o Mide . o . — ~{ Midde g Ml - . aata End [ ; Midde b daa [ Midde o deta — — Ed | . ] e, -t (e g - 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 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 ( 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 Hoauonk 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 (1ES) that provides a public key encryption scheme. An IES that uses an elliptic curve is 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 s 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 X25519 key pair with the long-term X25519 public key of the recipient. The sender never sees the ephemeral X25519 private key 0 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 o it's high performant and only the holder of the long-term Xa5519 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://www.rfc-editor.orglrfc/rfcg18o.html). 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

IND-CCA2 via ECIES, HPKE Baseline for IND-CCA2 i the Libsodium Crypto Box Seal or Sealed Box. This uses the X25519 key pairs and the venerable high-performant XSalsa2o 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

HPKE is not Authenticity IND-CCA2, 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. 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 s, 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.iacr.org/2006/252.pdf https:/fwww.rfc-editor.org/rfc/rfcg180.htmi#name-key-compromise-impersonatio https:/fwww.cryptologie.net/article/372/key-compromise-impersonation-attacks-kci/ https:/fwww.usenix.org/system|files/conference/woot15/woot15-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.

Baseline ESSR Message Authenticatible Confidential Message Verifiable Payload [ Restricted Payload Cipher-Data srcidentifier | | dst identifier

Relationships

(B, <>, B)

(A, ->, B)

(&, <-, B) _— i ) { T R (o) 2 | (i — ( ';"ww; X m:y.‘%h,.;.‘*. [ oo, g | [ )

Relationship Graph (global) S TR IR R s 2 7, Y 1 P LI L

i s Relationship Graph B “