- Authentication
- Password based - PACE, ...
- Other authentication Wultra, Opaque, ...
- Secret sharing and thresholds
- Commitment
- Oblivious Transfer - Private Information Retrieval
- Other privacy related protocols
- Intro PETs
- Fiat-Shamir - creating a signature on a proof of knowledge
- DAA - Direct Anonymous Attestation
- ZK - Zero Knowledge
- Anonymous Credentials - CL, Idemix, ...
- SD - Selective Disclosure, U-prove,...
- TOR, I2P, ...
- TLS
- IPSEC
- SSH
- QKD - Quantum Key Distribution
- Signal
- Peer2peer

- Cryptographic Protocol
*- Wikipedia* - Authentication
*- Wikipedia*- can be considered to be of three types: - Accepting proof of identity given by a credible person who has first-hand evidence that the identity is genuine. This can be organised centralised or decentralised.
- Comparing the attributes of the object itself to what is known about objects of that origin (e.g. a painting).
- Relying on documentation or other external affirmations. In criminal courts, the rules of evidence often require establishing the chain of custody of evidence presented.
- Authentication Protocol
*- Wikipedia*

- PACE
*Password Authenticated Connection Establishment* - Developed by the German Bundesamt für Sicherheit in der Informationstechnik (BSI), free of patents
- Establishes a shared session key between a contactless smartcard and terminal using the DH key agreement protocol
- As DH key agreement does not support authentication it is vulnerable to man-in-the-middle at-tacks. To prevent this and to ensure user consent, PACE uses a password-based protocol to protect the wireless communication interface between the terminal and the card before the card is accessed. In the most common scenario a PIN, permanently stored in the card and entered into the terminal by the user.
- As the password is used during the calculation of the session key, entering a wrong password leads to different session keys on both sides which causes the connection establishment to fail.

- Wultra Powerauth
- Wultra Powerauth developer doc
- A protocol for a key exchange and for subsequent request signing
- Based on a used cryptography, a security scheme and standard RESTful API end-points
- OPAQUE
- A secure asymmetric password-authenticated key exchange (aPAKE) that supports mutual authentication in a client-server setting without reliance on PKI and with security against pre-computation attacks upon server compromise

- Secret Sharing (splitting)
*- Wikipedia*- Shamir's scheme (SSS), Blakley's scheme - Verifiable Secret Sharing (VSS)
*- Wikipedia*Feldman's scheme, Benaloh's scheme, secret ballot elections - A secret sharing scheme is verifiable if auxiliary information is included that allows players to verify their shares as consistent.
- VSS ensures that even if the dealer is malicious there is a well-defined secret that the players can later reconstruct. In standard secret sharing, the dealer is assumed to be honest.
- VSS was first introduced in 1985 by Benny Chor, Shafi Goldwasser, Silvio Micali and Baruch Awerbuch.
- The
**dealer**is a distinguished player who wants to share the secret - The protocol consists of two phases: a sharing phase and a reconstruction phase.
- Sharing: Initially the dealer holds secret as input and each player holds an independent random input. The sharing phase may consist of several rounds. At each round each player can privately send messages to other players and can also broadcast a message. Each message sent or broadcast by a player is determined by its input, its random input and messages received from other players in previous rounds.
- Reconstruction: In this phase each player provides its entire view from the sharing phase and a reconstruction function is applied and is taken as the protocol's output.
- An alternative definition given by Oded Goldreich defines VSS as a secure multi-party protocol for computing the randomized functionality corresponding to some (non-verifiable) secret sharing scheme. This definition is stronger than that of the other definitions and is very convenient to use in the context of general secure multi-party computation.
- Verifiable secret sharing is important for MPC, which is typically accomplished by making secret shares of the inputs, and manipulating the shares to compute some function.
- To handle "active" adversaries (that is, adversaries that corrupt nodes and then make them deviate from the protocol), the secret sharing scheme needs to be verifiable to prevent the deviating nodes from throwing off the protocol.
- Publicly Verifiable Secret Sharing
*- Wikipedia* - A secret sharing scheme is publicly verifiable (PVSS) if it is a verifiable secret sharing scheme and if any party (not just the participants of the protocol) can verify the validity of the shares distributed by the dealer.
- Chaum-Pedersen protocol - ref voting infra
- A simple PVSS and its application to e-voting
*- Berry Schoenmakers*

- Commitment scheme
*- Wikipedia* - Allows one to commit to a chosen value (or chosen statement) while keeping it hidden to others, with the ability to reveal the committed value later.
- Notion of commitments appeared earliest in works by Manuel Blum, Shimon Even, and Shamir et al. The terminology seems to have been originated by Blum.
- Formalized by Gilles Brassard, David Chaum, and Claude Crepeau in 1988 as part of various Zero-Knowledge protocols for NP.
- Use in ZK:
- To allow the prover to participate in "cut and choose" proofs where the verifier will be presented with a choice of what to learn, and the prover will reveal only what corresponds to the verifier's choice. Commitment schemes allow the prover to specify all the information in advance, and only reveal what should be revealed later in the proof.
- To allow a verifier to specify their choices ahead of time in a commitment. This allows zero-knowledge proofs to be composed in parallel without revealing additional information to the prover.

- Explanation of KZG polynomial commitments -
*- Dankrad Feist*

- Oblivious transfer protocol
*- Wikipedia* - Protocol in which a sender transfers one of potentially many pieces of information to a receiver, but remains oblivious as to what piece (if any) has been transferred.
- The first form of OT was introduced in 1981 by Michael O. Rabin./li>
- A more useful form called
**1–2 OT**or "1 out of 2 OT" was developed by Even, Goldreich, and Lempel. Useful in MPC. - Generalized to
**1 out of n OT**where the user gets exactly one database element without the server getting to know which element was queried, and without the user knowing anything about the other elements that were not retrieved. The latter notion of oblivious transfer is a strengthening of**private information retrieval**, in which the database is not kept private. **k-n OT**is a special case of generalized oblivious transfer.- Rabin OT
*- IPython*

- ZK proof - Wikipedia
- Interactive Proof System (IPS) - Wikipedia Arthur-Merlin, Public coin, private coin protocols, Probabilistic Checkable Proofs, ...
- If we allow the probabilistic verifier machine and the all-powerful prover to interact for a polynomial number of rounds, we get the class of problems called IP. In 1992, Adi Shamir revealed in one of the central results of complexity theory that IP equals PSPACE, the class of problems solvable by an ordinary deterministic Turing machine in polynomial space
- ZKPs were first mentioned in the original 1985 paper on IP by Goldwasser, Micali and Rackoff, but the extent of their power was shown by Oded Goldreich, Silvio Micali and Avi Wigderson.
- Goldwasser in 1988 introduced "Multi prover interactive proofs: How to remove intractability assumptions", which defines a variant of IP called MIP in which there are two independent provers. The two provers cannot communicate once the verifier has begun sending messages to them. Just as it's easier to tell if a criminal is lying if he and his partner are interrogated in separate rooms, it's considerably easier to detect a malicious prover trying to trick the verifier into accepting a string not in the language if there is another prover it can double-check with.
- Non-interactive ZK proof - Wikipedia
- Cryptographic primitives where information between a prover and a verifier can be authenticated by the prover, without revealing any of the specific information beyond the validity of the statement itself.
- This makes direct communication between the prover and verifier unnecessary, effectively removing any intermediaries.
- The core trustless cryptography "proofing" involves a hash function generation of a random number, constrained within mathematical parameters (primarily to modulate hashing difficulties) determined by the prover and verifier.
- Key advantage is that they can be used in situations where there is no possibility of interaction between the prover and verifier, such as in online transactions where the two parties are not able to communicate in real time.
- Useful in decentralized systems like blockchains, where transactions are verified by a network of nodes and there is no central authority to oversee the verification process.
- Mostly based on elliptic curve cryptography or pairing-based cryptography, which allow for the creation of short and easily verifiable proofs of the truth of a statement.
- Unlike interactive zero-knowledge proofs, which require multiple rounds of interaction between the prover and verifier, non-interactive zero-knowledge proofs are designed to be efficient and can be used to verify a large number of statements simultaneously.
- Some history:
- Blum, Feldman, and Micali (1988) showed that a common reference string (crs) shared between the prover and the verifier is sufficient to achieve computational zero-knowledge without requiring interaction.
- Goldreich and Oren gave impossibility results for one shot zero-knowledge protocols in the standard model.
- In 2003, Shafi Goldwasser and Yael Tauman Kalai published an instance of an identification scheme for which any hash function will yield an insecure digital signature scheme. These results are not contradictory, as the impossibility result of Goldreich and Oren does not hold in the crs model or the random oracle model. Non-interactive zero-knowledge proofs however show a separation between the cryptographic tasks that can be achieved in the standard model and those that can be achieved in 'more powerful' extended models.
- The model influences the properties that can be obtained from a zero-knowledge protocol. Pass showed that in the crs model non-interactive zero-knowledge protocols do not preserve all of the properties of interactive zero-knowledge protocols; e.g.,
**they do not preserve deniability**. - Non-interactive zero-knowledge proofs can also be obtained in the random oracle model using the Fiat–Shamir heuristic.
**zk-SNARKS**: Chiesa et al developed the zk-SNARK protocol (2012), used in the Zerocash blockchain. Zcash utilized zk-SNARKs to facilitate four distinct transaction types: private, shielding, deshielding, and public. This allowed users to determine how much data was shared with the public ledger for each transaction.- Ethereum zk-Rollups also utilize zk-SNARKs to increase scalability.
- In 2017, Bulletproofs was released, which enable proving that a committed value is in a range using a logarithmic (in the bit length of the range) number of field and group elements. Bulletproofs was later implemented into Mimblewimble protocol (the basis for Grin and Beam, and Litecoin via extension blocks) and Monero cryptocurrency.
**zk-STARKs**: In 2018, the zk-STARK (zero-knowledge Scalable Transparent Argument of Knowledge) protocol was introduced by Eli Ben-Sasson, Iddo Bentov, Yinon Horesh, and Michael Riabzev, offering transparency (no trusted setup), quasi-linear proving time, and poly-logarithmic verification time. zk-STARKs are a type of cryptographic proof system that enables one party (the prover) to prove to another party (the verifier) that a certain statement is true, without revealing any additional information beyond the truth of the statement itself. zk-STARKs are succinct, meaning that they allow for the creation of short proofs that are easy to verify, and they are transparent, meaning that anyone can verify the proof without needing any secret information.- Unlike the first generation of zk-SNARKs, zk-STARKs, by default, do not require a trusted setup, which makes them particularly useful for decentralized applications like blockchains. Additionally, zk-STARKs can be used to verify many statements at once, making them scalable and efficient.
- In 2019, HALO recursive zk-SNARKs without a trusted setup were presented.
- ZK background at circom
- Oded Goldreich - Wikipedia - books, GMW papers, ...
- 'A Graduate Course in Applied Cryptography' - Dan Boneh and Victor Shoup, part III protocols (proving properties in zero-knowledge)
- ZK proof - Wikipedia

- "I know the private key that corresponds to this public key" : in this case, the proof would not reveal any information about the private key.
- "I know a private key that corresponds to a public key from this list" : as before, the proof would not reveal information about the private key but in this case, the associated public key would also remain private.
- "I know the preimage of this hash value" : in this case, the proof would show that the prover knows the preimage but it would not reveal any information about the value of that preimage.
- "This is the hash of a blockchain block that does not produce negative balances" : in this case, the proof would not reveal any information about the amount, origin or destination of the transactions included in the block.

- Security.
- The client is concerned about integrity of computation: how can he ascertain that the server reports the correct output z?
- In contrast, the server is concerned about confidentiality of his own input: how can he prevent the client from learning information about w?
- The server, acting as the prover, attempts to convince the client, acting as the verifier, that the following NP statement is true: “there exists w such that z = F (x, w)”. Indeed:
- The soundness property of the proof system guarantees that, if the NP statement is false, the prover cannot convince the verifier (with high probability). Thus, soundness addresses the client’s integrity concern.
- The zero-knowledge property of the proof system guarantees that, if the NP statement is true, the prover can convince the verifier without leaking any information about w (beyond was is leaked by the output z). Thus, zero knowledge addresses the server’s confidentiality concern.
- Moreover, the client sometimes not only seeks soundness but also proof of knowledge which guarantees that, whenever he is convinced, not only can he deduce that a witness w exists, but also that the server knows one such witness. This stronger property is often necessary to security if F encodes cryptographic computations, and is satisfied by most zero-knowledge proof systems.

- ZKproof.org standardize and mainstream cryptography by building a community-driven trust ecosystem

- Some SNARKS supports proving/verifying membership in a specific NP-complete language such as R1CS (rank-1 constraint systems). An instance of the language is specified by a set of equations over a prime field F, and each equation looks like: < A, (1,X) > * < B , (1,X) > = < C, (1,X) > where A,B,C are vectors over F, and X is a vector of variables.
- Arithmetic (as well as boolean) circuits are easily reducible to R1CS by converting each gate into a rank-1 constraint. See Ben-Sasson Appendix E (and "System of Rank 1 Quadratic Equations").
- R1CS in Rust

- libsnark - github a C++ library for zkSNARK proofs
- circom compiler written in Rust for compiling circuits written in the circom languag, outputs the representation of the circuit as constraints and everything needed to compute different ZK proofs
- zokrates - github a toolbox for zkSNARKs on Ethereum. It helps you use verifiable computation in your DApp
- Bellman
*a Rust crate for building zk-SNARK circuits. It provides circuit traits and primitive structures, as well as basic gadget implementations such as booleans and number abstractions.* - 'Achieves 3.14× speedup for Groth16, which is the most efficient zk-SNARK implementation working on BLS12-381 ECC field'
- iden3.io access control based on self-sovereign identity for decentralised and trust-minimised environments
- The Circom 2.0 compiler is used to create Zero-Knowledge Proofs for the circuits.
- circom circuit compiler
- Comes with a Rapid-PLONK scheme that offers a single trusted setup that can be shared with multiple applications.
- Supports DID, JSON-LD and JSON schema to be interoperable with W3C standards for Verifiable Credentials.

- Electriccoin - Zcash
- Local ZCash link
- halo
- halo2
- halo2 explanation ZCash
- eprint.iacr.org - PLONK
*Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge*, uses Kate commitments - Vitalik Buterin explaining PLONK

- jan.camenisch.org
*- homepage* - Idemix
*- Identity Mixer*- now in HL Fabric - Idemix is a protocol suite for privacy-preserving authentication and transfer of certified attributes which has been integrated into Hyperledger Fabric and forms the cryptographic core of Sovrin
- See also PrimeLife
- Jan Camenisch - Wikipedia
- NL - Yivi app
*- IRMA card based*- which is Idemix-based - Yivi is a front-end that forms a Javascript "client" to the IRMA server.
- Privacy by Design github
*including IRMA stuff* - NL - IRMA doc
*- IRMA card based* - IRMA is a set of free and open source software projects implementing the Idemix attribute-based credential scheme, allowing users to safely and securely authenticate themselves as privacy-preserving as the situation permits. Users receive digitally signed attributes from trusted issuer, storing them in their IRMA app, after which the user can selectively disclose attributes to others.

- BBS signatures - Boneh-Boyen-Shacham - Short group signatures Annual international cryptology conference. Springer, Berlin, Heidelberg, 2004.
- BBS+ signatures - Man Ho Au, Willy Susilo, and Yi Mu, Constant-Size Dynamick-TAA International conference on security and cryptography for networks. Springer, Berlin, Heidelberg, 2006
- BBS+ eprint.iacr.org
- BBS+ implementation in Rust

- TLS - Wikipedia
- TLS V2 RFC 5246
- TLS V3 RFC 8446
- TLS Work Group in IETF
- IETF RFC best practice on TLS
- IETF RFC 4492 ECC for TLS
- IETF RFC 5489 ECDHE_PSK Cipher Suites for Transport Layer Security (TLS)
- IETF RFC 7905 ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS) - primitives to be built in AEAD
- SSLabs.com
- SSLabs on TLS
- SSL config on Mozilla

- the transport layer provides server authentication, confidentiality, and integrity
- the user authentication protocol validates the user to the server
- the connection protocol multiplexes the encrypted tunnel into multiple logical communication channels

- 3des-cbc
- aes128-cbc
- aes192-cbc
- aes256-cbc
- rijndael-cbc@lysator.liu.se
- aes128-ctr
- aes192-ctr
- aes256-ctr
- aes128-gcm@openssh.com
- aes256-gcm@openssh.com
- chacha20-poly1305@openssh.com

- aes128-gcm@openssh.com
- aes256-gcm@openssh.com
- chacha20-poly1305@openssh.com

- hmac-sha1
- hmac-sha1-96
- hmac-sha2-256
- hmac-sha2-512
- hmac-md5
- hmac-md5-96
- umac-64@openssh.com
- umac-128@openssh.com
- hmac-sha1-etm@openssh.com
- hmac-sha1-96-etm@openssh.com
- hmac-sha2-256-etm@openssh.com
- hmac-sha2-512-etm@openssh.com
- hmac-md5-etm@openssh.com
- hmac-md5-96-etm@openssh.com
- umac-64-etm@openssh.com
- umac-128-etm@openssh.com

- diffie-hellman-group1-sha1
- diffie-hellman-group14-sha1
- diffie-hellman-group14-sha256
- diffie-hellman-group16-sha512
- diffie-hellman-group18-sha512
- diffie-hellman-group-exchange-sha1
- diffie-hellman-group-exchange-sha256
- ecdh-sha2-nistp256
- ecdh-sha2-nistp384
- ecdh-sha2-nistp521
- curve25519-sha256
- curve25519-sha256@libssh.org

- ssh-ed25519
- ssh-rsa
- rsa-sha2-256
- rsa-sha2-512
- ssh-dss
- ecdsa-sha2-nistp256
- ecdsa-sha2-nistp384
- ecdsa-sha2-nistp521

- I2P doc
- I2P ntcp
- I2P ntcp2
- NTCP2 is an authenticated key agreement protocol that improves the resistance of NTCP to various forms of automated identification and attacks

- NoiseProtocol - WhatsApp, I2P, ...
- Noise is a framework for crypto protocols based on Diffie-Hellman key agreement.

- Nebula on GitHub - rooted in Slack Engineering
- Nebula on Slack
- Based on Noise
- Nebula on Defined.Net
- Nebula main.go
- Nebula cmd main.go
- Nebula configuration including PKI
- Nebula introduction by Slack Engineering