mirror of
https://github.com/AtHeartEngineer/docs-mdbook.git
synced 2026-01-09 17:17:54 -05:00
reorg, work on request, clean up
This commit is contained in:
@@ -7,4 +7,4 @@ title = "tlsn-docs"
|
||||
|
||||
[output.html]
|
||||
mathjax-support = true
|
||||
default-theme = "light"
|
||||
default-theme = "ayu"
|
||||
|
||||
@@ -1,18 +1,16 @@
|
||||
# Summary
|
||||
|
||||
- [Introduction](./intro.md)
|
||||
- [Protocol](./protocol/README.md)
|
||||
[Introduction]()
|
||||
# [Protocol](./protocol/README.md)
|
||||
- [Overview](./protocol/overview/README.md)
|
||||
- [Request Phase](./protocol/request/README.md)
|
||||
- [Key Exchange](./protocol/request/key_exchange.md)
|
||||
- [(Enc/Dec)ryption]()
|
||||
- [Commitment]()
|
||||
- [Notarization Phase]()
|
||||
- [Selective Disclosure Phase]()
|
||||
- [Secure 2-Party Computation](./protocol/2pc/garbled_circuits.md)
|
||||
- [Garbled Circuits](./protocol/2pc/garbled_circuits.md)
|
||||
- [Oblivious Transfer](./protocol/2pc/oblivious_transfer.md)
|
||||
- [Paillier](./protocol/2pc/paillier.md)
|
||||
- [MAC](./protocol/2pc/mac.md)
|
||||
- [Handshake](./protocol/handshake/README.md)
|
||||
- [Key Exchange](./protocol/handshake/key_exchange.md)
|
||||
- [PRF](./protocol/handshake/prf.md)
|
||||
- [Verification](./protocol/handshake/verify.md)
|
||||
- [Query](./protocol/query/README.md)
|
||||
- [Encryption](./protocol/query/encryption.md)
|
||||
- [Decryption](./protocol/query/decryption.md)
|
||||
- [Commitment](./protocol/query/commitment.md)
|
||||
- [Notarization](./protocol/notarization/README.md)
|
||||
- [Garbled Circuits]()
|
||||
- [Oblivious Transfer]()
|
||||
- [Paillier]()
|
||||
- [MAC](./protocol/2pc/mac.md)
|
||||
@@ -0,0 +1 @@
|
||||
# Secure 2-Party Computation
|
||||
|
||||
@@ -1 +0,0 @@
|
||||
# Handshake
|
||||
@@ -1 +0,0 @@
|
||||
# Verification
|
||||
26
src/protocol/overview/README.md
Normal file
26
src/protocol/overview/README.md
Normal file
@@ -0,0 +1,26 @@
|
||||
# Overview
|
||||
|
||||
<div>
|
||||
<style>
|
||||
.zoom-without-container {
|
||||
transition: transform .2s; /* Animation */
|
||||
margin: 0 auto;
|
||||
}
|
||||
.zoom-without-container img{
|
||||
width:100%;
|
||||
height:auto;
|
||||
}
|
||||
.zoom-without-container:hover {
|
||||
transform: scale(2);
|
||||
}
|
||||
</style>
|
||||
<div class="zoom-without-container">
|
||||
<img src="https://raw.githubusercontent.com/tlsnotary/docs-assets/main/diagrams/overview.png" alt="zoom">
|
||||
</div>
|
||||
</div>
|
||||
|
||||
The TLSNotary protocol can be decomposed into three distinct phases:
|
||||
|
||||
1. [Request Phase](./request.md)
|
||||
2. Notarization Phase
|
||||
3. Selective Disclosure Phase
|
||||
30
src/protocol/request/README.md
Normal file
30
src/protocol/request/README.md
Normal file
@@ -0,0 +1,30 @@
|
||||
# Request Phase
|
||||
|
||||
During the Request Phase the `Requester`, otherwise referred to as the `User`, and the `Notary` work together to generate an authenticated `Transcript` of a TLS session with a `Server`.
|
||||
|
||||
Listed below are some key points regarding this process:
|
||||
|
||||
- The identity of the `Server` is not revealed to the `Notary`, but the `Requester` is capable of proving the `Server` identity to a `Verifier` later.
|
||||
- The `Notary` only ever sees the *encrypted* application data of the TLS session.
|
||||
- The protocol guarantees that the `Requester` is not solely capable of constructing requests, nor can they forge responses from the `Server`.
|
||||
|
||||
## Requester
|
||||
|
||||
The `Requester` is the party which runs the TLS connection with the `Server`. The `Requester` constructs application payloads, eg. HTTP requests, and coordinates with the `Notary` to encrypt them with the TLS session keys prior to sending them. Subsequently, the `Requester` works with the `Notary` to decrypt responses from the `Server`. The plaintext of the application data is only ever revealed to the `Requester`.
|
||||
|
||||
## Notary
|
||||
|
||||
The `Notary` is the party of which the authenticity of the `Transcript` relies on. During the session the `Notary` withholds its' shares of the TLS keys and participates in a series of secure 2-party computation protocols with the `Requester` to operate the TLS connection.
|
||||
|
||||
## Server
|
||||
|
||||
The `Server` can be any server which supports TLS. The TLSNotary protocol is entirely transparent to the `Server`, thus it can not be censored nor does it have to support any additional functionality.
|
||||
|
||||
## Transcript
|
||||
|
||||
The primary artifact generated from this phase is called the `Transcript`. It contains session meta-data, the server signature, and commitments to all the requests and responses.
|
||||
|
||||
> Note that the server signature (RSA) does not reveal the identity of the server.
|
||||
|
||||
|
||||
<img src="https://raw.githubusercontent.com/tlsnotary/docs-assets/main/diagrams/transcript.png">
|
||||
Reference in New Issue
Block a user