Convert more content
@@ -1,12 +0,0 @@
|
||||
---
|
||||
slug: first-blog-post
|
||||
title: First Blog Post
|
||||
authors: [slorber, yangshun]
|
||||
tags: [hola, docusaurus]
|
||||
---
|
||||
|
||||
Lorem ipsum dolor sit amet...
|
||||
|
||||
<!-- truncate -->
|
||||
|
||||
...consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
|
||||
@@ -1,44 +0,0 @@
|
||||
---
|
||||
slug: long-blog-post
|
||||
title: Long Blog Post
|
||||
authors: yangshun
|
||||
tags: [hello, docusaurus]
|
||||
---
|
||||
|
||||
This is the summary of a very long blog post,
|
||||
|
||||
Use a `<!--` `truncate` `-->` comment to limit blog post size in the list view.
|
||||
|
||||
<!-- truncate -->
|
||||
|
||||
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
|
||||
|
||||
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
|
||||
|
||||
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
|
||||
|
||||
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
|
||||
|
||||
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
|
||||
|
||||
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
|
||||
|
||||
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
|
||||
|
||||
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
|
||||
|
||||
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
|
||||
|
||||
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
|
||||
|
||||
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
|
||||
|
||||
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
|
||||
|
||||
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
|
||||
|
||||
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
|
||||
|
||||
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
|
||||
|
||||
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
|
||||
|
Before Width: | Height: | Size: 94 KiB |
@@ -1,29 +0,0 @@
|
||||
---
|
||||
slug: welcome
|
||||
title: Welcome
|
||||
authors: [slorber, yangshun]
|
||||
tags: [facebook, hello, docusaurus]
|
||||
---
|
||||
|
||||
[Docusaurus blogging features](https://docusaurus.io/docs/blog) are powered by the [blog plugin](https://docusaurus.io/docs/api/plugins/@docusaurus/plugin-content-blog).
|
||||
|
||||
Here are a few tips you might find useful.
|
||||
|
||||
<!-- truncate -->
|
||||
|
||||
Simply add Markdown files (or folders) to the `blog` directory.
|
||||
|
||||
Regular blog authors can be added to `authors.yml`.
|
||||
|
||||
The blog post date can be extracted from filenames, such as:
|
||||
|
||||
- `2019-05-30-welcome.md`
|
||||
- `2019-05-30-welcome/index.md`
|
||||
|
||||
A blog post folder can be convenient to co-locate blog post images:
|
||||
|
||||

|
||||
|
||||
The blog supports tags as well!
|
||||
|
||||
**And if you don't want a blog**: just delete this directory, and use `blog: false` in your Docusaurus config.
|
||||
37
blog/2023-09-19-tlsnotary-updates/convert_diagrams.sh
Executable file
@@ -0,0 +1,37 @@
|
||||
#!/bin/bash
|
||||
|
||||
FORMAT="svg"
|
||||
|
||||
# Convert all diagrams in the diagrams folder to pngs in the mdbook src/png-diagrams folder
|
||||
SOURCE_DIR=$(dirname "$0")
|
||||
TARGET_DIR=$(realpath "$(dirname "$0")/")
|
||||
|
||||
OS=$(uname)
|
||||
case "$OS" in
|
||||
"Darwin") # Mac
|
||||
DRAW_IO="/Applications/draw.io.app/Contents/MacOS/draw.io"
|
||||
;;
|
||||
"Linux") # Linux
|
||||
DRAW_IO="drawio"
|
||||
;;
|
||||
esac
|
||||
|
||||
if ! command -v "$DRAW_IO" &>/dev/null; then
|
||||
echo "Error: draw.io executable not found. Please install draw.io and make sure it's in your PATH."
|
||||
exit 1
|
||||
fi
|
||||
|
||||
pushd "$SOURCE_DIR" >/dev/null
|
||||
for page in $(seq 0 3); do
|
||||
SOURCE="diagrams.drawio"
|
||||
TARGET="${TARGET_DIR}/${SOURCE%.drawio}_${page}.${FORMAT}"
|
||||
# Only convert if the source is more recent than the target
|
||||
if [[ "$SOURCE" -nt "${TARGET}" ]]; then
|
||||
"$DRAW_IO" --export --page-index ${page} --format ${FORMAT} --scale 2.5 -o "${TARGET}" "${SOURCE}"
|
||||
if [ "$FORMAT" = "svg" ]; then
|
||||
# add styling for dark mode (https://github.com/jgraph/drawio-github/blob/master/DARK-MODE.md)
|
||||
sed -i -e "s$<defs/>$<defs><style type=\"text/css\"> @media (prefers-color-scheme: dark) { svg { filter: invert(93%) hue-rotate(180deg); background-color: transparent !important; } image { filter: invert(100%) hue-rotate(180deg) saturate(1.25); } } </style></defs>$" "${TARGET}"
|
||||
fi
|
||||
fi
|
||||
done
|
||||
popd >/dev/null
|
||||
248
blog/2023-09-19-tlsnotary-updates/diagrams.drawio
Normal file
@@ -0,0 +1,248 @@
|
||||
<mxfile host="Electron" modified="2023-09-13T08:13:23.040Z" agent="Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/21.6.8 Chrome/114.0.5735.289 Electron/25.5.0 Safari/537.36" version="21.6.8" etag="v2Ntmq55qNim5saO4JRN" type="device" pages="4">
|
||||
<diagram name="Simple Overview" id="1K7dc4YacWnzJAUZZLNN">
|
||||
<mxGraphModel dx="759" dy="1200" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="4681" pageHeight="3300" math="0" shadow="0">
|
||||
<root>
|
||||
<mxCell id="0" />
|
||||
<mxCell id="1" parent="0" />
|
||||
<mxCell id="FO-Th2_5Wnf5gWxcU9zP-1" value="Prover" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;shadow=1;fontStyle=1" parent="1" vertex="1">
|
||||
<mxGeometry x="620" y="250" width="80" height="80" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="FO-Th2_5Wnf5gWxcU9zP-2" value="Server" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;shadow=1;fontStyle=1" parent="1" vertex="1">
|
||||
<mxGeometry x="460" y="250" width="80" height="80" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="FO-Th2_5Wnf5gWxcU9zP-3" value="Verifier" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;shadow=1;fontStyle=1" parent="1" vertex="1">
|
||||
<mxGeometry x="780" y="250" width="80" height="80" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="uXpAJVi9-J_ntRPUj_sc-1" value="" style="endArrow=classic;startArrow=classic;html=1;rounded=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" parent="1" target="FO-Th2_5Wnf5gWxcU9zP-1" edge="1">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="540" y="290" as="sourcePoint" />
|
||||
<mxPoint x="-180" y="290" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="uXpAJVi9-J_ntRPUj_sc-2" value="<font style="font-size: 12px;">TLS</font>" style="whiteSpace=wrap;html=1;fillColor=none;strokeColor=none;fontSize=11;" parent="1" vertex="1">
|
||||
<mxGeometry x="550" y="274" width="50" height="10" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="uXpAJVi9-J_ntRPUj_sc-3" value="" style="endArrow=classic;startArrow=classic;html=1;rounded=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;exitX=1;exitY=0.5;exitDx=0;exitDy=0;" parent="1" source="FO-Th2_5Wnf5gWxcU9zP-1" target="FO-Th2_5Wnf5gWxcU9zP-3" edge="1">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="540" y="300" as="sourcePoint" />
|
||||
<mxPoint x="630" y="300" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="uXpAJVi9-J_ntRPUj_sc-4" value="<font style="font-size: 12px;">MPC</font>" style="edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];" parent="uXpAJVi9-J_ntRPUj_sc-3" vertex="1" connectable="0">
|
||||
<mxGeometry x="0.025" y="1" relative="1" as="geometry">
|
||||
<mxPoint x="-1" y="-10" as="offset" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="4YpQ24D73eh0dbAzUkyk-1" value="Data" style="whiteSpace=wrap;html=1;shape=mxgraph.basic.document;fontSize=10;shadow=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="560" y="300" width="50" height="58" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="4YpQ24D73eh0dbAzUkyk-2" value="<font style="font-size: 10px;">Redacted Data</font>" style="whiteSpace=wrap;html=1;shape=mxgraph.basic.document;fontSize=11;shadow=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="720" y="300" width="50" height="58" as="geometry" />
|
||||
</mxCell>
|
||||
</root>
|
||||
</mxGraphModel>
|
||||
</diagram>
|
||||
<diagram id="kcIGn_kX_1L25iIxUXLg" name="Notaries">
|
||||
<mxGraphModel dx="1757" dy="829" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="850" pageHeight="1100" math="0" shadow="0">
|
||||
<root>
|
||||
<mxCell id="0" />
|
||||
<mxCell id="1" parent="0" />
|
||||
<mxCell id="GdnXkJGOJiVmK7E47u4y-44" value="" style="shape=cylinder3;whiteSpace=wrap;html=1;boundedLbl=1;backgroundOutline=1;size=15;dashed=1;dashPattern=8 8;" parent="1" vertex="1">
|
||||
<mxGeometry x="170" y="220" width="140" height="285" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="EZAqd18MQriHtEKbU3QA-1" value="Prover" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;shadow=1;fontStyle=1" parent="1" vertex="1">
|
||||
<mxGeometry x="200" y="260" width="80" height="80" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="EZAqd18MQriHtEKbU3QA-2" value="Server" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;shadow=1;fontStyle=1" parent="1" vertex="1">
|
||||
<mxGeometry x="30" y="262" width="80" height="80" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="EZAqd18MQriHtEKbU3QA-3" value="Notary" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;shadow=1;fontStyle=1" parent="1" vertex="1">
|
||||
<mxGeometry x="200" y="410" width="80" height="80" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="GdnXkJGOJiVmK7E47u4y-40" value="blindly<br>signed<br style="font-size: 11px;">data" style="whiteSpace=wrap;html=1;shape=mxgraph.basic.document;fontSize=11;shadow=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="251" y="346" width="50" height="58" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="GdnXkJGOJiVmK7E47u4y-43" value="Verifier" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;shadow=1;fontStyle=1" parent="1" vertex="1">
|
||||
<mxGeometry x="410" y="260" width="80" height="80" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="GdnXkJGOJiVmK7E47u4y-45" value="" style="endArrow=classic;startArrow=classic;html=1;rounded=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;exitX=1.028;exitY=0.462;exitDx=0;exitDy=0;exitPerimeter=0;" parent="1" source="EZAqd18MQriHtEKbU3QA-2" target="EZAqd18MQriHtEKbU3QA-1" edge="1">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="350" y="490" as="sourcePoint" />
|
||||
<mxPoint x="400" y="440" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="GdnXkJGOJiVmK7E47u4y-46" value="TLS" style="whiteSpace=wrap;html=1;fillColor=none;strokeColor=none;fontSize=11;" parent="1" vertex="1">
|
||||
<mxGeometry x="118" y="284" width="60" height="10" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="GdnXkJGOJiVmK7E47u4y-47" value="" style="endArrow=classic;html=1;rounded=0;" parent="1" source="EZAqd18MQriHtEKbU3QA-3" target="EZAqd18MQriHtEKbU3QA-1" edge="1">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="350" y="490" as="sourcePoint" />
|
||||
<mxPoint x="400" y="440" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="vS6lQRuDm8DtBRq3Yqvl-2" value="notarize" style="edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];" parent="GdnXkJGOJiVmK7E47u4y-47" vertex="1" connectable="0">
|
||||
<mxGeometry x="-0.0599" y="2" relative="1" as="geometry">
|
||||
<mxPoint x="-21" y="1" as="offset" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="GdnXkJGOJiVmK7E47u4y-48" value="redacted<br style="font-size: 11px;">data" style="whiteSpace=wrap;html=1;shape=mxgraph.basic.document;fontSize=11;shadow=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="330" y="310" width="50" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="GdnXkJGOJiVmK7E47u4y-49" value="" style="endArrow=classic;html=1;rounded=0;" parent="1" source="EZAqd18MQriHtEKbU3QA-1" target="GdnXkJGOJiVmK7E47u4y-43" edge="1">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="350" y="490" as="sourcePoint" />
|
||||
<mxPoint x="400" y="440" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="GdnXkJGOJiVmK7E47u4y-50" value="<span style="font-family: Helvetica; font-size: 11px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: center; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; float: none; display: inline !important;">selective disclosure</span>" style="text;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="330" y="262" width="50" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="GdnXkJGOJiVmK7E47u4y-53" value="<span style="font-family: Helvetica; font-size: 11px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; float: none; display: inline !important;">MPC</span>" style="text;whiteSpace=wrap;html=1;align=center;verticalAlign=middle;" parent="1" vertex="1">
|
||||
<mxGeometry x="177" y="215" width="125" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="GdnXkJGOJiVmK7E47u4y-54" value="1" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;fontSize=10;" parent="1" vertex="1">
|
||||
<mxGeometry x="141.5" y="268" width="13" height="13" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="GdnXkJGOJiVmK7E47u4y-55" value="2" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;fontSize=10;" parent="1" vertex="1">
|
||||
<mxGeometry x="210" y="357" width="13" height="13" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="GdnXkJGOJiVmK7E47u4y-56" value="3" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;fontSize=10;" parent="1" vertex="1">
|
||||
<mxGeometry x="344.5" y="256" width="13" height="13" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="GdnXkJGOJiVmK7E47u4y-58" value="4" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;fontSize=10;" parent="1" vertex="1">
|
||||
<mxGeometry x="429" y="316.5" width="13" height="13" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="GdnXkJGOJiVmK7E47u4y-59" value="<span style="font-family: Helvetica; font-size: 11px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; float: none; display: inline !important;">verify</span>" style="text;whiteSpace=wrap;html=1;align=center;verticalAlign=middle;" parent="1" vertex="1">
|
||||
<mxGeometry x="438" y="313.25" width="40" height="19.5" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="_06KIDZZ9NYgVlEzEhfi-3" value="" style="endArrow=classic;html=1;rounded=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;edgeStyle=elbowEdgeStyle;elbow=vertical;exitX=0;exitY=0.5;exitDx=0;exitDy=0;" parent="1" source="EZAqd18MQriHtEKbU3QA-1" target="EZAqd18MQriHtEKbU3QA-3" edge="1">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="180" y="330" as="sourcePoint" />
|
||||
<mxPoint x="110" y="354" as="targetPoint" />
|
||||
<Array as="points">
|
||||
<mxPoint x="180" y="370" />
|
||||
</Array>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
</root>
|
||||
</mxGraphModel>
|
||||
</diagram>
|
||||
<diagram name="AES" id="mOAZV9J1HD8CvUNmk5yk">
|
||||
<mxGraphModel dx="759" dy="1200" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="4681" pageHeight="3300" math="0" shadow="0">
|
||||
<root>
|
||||
<mxCell id="0" />
|
||||
<mxCell id="1" parent="0" />
|
||||
<mxCell id="imKlexnwQG8ijFvp7Sfa-1" style="html=1;fontSize=12;rounded=0;entryX=0.013;entryY=0.284;entryDx=0;entryDy=0;entryPerimeter=0;" parent="1" edge="1">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="628.83" y="180.12" as="sourcePoint" />
|
||||
<mxPoint x="701.9999999999999" y="180" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="imKlexnwQG8ijFvp7Sfa-2" value="Key share" style="edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];fontSize=11;" parent="imKlexnwQG8ijFvp7Sfa-1" vertex="1" connectable="0">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint y="-11" as="offset" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="imKlexnwQG8ijFvp7Sfa-12" style="rounded=0;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;fontSize=12;" parent="1" source="imKlexnwQG8ijFvp7Sfa-13" edge="1">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="747" y="270" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="imKlexnwQG8ijFvp7Sfa-14" style="html=1;fontSize=12;rounded=0;entryX=0.013;entryY=0.718;entryDx=0;entryDy=0;entryPerimeter=0;" parent="1" edge="1">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="629" y="220" as="sourcePoint" />
|
||||
<mxPoint x="702.1699999999998" y="220.25999999999993" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="imKlexnwQG8ijFvp7Sfa-15" value="<font style="font-size: 11px;">Plaintext</font>" style="edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];fontSize=11;" parent="imKlexnwQG8ijFvp7Sfa-14" vertex="1" connectable="0">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint y="-10" as="offset" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="imKlexnwQG8ijFvp7Sfa-4" value="Prover" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;shadow=1;fontStyle=1" parent="1" vertex="1">
|
||||
<mxGeometry x="554" y="160" width="80" height="80" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="imKlexnwQG8ijFvp7Sfa-13" value="<font style="font-size: 12px;">AES</font>" style="rounded=1;whiteSpace=wrap;html=1;fontSize=10;shadow=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="702" y="165" width="90" height="70" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="imKlexnwQG8ijFvp7Sfa-18" style="html=1;fontSize=12;rounded=0;entryX=0.013;entryY=0.284;entryDx=0;entryDy=0;entryPerimeter=0;startArrow=classic;startFill=1;endArrow=none;endFill=0;" parent="1" edge="1">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="792" y="199.98" as="sourcePoint" />
|
||||
<mxPoint x="865.1699999999996" y="199.85999999999999" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="imKlexnwQG8ijFvp7Sfa-19" value="<style="font-size: 11px;">Key share</font>" style="edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];fontSize=11;" parent="imKlexnwQG8ijFvp7Sfa-18" vertex="1" connectable="0">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint y="-11" as="offset" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="imKlexnwQG8ijFvp7Sfa-7" value="Verifier" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;shadow=1;fontStyle=1" parent="1" vertex="1">
|
||||
<mxGeometry x="859" y="160" width="80" height="80" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="imKlexnwQG8ijFvp7Sfa-22" value="<span style="font-family: Helvetica; font-size: 11px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; float: none; display: inline !important;">Ciphertext</span>" style="text;whiteSpace=wrap;html=1;fontSize=11;align=center;" parent="1" vertex="1">
|
||||
<mxGeometry x="717" y="270" width="60" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="ugwm5q7jo5HeXQWcRzf4-1" value="<span style="font-family: Helvetica; font-size: 11px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; float: none; display: inline !important;">Garbled Circuit</span>" style="text;whiteSpace=wrap;html=1;fontSize=11;align=center;" parent="1" vertex="1">
|
||||
<mxGeometry x="707" y="140" width="80" height="20" as="geometry" />
|
||||
</mxCell>
|
||||
</root>
|
||||
</mxGraphModel>
|
||||
</diagram>
|
||||
<diagram name="Proxy mode" id="QbUhlncA6uj8AHGzzR_Y">
|
||||
<mxGraphModel dx="759" dy="1200" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="4681" pageHeight="3300" math="0" shadow="0">
|
||||
<root>
|
||||
<mxCell id="0" />
|
||||
<mxCell id="1" parent="0" />
|
||||
<mxCell id="csndq4Mb--6Wtup8P-S2-3" style="edgeStyle=orthogonalEdgeStyle;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;fontSize=12;rounded=0;" parent="1" source="bSltM_TDOgC1kJBMOoSB-1" target="csndq4Mb--6Wtup8P-S2-1" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="csndq4Mb--6Wtup8P-S2-5" value="Record" style="edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];fontSize=12;" parent="csndq4Mb--6Wtup8P-S2-3" vertex="1" connectable="0">
|
||||
<mxGeometry x="-0.48" relative="1" as="geometry">
|
||||
<mxPoint x="-30" y="-11" as="offset" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="bSltM_TDOgC1kJBMOoSB-1" value="Verifier" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;shadow=1;fontStyle=1" parent="1" vertex="1">
|
||||
<mxGeometry x="700" y="150" width="80" height="80" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="bSltM_TDOgC1kJBMOoSB-2" value="Server" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;shadow=1;fontStyle=1" parent="1" vertex="1">
|
||||
<mxGeometry x="540" y="150" width="80" height="80" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="csndq4Mb--6Wtup8P-S2-2" style="edgeStyle=orthogonalEdgeStyle;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;entryX=1;entryY=0.5;entryDx=0;entryDy=0;fontSize=12;rounded=0;" parent="1" source="bSltM_TDOgC1kJBMOoSB-3" target="csndq4Mb--6Wtup8P-S2-1" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="csndq4Mb--6Wtup8P-S2-6" value="Key" style="edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];fontSize=12;" parent="csndq4Mb--6Wtup8P-S2-2" vertex="1" connectable="0">
|
||||
<mxGeometry x="-0.4889" relative="1" as="geometry">
|
||||
<mxPoint x="20" y="2" as="offset" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="bSltM_TDOgC1kJBMOoSB-3" value="Prover" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;shadow=1;fontStyle=1" parent="1" vertex="1">
|
||||
<mxGeometry x="860" y="150" width="80" height="80" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="bSltM_TDOgC1kJBMOoSB-4" value="" style="endArrow=classic;startArrow=classic;html=1;rounded=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" parent="1" target="bSltM_TDOgC1kJBMOoSB-1" edge="1">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="620" y="190" as="sourcePoint" />
|
||||
<mxPoint x="-100" y="190" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="bSltM_TDOgC1kJBMOoSB-6" value="" style="endArrow=classic;startArrow=classic;html=1;rounded=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;exitX=1;exitY=0.5;exitDx=0;exitDy=0;" parent="1" source="bSltM_TDOgC1kJBMOoSB-1" target="bSltM_TDOgC1kJBMOoSB-3" edge="1">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="620" y="200" as="sourcePoint" />
|
||||
<mxPoint x="710" y="200" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="bSltM_TDOgC1kJBMOoSB-8" value="Encrypted Data" style="whiteSpace=wrap;html=1;shape=mxgraph.basic.document;fontSize=10;shadow=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="750" y="270" width="50" height="58" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="bSltM_TDOgC1kJBMOoSB-9" value="<font style="font-size: 10px;">Redacted Data</font>" style="whiteSpace=wrap;html=1;shape=mxgraph.basic.document;fontSize=11;shadow=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="820" y="300" width="50" height="58" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="csndq4Mb--6Wtup8P-S2-4" style="edgeStyle=orthogonalEdgeStyle;rounded=0;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;entryPerimeter=0;fontSize=12;" parent="1" source="csndq4Mb--6Wtup8P-S2-1" target="bSltM_TDOgC1kJBMOoSB-9" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="csndq4Mb--6Wtup8P-S2-1" value="<font style="font-size: 12px;">ZKP</font>" style="rounded=1;whiteSpace=wrap;html=1;fontSize=10;shadow=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="820" y="240" width="50" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
</root>
|
||||
</mxGraphModel>
|
||||
</diagram>
|
||||
</mxfile>
|
||||
BIN
blog/2023-09-19-tlsnotary-updates/diagrams_0.png
Normal file
|
After Width: | Height: | Size: 47 KiB |
3
blog/2023-09-19-tlsnotary-updates/diagrams_0.svg
Normal file
|
After Width: | Height: | Size: 10 KiB |
BIN
blog/2023-09-19-tlsnotary-updates/diagrams_0_dark.png
Normal file
|
After Width: | Height: | Size: 36 KiB |
BIN
blog/2023-09-19-tlsnotary-updates/diagrams_1.png
Normal file
|
After Width: | Height: | Size: 128 KiB |
3
blog/2023-09-19-tlsnotary-updates/diagrams_1.svg
Normal file
|
After Width: | Height: | Size: 21 KiB |
BIN
blog/2023-09-19-tlsnotary-updates/diagrams_1_dark.png
Normal file
|
After Width: | Height: | Size: 92 KiB |
BIN
blog/2023-09-19-tlsnotary-updates/diagrams_2.png
Normal file
|
After Width: | Height: | Size: 74 KiB |
3
blog/2023-09-19-tlsnotary-updates/diagrams_2.svg
Normal file
|
After Width: | Height: | Size: 11 KiB |
BIN
blog/2023-09-19-tlsnotary-updates/diagrams_2_dark.png
Normal file
|
After Width: | Height: | Size: 51 KiB |
BIN
blog/2023-09-19-tlsnotary-updates/diagrams_3.png
Normal file
|
After Width: | Height: | Size: 66 KiB |
3
blog/2023-09-19-tlsnotary-updates/diagrams_3.svg
Normal file
|
After Width: | Height: | Size: 12 KiB |
BIN
blog/2023-09-19-tlsnotary-updates/diagrams_3_dark.png
Normal file
|
After Width: | Height: | Size: 51 KiB |
207
blog/2023-09-19-tlsnotary-updates/index.md
Normal file
@@ -0,0 +1,207 @@
|
||||
---
|
||||
title: TLSNotary Updates
|
||||
authors: [sinu]
|
||||
tags: [mpc-tls, proxy]
|
||||
---
|
||||
|
||||
# Introduction
|
||||
|
||||
TLSNotary is a protocol which allows people to export data from any web application and prove facts about it to a third-party in a privacy preserving way.
|
||||
|
||||
<!-- truncate -->
|
||||
|
||||
It enables privacy-preserving **data provenance and data portability**, empowering users to share their data with others as they see fit.
|
||||
|
||||
To do this, TLSNotary leverages secure multi-party computation (MPC) to authenticate data communicated between a Prover and a TLS-enabled web server, as depicted in Figure 1.
|
||||
|
||||
|
||||
|  |
|
||||
| :----------------------------------: |
|
||||
| Figure 1: Simple Overview |
|
||||
|
||||
|
||||
Importantly, the protocol supports *selective disclosure* of data to a Verifier. This way the Prover can keep secrets hidden, such as passwords or any other information not necessary to prove some specific statement.
|
||||
|
||||
Selective disclosure may involve simple redactions, or more advanced techniques such as a zero-knowledge proof that a number in the data is within a specific range, without disclosing its exact value.
|
||||
|
||||
|  |
|
||||
| :----------------------------: |
|
||||
| Figure 2: Selective Disclosure |
|
||||
|
||||
The TLSNotary protocol presents a compelling alternative to other solutions for sharing data for the following reasons:
|
||||
|
||||
- It does not require the Server to integrate data sharing into its application, such as OAuth.
|
||||
- The act of disclosing data to a third-party is not known to the Server, nor can it be practically censored.
|
||||
- The Prover has very fine-grained control over *exactly* what data is disclosed to the Verifier.
|
||||
- The Verifier does not need to trust that the Prover is honest, the authenticity of the data comes with cryptographic assurances.
|
||||
|
||||
For more introductory information, see our [website](https://tlsnotary.org) which also includes some example use-cases and a link to our (work-in-progress) documentation.
|
||||
|
||||
TLSNotary is a project under the [Privacy & Scaling Explorations (PSE)](https://pse.dev) team at the Ethereum Foundation. PSE is a multi-disciplinary team exploring how programmable cryptography can be applied to enhance privacy and scale trust-minimized systems.
|
||||
|
||||
## General-purpose Verifier: Notary
|
||||
|
||||
We envision an ecosystem of general-purpose verifiers, called Notaries, which help users take back control of their data in a privacy preserving way.
|
||||
|
||||
We find it important that our protocol supports hiding the identity of the Server, as well as hiding virtually *all information* about the application the Prover is interacting with.
|
||||
|
||||
A Notary is a special kind of verifier which allows the Prover to do just that. It decouples the process of proving the authenticity of data from the process of selective disclosure. Notaries being completely blind of context preserves neutrality, and helps mitigate bad incentives or censorship which could arise in circumstances with an application-specific Verifier.
|
||||
|
||||
Of course, we still need to support selective disclosure of the data to _someone_. How do we do that if a Notary is to know nothing? Fortunately this is still possible to do in a relatively simple way.
|
||||
|
||||
|
||||
|
||||
|  |
|
||||
| :---------------------------: |
|
||||
| Figure 3: Notaries |
|
||||
|
||||
|
||||
During the MPC, efficient commitments to the data are generated and we can reuse them for selective disclosure. The Notary simply signs an attestation which includes these commitments, as well as a commitment to the Server identity, which the Prover can store and carry around (in a data backpack? 🎒). Later the Prover can use this attestation to selectively disclose data to someone else.
|
||||
|
||||
This enables users to privately export data with the help of a neutral third-party, receiving an attestation to its authenticity. Using these attestations, other verifiers can accept proofs if they consider the attesting Notary trustworthy. Of course, a verifier can require attestations from multiple Notaries, which reduces to a 1-of-N trust assumption!
|
||||
|
||||
# How It Works
|
||||
|
||||
As mentioned in the introduction, TLSNotary leverages MPC to provide cryptographic assurances that the Prover can not cheat or lie about the communications with the Server. Additionally, the Verifier can not tamper with the connection as to leak secrets or cause malicious state updates within the application. In other words, the protocol is designed to be [malicious secure](https://en.wikipedia.org/wiki/Secure_multi-party_computation#Security_definitions) for both parties.
|
||||
|
||||
The Prover and Verifier securely secret-share the TLS session keys such that neither party is able to unilaterally send or receive messages from the Server. This ensures the authenticity of data, while hiding the plaintext from the Verifier.
|
||||
|
||||
Under the hood we employ primitives such as [Garbled Circuits](https://en.wikipedia.org/wiki/Garbled_circuit), [Oblivious Transfer](https://en.wikipedia.org/wiki/Oblivious_transfer#1%E2%80%932_oblivious_transfer) and Oblivious Linear Evaluation (OLE) to do this. These primitives have historically suffered from high resource costs in terms of both compute and bandwidth requirements, particularly in adversarial settings which require malicious security. Fortunately, over the past decade or so, there have been many breakthroughs in concrete efficiency which have brought MPC closer to a practical reality for many applications.
|
||||
|
||||
Even so, implementing a protocol like TLSNotary pushes up against the bounds of practical feasability in the malicious setting.
|
||||
|
||||
For example, the dominant cost of our protocol comes from performing binary computation using Garbled Circuits. Modern techniques such as free-XOR[^1] and half-gates[^2] still comes with a cost of ~200kB of communication to evaluate a single AES block (the most widely used cipher in TLS) in the semi-honest setting. Extrapolating, it costs ~50MB to encrypt only 4kB of data! Doing so with malicious security can easily add an order of magnitude to this cost figure, rendering such pursuits practically infeasible.
|
||||
|
||||
|  |
|
||||
| :-------------------------------------: |
|
||||
| Figure 4: 2PC AES with Garbled Circuits |
|
||||
|
||||
|
||||
Naturally, we require the TLSNotary protocol to be secure against malicious adversaries. We must find a way to make it malicious secure, but malicious security is expensive. Wat do?
|
||||
|
||||
Before we get into how we solved this problem for our protocol, we wanted to highlight a viable alternative approach which we decided not to take.
|
||||
|
||||
## Alternative: Proxy Mode
|
||||
|
||||
An alternative approach to this problem is to side-step the need to use expensive MPC techniques and stick to cheaper approaches which operate in the zero-knowledge setting. Or more specifically, the setting where only 1 party has private inputs (the Prover).
|
||||
|
||||
Rather than having the Prover connect directly to the Server and operating the connection cooperatively with the Verifier, instead, the Verifier is situated in-between the Prover and Server, as shown in Figure 5.
|
||||
|
||||
|  |
|
||||
| :-----------------------------: |
|
||||
| Figure 5: Proxy Mode |
|
||||
|
||||
In this configuration, the Verifier acts as a proxy and simply records the encrypted data being communicated between the Prover and Server. Afterwards, the Prover can selectively disclose parts of the data with a zero-knowledge proof using their TLS keys as private inputs.
|
||||
|
||||
This approach is quite viable and is one which other teams are pursuing. However, it comes with a different set of security assumptions. Rather than relying just on cryptographic assumptions, the proxy approach also makes _network topology_ assumptions. It assumes that the Verifier has a direct connection to the Server, and that a malicious Prover can not bypass or otherwise insert themselves in-between the Verifier and Server. As the Prover holds the full TLS session keys, if they are able to invalidate this assumption it completely breaks the integrity of the protocol.
|
||||
|
||||
As explained in the above [section on Notaries](#General-purpose-Verifier-Notary), we find the ability to hide the identity of the Server from the Verifier important. This is clearly not possible with this model.
|
||||
|
||||
To be fair, there are viable mitigations to network attacks and in many scenarios these assumptions are acceptable. We look forward to seeing what is unlocked with the application of this model, as the simplicity and efficiency of this approach is enticing.
|
||||
|
||||
However, we decided to pursue the MPC approach and found a way to practically achieve malicious security without making such network assumptions.
|
||||
|
||||
## Achieving Practicality with MPC
|
||||
|
||||
A key observation enabling our approach is that all private inputs from the Verifier in the MPC are ephemeral. That is, after the TLS connection has been terminated the Verifier can reveal their share of the TLS session keys to the Prover without consequence. Moreover, multiple bits of the Verifier's inputs can be leaked prematurely without compromising security of the overall protocol.
|
||||
|
||||
Malicious secure protocols typically aim to prevent *any* leakage of any parties inputs, employing techniques such as authenticated garbling or variants of cut-and-choose, which add significant compute and/or communication overhead.
|
||||
|
||||
For our needs, we implemented a novel\* variant of so-called Dual Execution, which we dubbed Dual Execution with Asymmetric Privacy (DEAP). Is there a better name for it? Probably. Nonetheless, you can read our informal [explanation of it here](https://docs.tlsnotary.org/mpc/deap.html).
|
||||
|
||||
The jist of it is this: During the TLS session one party, the Prover, acts as the Garbler while also committing to their inputs prior to learning the output of the circuit. Later, these commitments are used to prove the Prover acted honestly (or at least leakage was statistically bounded), and aborting otherwise.
|
||||
|
||||
Some key take aways of this approach:
|
||||
|
||||
- Garbled circuits on their own are secure against a malicious evaluator. The Verifier, acting as the evaluator, can not cheat or otherwise corrupt the output without detection. This ensures the privacy and integrity of the data to the Prover during the TLS session.
|
||||
- In the final phase of DEAP the Verifier opens all their inputs to the Prover. This allows the Prover to check the Verifier has behaved honestly and ensures *no leakage* of the private data, contrary to the leakage inherent in the equality check of standard Dual Execution.
|
||||
|
||||
Exploiting the rather niche privacy requirements of our protocol allows us to achieve malicious security without the typical overhead that comes with it.
|
||||
|
||||
In fact, the final phase of DEAP reduces to the much cheaper zero-knowledge scenario. While we currently use garbled circuits for this ZK phase, as pioneered in JKO13[^4], we can take advantage of even more efficient ZK proof systems. We're planning on switching to new methods known as VOLE-based IZK[5], which boast over 100x reduction in communication cost compared to garbled circuits. Doing so will make our protocol marginally more expensive than the semi-honest security setting.
|
||||
|
||||
Using the efficient VOLE-based IZK in combination with the simple trick of deferring decryption until after the TLS connection is closed, **TLSNotary will achieve efficiency similar to that of the proxy mode configuration**. Specifically, we do not need to utilize expensive Garbled Circuits for proving Server response data, which is typically the dominant cost.
|
||||
|
||||
\* This approach has recently also been articulated by XYWY23[^3]
|
||||
|
||||
## A note on Oracles
|
||||
|
||||
While the TLSNotary protocol can be used to construct a [blockchain oracle protocol](https://ethereum.org/en/developers/docs/oracles/), that is not its primary purpose, especially in regards to _public_ data feeds. TLSNotary is best suited for contexts which require proving of _private_ data which is typically only accessible to an authenticated user. Moreover, because it is an _interactive_ protocol, it must be run by an off-chain Verifier. Bringing data on-chain still requires a trust assumption, ie an attestation from a trusted party(s).
|
||||
|
||||
# Where We Are
|
||||
|
||||
An alpha version of the TLSNotary protocol is [available for testing](https://github.com/tlsnotary/tlsn). We welcome folks to start playing around with it, including trying to break it! We have some examples available and a quick start to get you running.
|
||||
|
||||
The underlying MPC primitives are contained in a separate project named [`mpz`](https://github.com/privacy-scaling-explorations/mpz) which is intended to evolve into a general-purpose MPC stack.
|
||||
|
||||
Both codebases are 100% Rust 🦀 and compile to WASM targets with an eye on deployment into browser environments.
|
||||
|
||||
All our code is and always will be open source! Dual-licensed under Apache 2 and MIT, at your choice.
|
||||
|
||||
We've invested effort into making sure our code is modular and capable of evolving. We hope that others may find some of the components independently interesting and useful. Contributions are welcome!
|
||||
|
||||
## Current Limitations
|
||||
|
||||
While we're excited to start experimenting with TLSNotary, we acknowledge the work we have ahead of us.
|
||||
|
||||
Below are some important points to consider:
|
||||
|
||||
- Our protocol currently lacks security proofs and has not been audited.
|
||||
- It is functional but under active development.
|
||||
- Until we integrate VOLE-based IZK, it is only practical to prove data volumes in the **low kB** range (largely dependent on network bandwidth between the Prover and Verifier). This works for many use-cases involving API queries for succinct representations of data, eg. identity information.
|
||||
- Selective disclosure *tooling* is currently limited to simple redactions.
|
||||
|
||||
# Roadmap
|
||||
|
||||
We have a number of items on our roadmap that we are tackling across a few different areas.
|
||||
|
||||
## Core Protocol (MPC TLS)
|
||||
|
||||
In addition to standard things like better tests, audits and documentation, we have a number of improvements in mind for our core protocol:
|
||||
|
||||
- The security proofs for the protocol we use for OT extension, KOS15[^6], was called into question around the time we adopted and implemented it. We're due to replace it with the more recent SoftSpokenOT protocol, Roy22[^7]
|
||||
- Implement and integrate VOLE-based IZK. As mentioned earlier, this is a critical piece which will significantly boost efficiency and make proving larger data volumes (MBs) practical.
|
||||
- Improve the P256 point-addition protocol used in the ECDHE key exchange, as well as the protocol for GHASH used in AES-GCM. We implement both using Gilboa-style (Gil99[^8]) OLE with additional consistency checks, but a more efficient approach was recently demonstrated by XYWY23[^ 3].
|
||||
- Add support for the ChaCha20-Poly1305 ciphersuite. ChaCha20 has ~50% lower communication cost compared to AES when executed in MPC.
|
||||
- TLS 1.3 support.
|
||||
|
||||
## Selective Disclosure
|
||||
|
||||
Being able to prove the authenticity of data is one thing, but it's important that selective disclosure tooling is available for developers to easily build privacy preserving applications.
|
||||
|
||||
Below are some items we will be prioritizing:
|
||||
|
||||
- Gadgets and examples for using the commitments with SNARKs. We intend to make it easy to integrate SNARKs using tooling such as Circom.
|
||||
- Support proving arbitrary statements to the Verifier with IZK. Presently, we only provide tools for simple redactions out of the box.
|
||||
- Tooling for common application contexts, eg. HTTP, and JSON. Web applications do not represent data in formats friendly to ZK proofs, so it can be quite burdensome to work with. Developers need good abstractions at their disposal for working with these formats.
|
||||
|
||||
## Infrastructure
|
||||
|
||||
### Reference Notary Server
|
||||
|
||||
We're building a reference [Notary server implementation](https://github.com/tlsnotary/notary-server) which enables anyone to spin up a Notary and start attesting!
|
||||
|
||||
This implementation will also serve as a reference for building application-specific verifiers.
|
||||
|
||||
### Browser extension
|
||||
|
||||
Desktop applications have mostly fallen out of style, which is a shame because building cryptography applications in the browser is *difficult*! But we work with what we've got. So we're building a [web extension](https://github.com/tlsnotary/tlsn-extension) to let people run the TLSNotary protocol in their browser using WASM.
|
||||
|
||||
It is still in very early stages, but the plan is to provide some UI conveniences for users, and a plugin system for developers to build proving flows in a sandboxed environment. We envision an open ecosystem of these plugins which users can select depending on their needs. This no doubt will come with some security challenges!
|
||||
|
||||
# Join Us!
|
||||
|
||||
Come find us in our [public Discord server](https://discord.gg/9XwESXtcN7), and tune in for further updates on [Twitter](https://twitter.com/tlsnotary).
|
||||
|
||||
We're looking forward to seeing all the great privacy-centric applications folks can come up with!
|
||||
|
||||
# References
|
||||
|
||||
[^1]: Kolesnikov, V., Schneider, T.: Improved garbled circuit: Free XOR gates and applications. In: ICALP 2008, Part II (2008)
|
||||
[^2]: Zahur, S., Rosulek, M., and Evans, D.: Two Halves Make a Whole Reducing Data Transfer in Garbled Circuits using Half Gates. In: 34th Eurocrypt, Sofia, Bulgaria, April 2015
|
||||
[^3]: Xie, X., Yang, K., Wang, X., Yu, Y.: Lightweight Authentication of Web Data via Garble-Then-Prove
|
||||
[^4]: Jawurek, M., Kerschbaum, F., Orlandi, C.: Zero-Knowledge Using Garbled Circuits or How To Prove Non-Algebraic Statements Efficiently.
|
||||
[^5]: Baum, C., Dittmer, S., Scholl, P., Wang, X.: SoK: Vector OLE-Based Zero-Knowledge Protocols
|
||||
[^6]: Keller, M., Orsini, E., Scholl, P.: Actively Secure OT Extension with Optimal Overhead
|
||||
[^7]: Roy, L.: SoftSpokenOT: Communication–Computation Tradeoffs in OT Extension
|
||||
[^8]: Gilboa, N.: Two Party RSA Key Generation. In: Advances in Cryptology - Crypto '99
|
||||
BIN
blog/2023-09-19-tlsnotary-updates/redacted.png
Normal file
|
After Width: | Height: | Size: 309 KiB |
@@ -15,9 +15,19 @@ slorber:
|
||||
image_url: https://github.com/slorber.png
|
||||
page:
|
||||
# customize the url of the author page at /blog/authors/<permalink>
|
||||
permalink: '/all-sebastien-lorber-articles'
|
||||
permalink: "/all-sebastien-lorber-articles"
|
||||
socials:
|
||||
x: sebastienlorber
|
||||
linkedin: sebastienlorber
|
||||
github: slorber
|
||||
newsletter: https://thisweekinreact.com
|
||||
|
||||
sinu:
|
||||
name: Sinu
|
||||
title: Tech lead
|
||||
url: https://github.com/sinui0
|
||||
image_url: https://github.com/sinui0.png
|
||||
page: true
|
||||
socials:
|
||||
x: sinu_eth
|
||||
github: sinui0
|
||||
|
||||
3
docs/diagrams/client-state-diagram.svg
Normal file
|
After Width: | Height: | Size: 39 KiB |
3
docs/diagrams/crate_structure.svg
Normal file
|
After Width: | Height: | Size: 17 KiB |
3
docs/diagrams/data_provenance_none.svg
Normal file
|
After Width: | Height: | Size: 11 KiB |
3
docs/diagrams/data_provenance_oauth.svg
Normal file
|
After Width: | Height: | Size: 15 KiB |
3
docs/diagrams/data_provenance_tlsn.svg
Normal file
|
After Width: | Height: | Size: 12 KiB |
3
docs/diagrams/data_provenance_ultimate.svg
Normal file
|
After Width: | Height: | Size: 12 KiB |
3
docs/diagrams/encoding_commitment.svg
Normal file
|
After Width: | Height: | Size: 116 KiB |
3
docs/diagrams/gc-types.svg
Normal file
|
After Width: | Height: | Size: 60 KiB |
3
docs/diagrams/intro-diagram.svg
Normal file
|
After Width: | Height: | Size: 54 KiB |
3
docs/diagrams/key_exchange.svg
Normal file
|
After Width: | Height: | Size: 30 KiB |
3
docs/diagrams/mpc-decryption.svg
Normal file
|
After Width: | Height: | Size: 9.9 KiB |
3
docs/diagrams/mpc-encryption.svg
Normal file
|
After Width: | Height: | Size: 9.9 KiB |
3
docs/diagrams/overview.svg
Normal file
|
After Width: | Height: | Size: 38 KiB |
3
docs/diagrams/overview2.svg
Normal file
|
After Width: | Height: | Size: 23 KiB |
3
docs/diagrams/overview_notarization.svg
Normal file
|
After Width: | Height: | Size: 32 KiB |
3
docs/diagrams/overview_notary.svg
Normal file
|
After Width: | Height: | Size: 21 KiB |
3
docs/diagrams/overview_prover_verifier.svg
Normal file
|
After Width: | Height: | Size: 14 KiB |
3
docs/diagrams/protocol.svg
Normal file
|
After Width: | Height: | Size: 82 KiB |
3
docs/diagrams/transcript.svg
Normal file
|
After Width: | Height: | Size: 44 KiB |
3
docs/diagrams/verification_example.svg
Normal file
|
After Width: | Height: | Size: 5.4 KiB |
13
docs/extension/README.md
Normal file
@@ -0,0 +1,13 @@
|
||||
---
|
||||
sidebar_label: Browser Extension
|
||||
---
|
||||
# Chrome Extension (MV3) for TLSNotary
|
||||
|
||||
> **Important**
|
||||
>
|
||||
> ⚠️ When running the extension against a notary server, ensure that the notary server's version matches the version of this extension.
|
||||
|
||||
The TLSNotary browser extension includes a plugin system that allows you to safely extend its functionality with custom plugins tailored to your specific data sources. This section also explains how to interact with the TLSN Extension within web applications.
|
||||
|
||||
- [Plugins](./plugins.md)
|
||||
- [Provider API](./provider.md)
|
||||
BIN
docs/extension/images/connect.png
Normal file
|
After Width: | Height: | Size: 53 KiB |
BIN
docs/extension/images/execute_plugin.png
Normal file
|
After Width: | Height: | Size: 40 KiB |
BIN
docs/extension/images/install_plugin.png
Normal file
|
After Width: | Height: | Size: 57 KiB |
BIN
docs/extension/images/notarize.png
Normal file
|
After Width: | Height: | Size: 54 KiB |
BIN
docs/extension/images/share_installed_plugins.png
Normal file
|
After Width: | Height: | Size: 52 KiB |
BIN
docs/extension/images/share_proof_data.png
Normal file
|
After Width: | Height: | Size: 47 KiB |
BIN
docs/extension/images/share_proof_history.png
Normal file
|
After Width: | Height: | Size: 52 KiB |
BIN
docs/extension/images/steps_ui.png
Normal file
|
After Width: | Height: | Size: 45 KiB |
127
docs/extension/plugins.md
Normal file
@@ -0,0 +1,127 @@
|
||||
---
|
||||
sidebar_position: 1
|
||||
sidebar_label: Plugins
|
||||
---
|
||||
# Browser Extension Plugins
|
||||
|
||||
The **TLSN Extension** has a plugin system that allows you to safely extend its functionality. The plugin system is based on [Extism](https://extism.org/docs/concepts/plug-in-system), which enables you to write plugins in the programming language of your choice. This page focuses on plugins written in TypeScript.
|
||||
|
||||
## What Can You Do with Plugins?
|
||||
|
||||
Plugins can add new custom features to the extension by using built-in host functions, such as:
|
||||
|
||||
- Requesting private information from the browser, such as cookies and headers of one or more hostnames.
|
||||
- Submitting a new notarization request.
|
||||
- Redirecting a browsing window.
|
||||
|
||||
New features and capabilities will be added based on feedback from developers. Please reach out to us on [Discord](https://discord.gg/9XwESXtcN7).
|
||||
|
||||
## Templates and Examples
|
||||
|
||||
You can find a boilerplate template at [tlsn-plugin-boilerplate](https://github.com/tlsnotary/tlsn-plugin-boilerplate), which is a great starting point. This repository explains how to compile and test Typescript plugins.
|
||||
|
||||
The [examples folder](https://github.com/tlsnotary/tlsn-plugin-boilerplate/tree/main/examples) contains more examples of TLSNotary plugins.
|
||||
|
||||
## Configuration JSON
|
||||
|
||||
A plugin must include a configuration JSON file that describes its behavior and permissions.
|
||||
|
||||
<!-- https://github.com/tlsnotary/tlsn-extension/blob/p2p/src/utils/misc.ts#L315-L326 -->
|
||||
```ts
|
||||
export type PluginConfig = {
|
||||
title: string; // The name of the plugin
|
||||
description: string; // A description of the plugin purpose
|
||||
icon?: string; // A base64-encoded image string representing the plugin's icon (optional)
|
||||
steps?: StepConfig[]; // An array describing the UI steps and behavior (see Step UI below) (optional)
|
||||
hostFunctions?: string[]; // Host functions that the plugin will have access to
|
||||
cookies?: string[]; // Cookies the plugin will have access to, cached by the extension from specified hosts (optional)
|
||||
headers?: string[]; // Headers the plugin will have access to, cached by the extension from specified hosts (optional)
|
||||
localStorage?: string[]; // LocalStorage the plugin will have access to, cached by the extension from specified hosts (optional)
|
||||
sessionStorage?: string[]; // SessionStorage the plugin will have access to, cached by the extension from specified hosts (optional)
|
||||
requests: { method: string; url: string }[]; // List of requests that the plugin is allowed to make
|
||||
notaryUrls?: string[]; // List of notary services that the plugin is allowed to use (optional)
|
||||
proxyUrls?: string[]; // List of websocket proxies that the plugin is allowed to use (optional)
|
||||
};
|
||||
```
|
||||
|
||||
## Step UI
|
||||
|
||||
The plugin system allows customization of the UI and the functionality of the side panel.
|
||||
|
||||

|
||||
|
||||
### Step Configuration
|
||||
|
||||
The steps are declared in the JSON configuration:
|
||||
|
||||
```ts
|
||||
type StepConfig = {
|
||||
title: string; // Text for the step's title
|
||||
description?: string; // OPTIONAL: Text for the step's description
|
||||
cta: string; // Text for the step's call-to-action button
|
||||
action: string; // The function name that this step will execute
|
||||
prover?: boolean; // Boolean indicating if this step outputs a notarization
|
||||
}
|
||||
```
|
||||
|
||||
You need to implement the functionality of the steps in `src/index.ts`. The function names must match the corresponding step names in the JSON configuration.
|
||||
|
||||
## Host Functions
|
||||
|
||||
<!-- https://github.com/tlsnotary/tlsn-extension/blob/fe56de0b6cb4e235cabb0f8b2216853de2adb47f/src/utils/plugins.tsx#L5 -->
|
||||
[Host functions](https://extism.org/docs/concepts/host-functions) are specific behaviors provided by the extension that the plugin can call. Host function usage may vary depending on the language used to write the plugin.
|
||||
|
||||
### `redirect`
|
||||
|
||||
Redirects the current tab to a different URL.
|
||||
|
||||
Example in JavaScript:
|
||||
```js
|
||||
const { redirect } = Host.getFunctions();
|
||||
const mem = Memory.fromString('https://x.com');
|
||||
redirect(mem.offset);
|
||||
```
|
||||
|
||||
### `notarize`
|
||||
|
||||
Notarizes a request.
|
||||
|
||||
Example in JavaScript:
|
||||
```js
|
||||
const { notarize } = Host.getFunctions();
|
||||
const mem = Memory.fromString(JSON.stringify({
|
||||
url: "https://...",
|
||||
method: "GET",
|
||||
headers: {
|
||||
"authorization": "Bearer xxx",
|
||||
"cookie": "lang=en; auth_token=xxx",
|
||||
},
|
||||
secretHeaders: [
|
||||
"authorization: Bearer xxx",
|
||||
"cookie: lang=en; auth_token=xxx",
|
||||
],
|
||||
getSecretBody: "parseResponse" // See redaction example below
|
||||
}));
|
||||
const idOffset = notarize(mem.offset);
|
||||
const id = Memory.find(idOffset).readString();
|
||||
Host.outputString(JSON.stringify(id)); // Outputs the notarization ID
|
||||
```
|
||||
|
||||
#### Redaction
|
||||
|
||||
If the `getSecretResponse` field of the `notarize` host function call is set, the corresponding method will be called to parse the response of the request. Make sure to also export this function in the `main` module declaration in `index.d.ts`.
|
||||
|
||||
```ts
|
||||
function parseResponse() {
|
||||
const bodyString = Host.inputString();
|
||||
const params = JSON.parse(bodyString);
|
||||
const revealed = `"screen_name":"${params.screen_name}"`;
|
||||
const selectionStart = bodyString.indexOf(revealed);
|
||||
const selectionEnd = selectionStart + revealed.length;
|
||||
const secretResps = [
|
||||
bodyString.substring(0, selectionStart),
|
||||
bodyString.substring(selectionEnd, bodyString.length),
|
||||
];
|
||||
Host.outputString(JSON.stringify(secretResps));
|
||||
}
|
||||
```
|
||||
57
docs/extension/provider.md
Normal file
@@ -0,0 +1,57 @@
|
||||
---
|
||||
sidebar_position: 2
|
||||
sidebar_label: Provider API
|
||||
---
|
||||
# TLSN Extension's Provider API
|
||||
|
||||
This page is a reference for the **TLSN Extension's Provider API**. This API can be used in web pages to run plugins via the TLSN extension.
|
||||
|
||||
The TLSN Extension injects a provider API into websites visited by its users using the `window.tlsn` provider object. This allows webpages to **connect to the TLSN Extension** and ask the user to run plugins.
|
||||
|
||||
## Connect to TLSN Extension
|
||||
|
||||
### `tlsn.connect()`
|
||||
|
||||
This method is used to request a connection between the website and the extension. Once connected, the website can use the provider API to request actions from the extension.
|
||||
|
||||
#### Parameters
|
||||
None.
|
||||
|
||||
#### Returns
|
||||
A promise that resolves to the full provider API object.
|
||||
|
||||
#### Example
|
||||
```ts
|
||||
const client = await tlsn.connect();
|
||||
```
|
||||
|
||||
|
||||
### `client.runPlugin(url, params)`
|
||||
|
||||
This method is used to request the execution of a plugin by its URL. The plugin will be loaded automatically, and if the user approves, the extension will guide the user through the plugin's steps.
|
||||
|
||||
|
||||
#### Parameters
|
||||
1. `url`: The URL to the plugin's WASM file.
|
||||
2. `params` *(optional)*: An object containing user input parameters as key-value pairs.
|
||||
|
||||
#### Returns
|
||||
A promise that resolves to the proof data.
|
||||
```ts
|
||||
type ProofData = {
|
||||
notaryUrl: string;
|
||||
session: Session; // https://github.com/tlsnotary/tlsn-js/blob/main/src/types.ts#L7-L11;
|
||||
substrings: Substrings; // https://github.com/tlsnotary/tlsn-js/blob/main/src/types.ts#L73-L76
|
||||
}
|
||||
```
|
||||
|
||||
#### Example
|
||||
```ts
|
||||
const proof = await client.runPlugin(
|
||||
"https://github.com/tlsnotary/tlsn-extension/raw/main/plugins/twitter_profile/index.wasm",
|
||||
{ Key: "Value" }
|
||||
);
|
||||
```
|
||||
|
||||
#### Screenshot
|
||||

|
||||
@@ -2,46 +2,76 @@
|
||||
sidebar_position: 1
|
||||
---
|
||||
|
||||
# Tutorial Intro
|
||||
# Introduction
|
||||
|
||||
Let's discover **Docusaurus in less than 5 minutes**.
|
||||
## Data Provenance without Compromising Privacy, That is Why!
|
||||
|
||||
## Getting Started
|
||||
The Internet currently lacks effective, privacy-preserving **Data Provenance**. [TLS](https://en.wikipedia.org/wiki/Transport_Layer_Security), also known as the "s" in "https" 🔐 to the general public, ensures that data can be securely communicated between a server and a user. But how can this user credibly share this data with another user or server without compromising security, privacy, and control?
|
||||
|
||||
Get started by **creating a new site**.
|
||||
Enter TLSNotary: a protocol enabling users to export data securely from any website. Using Zero Knowledge Proof (ZKP) technology, this data can be selectively shared with others in a cryptographically verifiable manner.
|
||||
|
||||
Or **try Docusaurus immediately** with **[docusaurus.new](https://docusaurus.new)**.
|
||||
TLSNotary makes data truly portable and allows a user, the `Prover`, to share it with another party, the `Verifier`, as they see fit.
|
||||
|
||||
### What you'll need
|
||||
## How Does the TLSNotary Protocol Work?
|
||||
|
||||
- [Node.js](https://nodejs.org/en/download/) version 18.0 or above:
|
||||
- When installing Node.js, you are recommended to check all checkboxes related to dependencies.
|
||||
The TLSNotary protocol consists of 3 steps:
|
||||
1. The `Prover` **requests** data from a `Server` over TLS while cooperating with the `Verifier` in secure and privacy-preserving *multi-party computation (MPC)*.
|
||||
2. The `Prover` **selectively discloses** the data to the `Verifier`.
|
||||
3. The `Verifier` **verifies** the data.
|
||||
|
||||
## Generate a new site
|
||||

|
||||
|
||||
Generate a new Docusaurus site using the **classic template**.
|
||||
### ① Multi-party TLS Request
|
||||
|
||||
The classic template will automatically be added to your project after you run the command:
|
||||
TLSNotary works by adding a third party, a `Verifier`, to the usual TLS connection between the `Prover` and a `Server`. This `Verifier` is **not "[a man in the middle](https://en.wikipedia.org/wiki/Man-in-the-middle_attack)"**. Instead, the `Verifier` participates in a **secure multi-party computation** (MPC) to jointly operate the TLS connection without seeing the data in plain text. By participating in the MPC, the `Verifier` can validate the authenticity of the data the `Prover` received from the `Server`.
|
||||
|
||||
```bash
|
||||
npm init docusaurus@latest my-website classic
|
||||
```
|
||||
The TLSNotary protocol is transparent to the `Server`. From the `Server`'s perspective, the `Prover`'s connection is a standard TLS connection.
|
||||
|
||||
You can type this command into Command Prompt, Powershell, Terminal, or any other integrated terminal of your code editor.
|
||||
### ② Selective Disclosure
|
||||
|
||||
The command also installs all necessary dependencies you need to run Docusaurus.
|
||||
The TLSNotary protocol enables the `Prover` to selectively prove the authenticity of arbitrary parts of the data to a `Verifier`. In this **selective disclosure** phase, the `Prover` can **redact** sensitive information from the data prior to sharing it with the `Verifier`.
|
||||
|
||||
## Start your site
|
||||
This capability can be paired with Zero-Knowledge Proofs to prove properties of the redacted data without revealing the data itself.
|
||||
|
||||
Run the development server:
|
||||
### ③ Data Verification
|
||||
|
||||
```bash
|
||||
cd my-website
|
||||
npm run start
|
||||
```
|
||||
The `Verifier` now validates the proof received from the `Prover`. The data origin can be verified by inspecting the `Server` certificate through trusted certificate authorities (CAs). The `Verifier` can now make assertions about the non-redacted content of the transcript.
|
||||
|
||||
The `cd` command changes the directory you're working with. In order to work with your newly created Docusaurus site, you'll need to navigate the terminal there.
|
||||
## TLS verification with a general-purpose Notary
|
||||
|
||||
The `npm run start` command builds your website locally and serves it through a development server, ready for you to view at http://localhost:3000/.
|
||||
Since the validation of the TLS traffic neither reveals anything about the plaintext of the TLS session nor about the `Server`, it is possible to outsource the MPC-TLS verification ① to a general-purpose TLS verifier, which we term a `Notary`. This `Notary` can sign (aka *notarize*) ② the data, making it portable. The `Prover` can then take this signed data and selectively disclose ③ sections to an application-specific `Verifier`, who then verifies the data ④.
|
||||
|
||||
Open `docs/intro.md` (this page) and edit some lines: the site **reloads automatically** and displays your changes.
|
||||

|
||||
|
||||
In this setup, the `Notary` cryptographically signs commitments to the data and the server's identity. The `Prover` can store this signed data, redact it, and share it with any `Verifier` as they see fit, making the signed data both reusable and portable.
|
||||
|
||||
`Verifiers` will only accept the signed data if they trust the `Notary`. A data `Verifier` can also require signed data from multiple `Notaries` to rule out collusion between the `Prover` and a `Notary`.
|
||||
|
||||
|
||||
## What Can TLSNotary Do?
|
||||
|
||||
TLSNotary can be used for various purposes. For example, you can use TLSNotary to prove that:
|
||||
- you have access to an account on a web platform
|
||||
- a website showed specific content on a certain date
|
||||
- you have private information about yourself (address, birth date, health, etc.)
|
||||
- you have received a money transfer using your online banking account without revealing your login credentials or sensitive financial information
|
||||
- you received a private message from someone
|
||||
- you purchased an item online
|
||||
- you were blocked from using an app
|
||||
- you earned professional certificates
|
||||
|
||||
While TLSNotary can notarize publicly available data, it does not solve the "[oracle problem](https://ethereum.org/en/developers/docs/oracles/)". For this use case, existing oracle solutions are more suitable.
|
||||
|
||||
## What TLS version does TLSNotary support?
|
||||
|
||||
TLSNotary currently supports TLS 1.2. TLS 1.3 support will be added in 2024.
|
||||
|
||||
## Who is behind TLSNotary?
|
||||
|
||||
TLSNotary is developed by the [Privacy and Scaling Exploration (PSE)](https://pse.dev) research lab of the Ethereum Foundation. The PSE team is committed to conceptualizing and testing use cases for cryptographic primitives.
|
||||
|
||||
TLSNotary is not a new project; in fact, it has been around for [more than a decade](https://bitcointalk.org/index.php?topic=173220.0).
|
||||
|
||||
In 2022, TLSNotary was rebuilt from the ground up in [Rust](https://www.rust-lang.org/) incorporating state-of-the-art cryptographic protocols. This renewed version of the TLSNotary protocol offers enhanced security, privacy, and performance.
|
||||
|
||||
Older versions of TLSNotary, including PageSigner, have been archived due to a security vulnerability.
|
||||
|
||||
51
docs/motivation.md
Normal file
@@ -0,0 +1,51 @@
|
||||
---
|
||||
sidebar_position: 1
|
||||
---
|
||||
|
||||
# Motivation
|
||||
|
||||
The decentralized internet demands privacy-respecting data provenance!
|
||||
|
||||
Data provenance ensures internet data is authentic. It allows verification of the data's origin and ensures the data hasn't been fabricated or tampered with.
|
||||
|
||||
Data provenance will make data truly portable, empowering users to share it with others as they see fit.
|
||||
|
||||
## Non-repudiation: TLS is not enough
|
||||
|
||||

|
||||
|
||||
Transport Layer Security (TLS) plays a crucial role in digital security. TLS protects communication against eavesdropping and tampering. It ensures that the data received by a user (_"Alice"_) indeed originated from the `Server` and was not changed. The `Server`'s identity is verified by Alice through trusted Certificate Authorities (CAs). Data integrity is maintained by transmitting a cryptographic hash (called Message Authentication Code or MAC in TLS) alongside the data, which safeguards against deliberate alterations.
|
||||
|
||||
However, this hash does not provide **non-repudiation**, meaning it cannot serve as evidence for the **authenticity and integrity** of the data to Bob (e.g., a service or an app). Because it is a keyed hash and TLS requires that the key is known to Alice, she could potentially modify the data and compute a corresponding hash after the TLS session is finished.
|
||||
|
||||
Achieving non-repudiation requires digital signatures implemented with asymmetric, public-key cryptography.
|
||||
|
||||
While the concept seems straightforward, enabling servers to sign data is not a part of the TLS protocol. Even if all data were securely signed, naively sharing all data with others could expose too much information, compromising Alice's privacy. **Privacy** is a vital social good that must be protected.
|
||||
|
||||
## Status Quo: delegate access
|
||||
|
||||

|
||||
|
||||
Currently, when Alice wants to share data from a `Server` with another party, OAuth can be used to facilitate this if the application supports it. In this way, the other party receives the data directly from the `Server`, ensuring authentic and unchanged data. However, applications often do not provide fine-grained control over which data to share, leading to the other party gaining access to more information than strictly necessary.
|
||||
|
||||
Another drawback of this solution is that the `Server` is aware of the access delegation, enabling it to monitor and censor the other user’s requests.
|
||||
|
||||
It's worth noting that in many instances, OAuth is not even presented as an option. This is because a lot of servers lack the incentive to provide third-party access to the data.
|
||||
|
||||
## TLSNotary: data provenance and privacy with secure multi-party computation
|
||||
|
||||

|
||||
|
||||
TLSNotary operates by executing the TLS communication using **multi-party computation** (MPC). MPC allows Alice and Bob to jointly manage the TLS connection.
|
||||
With TLSNotary, Alice can selectively prove the authenticity of arbitrary portions of the data to Bob. Since Bob participated in the MPC-TLS communication, he is guaranteed that the data is authentic.
|
||||
|
||||
The TLSNotary protocol is **transparent** to the `Server`. From the `Server`'s perspective, the TLS connection appears just like any other connection, meaning **no modifications to the TLS protocol are necessary**.
|
||||
|
||||
<!-- TLSNotary can also separate the TLS-MPC verification from the data verification. When an independent **Notary** handles the TLS verification, the user receives signed, or notarized, data from the notary, which she can store or carry around. This equates to full data portability. It is worth noting that in this setup, Bob (the data verifier) needs to trust the notary. -->
|
||||
|
||||
|
||||
## Make your data portable with TLSNotary!
|
||||
|
||||
TLSNotary is a solution designed to prove the authenticity of data while preserving user privacy. It unlocks a variety of new use cases. So, if you're looking for a way to make your data portable without compromising on privacy, TLSNotary is developed for you!
|
||||
|
||||
Dive into the protocol and integrate it into your applications. We eagerly await your feedback on [Discord](https://discord.com/invite/9XwESXtcN7).
|
||||
42
docs/quick_start/README.md
Normal file
@@ -0,0 +1,42 @@
|
||||
---
|
||||
sidebar_position: 1
|
||||
---
|
||||
# Quick Start
|
||||
|
||||
This quick start will help you get started with TLSNotary, both in native Rust and in the Browser.
|
||||
|
||||
## Objectives
|
||||
|
||||
- Gain a better understanding of what you can do with TLSNotary
|
||||
- Learn the basics of how to notarize and verify data using TLSNotary
|
||||
|
||||
## Rust
|
||||
|
||||
1. [Interactive Verification Example](rust.md#interactive): This example demonstrates how to use TLSNotary in a simple interactive session between a Prover and a Verifier. It involves the Verifier first verifying the MPC-TLS session and then confirming the correctness of the data.
|
||||
2. [Simple Attestation Example](rust.md#attestation): Use TLSNotary with a Notary attesting to the data.
|
||||
|
||||
## Browser
|
||||
|
||||
### Hosted demo
|
||||
|
||||
To get started with TLSNotary in the browser, it is recommended to try the online TLSNotary demo first. This demo shows how TLSNotary can be used to verify private user data in a web app. The demo guides you through the following steps:
|
||||
|
||||
1. Installing the browser extension
|
||||
2. Installing the website plugin into the browser extension
|
||||
3. Running the plugin to get a TLSNotary attestation
|
||||
4. Verifying the attestation on the server
|
||||
|
||||
Visit [demo.tlsnotary.org](https://demo.tlsnotary.org) to try the different steps.
|
||||
|
||||
### Proving and Verifying Data in a React/Typescript App (`tlsn-js`)
|
||||
|
||||
Learn how to use TLSNotary in a React/Typescript app with the `tlsn-js` NPM module.
|
||||
|
||||
[Proving and Verifying Data in a React/Typescript App](tlsn-js.md#browser)
|
||||
|
||||
### Browser Extension
|
||||
|
||||
Learn how to prove and verify ownership of a Twitter account using the TLSNotary browser extension.
|
||||
|
||||
[Proving and Verifying Ownership of a Twitter Account (Browser)](browser_extension)
|
||||
|
||||
115
docs/quick_start/browser_extension.md
Normal file
@@ -0,0 +1,115 @@
|
||||
---
|
||||
sidebar_label: Browser Extension
|
||||
|
||||
---
|
||||
# TLSNotary Browser Extension
|
||||
|
||||
In this quick start we will prove ownership of a Twitter account with TLSNotary's browser extension.
|
||||
|
||||
Optionaly you can [install](#install) and configure a local [websocket proxy](#proxy) and local [notary server](#notary-server).
|
||||
|
||||
## Install Browser Extension (Chrome/Brave) <a name="install"></a>
|
||||
|
||||
The easiest way to install the TLSN browser extension is to use **[Chrome Web Store](https://chromewebstore.google.com/detail/gcfkkledipjbgdbimfpijgbkhajiaaph)**.
|
||||
|
||||

|
||||
|
||||
Alternatively, you can install it manually:
|
||||
1. Download the browser extension from https://github.com/tlsnotary/tlsn-extension/releases/download/0.1.0.1000/tlsn-extension-0.1.0.1000.zip
|
||||
2. Unzip
|
||||
⚠️ This is a flat zip file, so be careful if you unzip from the command line, this zip file contains many file at the top level
|
||||
3. Open **Manage Extensions**: chrome://extensions/
|
||||
4. Enable `Developer mode`
|
||||
5. Click the **Load unpacked** button
|
||||
6. Select the unzipped folder
|
||||
|
||||

|
||||
|
||||
(Optional:) Pin the extension, so that it is easier to find in the next steps:
|
||||
|
||||

|
||||
|
||||
## Websocket Proxy <a name="proxy"></a>
|
||||
|
||||
Since a web browser doesn't have the ability to make TCP connection, we need to use a websocket proxy server. You can either run one yourself, or use a TLSNotary hosted proxy.
|
||||
|
||||
To use the TLSnotary hosted proxy:
|
||||
1. Open the extension
|
||||
2. Click **Options**
|
||||
3. Enter `wss://notary.pse.dev/proxy` as **proxy API**
|
||||
4. Click **Save**
|
||||
|
||||
> ⚠️ **Note:** The TLSNotary hosted proxy only supports a predefined set of domains. You can view the full list of supported domains in the [websockify configuration file](https://github.com/privacy-scaling-explorations/tlsn-infra/blob/main/docker/websockify/websockify_config).
|
||||
|
||||
To run your own websocket proxy **locally**, run:
|
||||
1. Install [wstcp](https://github.com/sile/wstcp):
|
||||
```shell
|
||||
cargo install wstcp
|
||||
```
|
||||
2. Run a websocket proxy for `https://api.x.com`:
|
||||
```shell
|
||||
wstcp --bind-addr 127.0.0.1:55688 api.x.com:443
|
||||
```
|
||||
Note the `api.x.com:443` argument on the last line.
|
||||
|
||||
Next use `ws://localhost:55688` as **proxy API** in Step 3 above.
|
||||
|
||||
## Notary Server <a name="notary-server"></a>
|
||||
|
||||
To create a TLSNotary proof, the browser extension needs a TLSNotary notary server. In a real world scenario, this server should be run by a neutral party, or by the verifier of the proofs. In this quick start, you can either run the server yourself or use the test server from the TLSNotary team. Notarizing TLS with Multi Party Computation involves a lot of communication between the extension and notary server, so running a local server is the fastest option.
|
||||
|
||||
To use the TLSNotary team notary server:
|
||||
1. Open the extension
|
||||
2. Click **Options**
|
||||
3. Update Notary API to: `https://notary.pse.dev/v0.1.0-alpha.10`
|
||||
4. Click **Save**
|
||||
5. Skip the next section and [continue with the notarization step](#notarize)
|
||||
|
||||
If you plan to run a local notary server:
|
||||
1. Open the extension
|
||||
2. Click **Options**
|
||||
3. Update Notary API to: `http://localhost:7047`
|
||||
4. Click **Save**
|
||||
5. Run a local notary server (see [below](#local-notary))
|
||||
|
||||
<img width="478" src="images/extension_proxy.png" />
|
||||
|
||||
### Run a Local Notary Server <a name="local-notary"></a>
|
||||
|
||||
1. Clone the TLSNotary repository (defaults to the `main` branch, which points to the latest release):
|
||||
```shell
|
||||
git clone https://github.com/tlsnotary/tlsn.git
|
||||
```
|
||||
2. Run the notary server:
|
||||
```sh
|
||||
cd crates/notary/server
|
||||
cargo run --release -- --tls-enabled false
|
||||
```
|
||||
|
||||
The notary server will now be running in the background waiting for connections.
|
||||
|
||||
## Notarize Twitter Account Access <a name="notarize"></a>
|
||||
|
||||
1. Open the extension, you should see the Twitter plugin:
|
||||
<img width="477" src="images/extension_plugins.png" />
|
||||
2. Click the Twitter Plugin
|
||||
3. The TLSNotary Extension sidebar should open and the browser will automatically navigate to Twitter
|
||||
4. If you haven't already, log in
|
||||
5. The sidebar should automatically proceeds through the steps
|
||||
|
||||
Tip: If you use the hosted notary server, notarization will take multiple seconds. You can track progress by opening the *offscreen console*:
|
||||
* Open: chrome://extensions ▸ **TLSN Extension** ▸ **Details** ▸ **offscreen.html**
|
||||
|
||||
## Verify
|
||||
|
||||
When the notarization is ready, you can click the **View** button. If you closed the sidebar, you can find the proof by clicking the extension button and selecting the notarization request in the **History** tab.
|
||||
<img width="477" src="./images/extension_history_new.png" />
|
||||

|
||||
|
||||
<!-- TODO -->
|
||||
<!-- You also have the option to download the proof. You can view this proof later by using the **Verify** button or via <https://explorer.tlsnotary.org/>. You can get the Notary public key by visiting the Notary API specified [above](#notary-server). -->
|
||||
|
||||
|
||||
## Write your own Extension Plugins
|
||||
|
||||
The TLSNotary Browser extension allows you to add custom plugins for more data sources. The repository at https://github.com/tlsnotary/tlsn-plugin-boilerplate shows how the Twitter plugin (see above) is built. The `examples` folder contains more examples.
|
||||
BIN
docs/quick_start/images/chromewebstore.png
Normal file
|
After Width: | Height: | Size: 116 KiB |
BIN
docs/quick_start/images/discord_authentication_token.png
Normal file
|
After Width: | Height: | Size: 544 KiB |
BIN
docs/quick_start/images/explorer.png
Normal file
|
After Width: | Height: | Size: 29 KiB |
BIN
docs/quick_start/images/explorer_redacted.png
Normal file
|
After Width: | Height: | Size: 46 KiB |
BIN
docs/quick_start/images/extension_headers.png
Normal file
|
After Width: | Height: | Size: 194 KiB |
BIN
docs/quick_start/images/extension_headers_reveal.png
Normal file
|
After Width: | Height: | Size: 158 KiB |
BIN
docs/quick_start/images/extension_history.png
Normal file
|
After Width: | Height: | Size: 40 KiB |
BIN
docs/quick_start/images/extension_history_new.png
Normal file
|
After Width: | Height: | Size: 74 KiB |
BIN
docs/quick_start/images/extension_install.png
Normal file
|
After Width: | Height: | Size: 210 KiB |
BIN
docs/quick_start/images/extension_notarize.png
Normal file
|
After Width: | Height: | Size: 1.3 MiB |
BIN
docs/quick_start/images/extension_pin.png
Normal file
|
After Width: | Height: | Size: 360 KiB |
BIN
docs/quick_start/images/extension_plugins.png
Normal file
|
After Width: | Height: | Size: 54 KiB |
BIN
docs/quick_start/images/extension_process.png
Normal file
|
After Width: | Height: | Size: 106 KiB |
BIN
docs/quick_start/images/extension_proxy.png
Normal file
|
After Width: | Height: | Size: 22 KiB |
BIN
docs/quick_start/images/extension_request.png
Normal file
|
After Width: | Height: | Size: 31 KiB |
BIN
docs/quick_start/images/extension_requests.png
Normal file
|
After Width: | Height: | Size: 22 KiB |
BIN
docs/quick_start/images/extension_sidebar.png
Normal file
|
After Width: | Height: | Size: 110 KiB |
BIN
docs/quick_start/images/extension_text_reveal.png
Normal file
|
After Width: | Height: | Size: 130 KiB |
BIN
docs/quick_start/images/extension_twitter_requests.png
Normal file
|
After Width: | Height: | Size: 1.4 MiB |
BIN
docs/quick_start/images/extesnion_notarize_pending.png
Normal file
|
After Width: | Height: | Size: 1.4 MiB |
BIN
docs/quick_start/images/notary_certificate.png
Normal file
|
After Width: | Height: | Size: 606 KiB |
BIN
docs/quick_start/images/notary_certificate_advanced.png
Normal file
|
After Width: | Height: | Size: 670 KiB |
BIN
docs/quick_start/images/proof_viz.png
Normal file
|
After Width: | Height: | Size: 379 KiB |
BIN
docs/quick_start/images/run_vs_code.png
Normal file
|
After Width: | Height: | Size: 22 KiB |
37
docs/quick_start/rust.md
Normal file
@@ -0,0 +1,37 @@
|
||||
---
|
||||
sidebar_position: 1
|
||||
sidebar_label: Rust
|
||||
---
|
||||
# Rust Quick Start
|
||||
|
||||
This quick start demonstrates how to use TLSNotary with Rust code.
|
||||
|
||||
## Requirements
|
||||
|
||||
Before we start, make sure you have cloned the `tlsn` repository and have a recent version of Rust installed.
|
||||
|
||||
1. Clone the `tlsn` repository (defaults to the `main` branch, which points to the latest release):
|
||||
```shell
|
||||
git clone https://github.com/tlsnotary/tlsn.git
|
||||
```
|
||||
2. If you don't have Rust installed yet, you can install it using [rustup](https://rustup.rs/). If your Rust version is outdated, update it with `rustup update stable`.
|
||||
|
||||
## Simple Interactive Verifier: Verifying Data from an API in Rust<a name="interactive"></a>
|
||||
|
||||

|
||||
|
||||
This example demonstrates how to use TLSNotary in a simple interactive session between a Prover and a Verifier. It involves the Verifier first verifying the MPC-TLS session and then confirming the correctness of the data.
|
||||
|
||||
Follow the instructions from:
|
||||
https://github.com/tlsnotary/tlsn/tree/main/crates/examples/interactive#readme
|
||||
|
||||
## Simple Attestation Example: Verifying Data from an API in Rust with a Notary<a name="attestation"></a>
|
||||
|
||||

|
||||
|
||||
TLSNotary can also be used in a setup where MPC-TLS verification is delegated to a notary server. In this example, the notary attests to the data served to the prover. Next, the prover can share this attestation with a Verifier who can verify the data.
|
||||
|
||||
Follow the instructions from:
|
||||
https://github.com/tlsnotary/tlsn/tree/main/crates/examples/attestation#readme
|
||||
|
||||
🍾 Great job! You have successfully used TLSNotary in Rust.
|
||||
108
docs/quick_start/tlsn-js.md
Normal file
@@ -0,0 +1,108 @@
|
||||
---
|
||||
sidebar_position: 1
|
||||
sidebar_label: Browser
|
||||
---
|
||||
# TLSNotary in React/Typescript with `tlsn-js`
|
||||
|
||||
In this quick start you will learn how to use TLSNotary in React/Typescript with the [`tlsn-js`](https://github.com/tlsnotary/tlsn-js) NPM module in the browser.
|
||||
|
||||
This quick start uses the react/typescript [demos in `tlsn-js`](https://github.com/tlsnotary/tlsn-js/tree/main/demo/). The `demo` directory contains three demos to quickly bootstrap a webpack app using `tlsn-js`:
|
||||
|
||||
1. [`react-ts-webpack`: create an attestation with a Notary and render the result](#react-ts-webpack)
|
||||
2. [`interactive-demo`: prove data interactively to a Verifier](#interactive-demo)
|
||||
3. [`web-to-web-p2p`: prove data between two peers, in the browser](#web-to-web-p2p)
|
||||
|
||||
## `tlsn-js` in a React/Typescript app<a name="react-ts-webpack"></a>
|
||||
|
||||
In this demo, we will request JSON data from the Star Wars API at https://swapi.dev. We will use `tlsn-js` to notarize the TLS request with TLSNotary and store the result in a *proof*. Then, we will use `tlsn-js` again to verify this *proof*.
|
||||
|
||||
> **_NOTE:_** ℹ️ This demo uses TLSNotary to notarize **public** data to simplify the quick start for everyone. For real-world applications, TLSNotary is particularly valuable for notarizing private and sensitive data.
|
||||
|
||||
1. Clone the repository
|
||||
```sh
|
||||
git clone https://github.com/tlsnotary/tlsn-js
|
||||
```
|
||||
2. Navigate to the demo directory:
|
||||
```sh
|
||||
cd tlsn-js/demo/react-ts-webpack
|
||||
```
|
||||
3. Checkout the version of this quick start:
|
||||
```sh
|
||||
git checkout v0.1.0-alpha.10
|
||||
```
|
||||
4. If you want to use a local TLSNotary server: [Run a local notary server and websocket proxy](#local), otherwise:
|
||||
1. Open `app.tsx` in your favorite editor.
|
||||
2. Replace `notaryUrl: 'http://localhost:7047',` with:
|
||||
```ts
|
||||
notaryUrl: 'https://notary.pse.dev/v0.1.0-alpha.10',
|
||||
```
|
||||
This makes this webpage use the [PSE](https://pse.dev) notary server to notarize the API request. Feel free to use different or [local notary](#local); a local server will be faster because it removes the bandwidth constraints between the user and the notary.
|
||||
3. Replace `websocketProxyUrl: 'ws://localhost:55688',` with:
|
||||
```ts
|
||||
websocketProxyUrl: 'wss://notary.pse.dev/proxy?token=swapi.dev',
|
||||
```
|
||||
Because a web browser doesn't have the ability to make TCP connection, we need to use a websocket proxy server. This uses a proxy hosted by [PSE](https://pse.dev). Feel free to use different or [local notary](#local) proxy.
|
||||
4. In `package.json`: check the version number:
|
||||
```json
|
||||
"tlsn-js": "v0.1.0-alpha.10"
|
||||
```
|
||||
5. Install dependencies
|
||||
```sh
|
||||
npm i
|
||||
```
|
||||
6. Start Webpack Dev Server:
|
||||
```sh
|
||||
npm run dev
|
||||
```
|
||||
7. Open `http://localhost:8080` in your browser
|
||||
8. Click the **Start demo** button
|
||||
9. Open **Developer Tools** and monitor the console logs
|
||||
|
||||
## Interactive verification with `tlsn-js` <a name="interactive-demo"></a>
|
||||
|
||||

|
||||
|
||||
Follow the instructions from:
|
||||
https://github.com/tlsnotary/tlsn-js/blob/main/demo/interactive-demo/README.md
|
||||
|
||||
## Web-to-web proofs with `tlsn-js`<a name="web-to-web-p2p"></a>
|
||||
|
||||
This demo showcases peer-to-peer communication between a web prover and a web verifier using TLSNotary. The prover fetches data from swapi.dev and proves it to the verifier.
|
||||
|
||||
Follow the instructions from:
|
||||
https://github.com/tlsnotary/tlsn-js/blob/main/demo/web-to-web-p2p/README.md
|
||||
|
||||
## Run a local notary server and websocket proxy <a name="local"></a> (Optional)
|
||||
|
||||
The instructions above, use the [PSE](https://pse.dev) hosted notary server and websocket proxy. This is easier for this quick start because it requires less setup. If you develop your own applications with `tlsn-js`, development will be easier with locally hosted services. This section explains how.
|
||||
|
||||
### Websocket Proxy <a name="proxy"></a>
|
||||
|
||||
Since a web browser doesn't have the ability to make TCP connection, we need to use a websocket proxy server.
|
||||
|
||||
1. Install [wstcp](https://github.com/sile/wstcp):
|
||||
```shell
|
||||
cargo install wstcp
|
||||
```
|
||||
2. Run a websocket proxy for `https://swapi.dev`:
|
||||
```shell
|
||||
wstcp --bind-addr 127.0.0.1:55688 swapi.dev:443
|
||||
```
|
||||
|
||||
Note the `swapi.dev:443` argument on the last line, this is the server we will use in this quick start.
|
||||
|
||||
### Run a Local Notary Server <a name="local-notary"></a>
|
||||
|
||||
For this demo, we also need to run a local notary server.
|
||||
|
||||
1. Clone the TLSNotary repository (defaults to the `main` branch, which points to the latest release):
|
||||
```sh
|
||||
git clone https://github.com/tlsnotary/tlsn.git
|
||||
```
|
||||
2. Run the notary server:
|
||||
```sh
|
||||
cd crates/notary/server
|
||||
cargo run --release -- --tls-enabled false
|
||||
```
|
||||
|
||||
The notary server will now be running in the background waiting for connections.
|
||||
@@ -1,24 +1,24 @@
|
||||
import {themes as prismThemes} from 'prism-react-renderer';
|
||||
import type {Config} from '@docusaurus/types';
|
||||
import { themes as prismThemes } from 'prism-react-renderer';
|
||||
import type { Config } from '@docusaurus/types';
|
||||
import type * as Preset from '@docusaurus/preset-classic';
|
||||
|
||||
// This runs in Node.js - Don't use client-side code here (browser APIs, JSX...)
|
||||
|
||||
const config: Config = {
|
||||
title: 'My Site',
|
||||
tagline: 'Dinosaurs are cool',
|
||||
title: 'TLSNotary',
|
||||
tagline: 'Privacy-preserving data portability',
|
||||
favicon: 'img/favicon.ico',
|
||||
|
||||
// Set the production url of your site here
|
||||
url: 'https://your-docusaurus-site.example.com',
|
||||
url: 'https://tlsnotary.org/',
|
||||
// Set the /<baseUrl>/ pathname under which your site is served
|
||||
// For GitHub pages deployment, it is often '/<projectName>/'
|
||||
baseUrl: '/',
|
||||
|
||||
// GitHub pages deployment config.
|
||||
// If you aren't using GitHub pages, you don't need these.
|
||||
organizationName: 'facebook', // Usually your GitHub org/user name.
|
||||
projectName: 'docusaurus', // Usually your repo name.
|
||||
organizationName: 'tlsnotary', // Usually your GitHub org/user name.
|
||||
projectName: 'TLSNotary', // Usually your repo name.
|
||||
|
||||
onBrokenLinks: 'throw',
|
||||
onBrokenMarkdownLinks: 'warn',
|
||||
@@ -40,7 +40,7 @@ const config: Config = {
|
||||
// Please change this to your repo.
|
||||
// Remove this to remove the "edit this page" links.
|
||||
editUrl:
|
||||
'https://github.com/facebook/docusaurus/tree/main/packages/create-docusaurus/templates/shared/',
|
||||
'https://github.com/tlsnotary/landing-page',
|
||||
},
|
||||
blog: {
|
||||
showReadingTime: true,
|
||||
@@ -68,10 +68,10 @@ const config: Config = {
|
||||
// Replace with your project's social card
|
||||
image: 'img/docusaurus-social-card.jpg',
|
||||
navbar: {
|
||||
title: 'My Site',
|
||||
title: 'TLSNotary',
|
||||
logo: {
|
||||
alt: 'My Site Logo',
|
||||
src: 'img/logo.svg',
|
||||
alt: 'TLSNotary Logo',
|
||||
src: 'img/logo/tlsn-logo-white-on-blue.png',
|
||||
},
|
||||
items: [
|
||||
{
|
||||
@@ -80,9 +80,24 @@ const config: Config = {
|
||||
position: 'left',
|
||||
label: 'Tutorial',
|
||||
},
|
||||
{to: '/blog', label: 'Blog', position: 'left'},
|
||||
{ to: '/use_cases', label: 'Use Cases', position: 'left' },
|
||||
|
||||
{ to: '/docs/intro', label: 'Documentation', position: 'left' },
|
||||
{ href: 'https://tlsnotary.github.io/tlsn/tlsn_prover/', label: 'API', position: 'left' },
|
||||
{ to: '/blog', label: 'Blog', position: 'left' },
|
||||
{
|
||||
href: 'https://github.com/facebook/docusaurus',
|
||||
href: 'https://discord.com/invite/9XwESXtcN7',
|
||||
label: 'Discord',
|
||||
position: 'right',
|
||||
},
|
||||
|
||||
{
|
||||
href: 'https://x.com/tlsnotary',
|
||||
label: 'X',
|
||||
position: 'right',
|
||||
},
|
||||
{
|
||||
href: 'https://github.com/tlsnotary',
|
||||
label: 'GitHub',
|
||||
position: 'right',
|
||||
},
|
||||
@@ -103,17 +118,13 @@ const config: Config = {
|
||||
{
|
||||
title: 'Community',
|
||||
items: [
|
||||
{
|
||||
label: 'Stack Overflow',
|
||||
href: 'https://stackoverflow.com/questions/tagged/docusaurus',
|
||||
},
|
||||
{
|
||||
label: 'Discord',
|
||||
href: 'https://discordapp.com/invite/docusaurus',
|
||||
href: 'https://discord.com/invite/9XwESXtcN7',
|
||||
},
|
||||
{
|
||||
label: 'X',
|
||||
href: 'https://x.com/docusaurus',
|
||||
href: 'https://x.com/tlsnotary',
|
||||
},
|
||||
],
|
||||
},
|
||||
@@ -126,7 +137,7 @@ const config: Config = {
|
||||
},
|
||||
{
|
||||
label: 'GitHub',
|
||||
href: 'https://github.com/facebook/docusaurus',
|
||||
href: 'https://github.com/tlsnotary',
|
||||
},
|
||||
],
|
||||
},
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
import type {ReactNode} from 'react';
|
||||
import type { ReactNode } from 'react';
|
||||
import clsx from 'clsx';
|
||||
import Link from '@docusaurus/Link';
|
||||
import useDocusaurusContext from '@docusaurus/useDocusaurusContext';
|
||||
@@ -9,7 +9,7 @@ import Heading from '@theme/Heading';
|
||||
import styles from './index.module.css';
|
||||
|
||||
function HomepageHeader() {
|
||||
const {siteConfig} = useDocusaurusContext();
|
||||
const { siteConfig } = useDocusaurusContext();
|
||||
return (
|
||||
<header className={clsx('hero hero--primary', styles.heroBanner)}>
|
||||
<div className="container">
|
||||
@@ -21,7 +21,12 @@ function HomepageHeader() {
|
||||
<Link
|
||||
className="button button--secondary button--lg"
|
||||
to="/docs/intro">
|
||||
Docusaurus Tutorial - 5min ⏱️
|
||||
Check out our documentation
|
||||
</Link>
|
||||
<Link
|
||||
className="button button--secondary button--lg"
|
||||
to="https://demo.tlsnotary.org">
|
||||
Try TLSNotary (Chrome Browser)
|
||||
</Link>
|
||||
</div>
|
||||
</div>
|
||||
@@ -30,7 +35,7 @@ function HomepageHeader() {
|
||||
}
|
||||
|
||||
export default function Home(): ReactNode {
|
||||
const {siteConfig} = useDocusaurusContext();
|
||||
const { siteConfig } = useDocusaurusContext();
|
||||
return (
|
||||
<Layout
|
||||
title={`Hello from ${siteConfig.title}`}
|
||||
|
||||
9
src/pages/use_cases.md
Normal file
@@ -0,0 +1,9 @@
|
||||
---
|
||||
title: my hello page title
|
||||
description: my hello page description
|
||||
hide_table_of_contents: true
|
||||
---
|
||||
|
||||
# Use cases
|
||||
|
||||
TODO
|
||||
|
Before Width: | Height: | Size: 3.5 KiB After Width: | Height: | Size: 99 KiB |
BIN
static/img/logo/tlsn-banner.png
Normal file
|
After Width: | Height: | Size: 20 KiB |
BIN
static/img/logo/tlsn-logo-blue-on-white.png
Normal file
|
After Width: | Height: | Size: 4.5 KiB |
11
static/img/logo/tlsn-logo-blue.svg
Normal file
@@ -0,0 +1,11 @@
|
||||
<svg width="529" height="548" viewBox="0 0 529 548" xmlns="http://www.w3.org/2000/svg">
|
||||
<path
|
||||
d="M153.581 4.41505C153.581 1.08579 157.014 -1.04229 159.856 0.525709L202.517 24.065C203.907 24.8316 204.774 26.3268 204.774 27.9544V58.7885H226.105C228.461 58.7885 230.371 60.7624 230.371 63.1974V133.741L217.573 124.923V72.0154H204.774V504.359C204.774 505.115 204.586 505.859 204.227 506.519L182.897 545.751C181.266 548.75 177.089 548.75 175.458 545.751L154.128 506.519C153.769 505.859 153.581 505.115 153.581 504.359V4.41505Z"
|
||||
fill="#243f5f" />
|
||||
<path d="M127.984 160.194V477.639H76.7903V213.102H0V160.194H127.984Z" fill="#243f5f" />
|
||||
<path d="M383.952 477.639H435.145V213.102H460.742V477.639H511.935V160.194H383.952V477.639Z"
|
||||
fill="#243f5f" />
|
||||
<path
|
||||
d="M230.371 160.194H358.355V213.102H281.565V292.463H358.355V477.639H230.371V424.732H307.161V345.37H230.371V160.194Z"
|
||||
fill="#243f5f" />
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 942 B |
11
static/img/logo/tlsn-logo-transparent.svg
Normal file
@@ -0,0 +1,11 @@
|
||||
<svg width="529" height="548" viewBox="0 0 529 548" xmlns="http://www.w3.org/2000/svg">
|
||||
<path
|
||||
d="M153.581 4.41505C153.581 1.08579 157.014 -1.04229 159.856 0.525709L202.517 24.065C203.907 24.8316 204.774 26.3268 204.774 27.9544V58.7885H226.105C228.461 58.7885 230.371 60.7624 230.371 63.1974V133.741L217.573 124.923V72.0154H204.774V504.359C204.774 505.115 204.586 505.859 204.227 506.519L182.897 545.751C181.266 548.75 177.089 548.75 175.458 545.751L154.128 506.519C153.769 505.859 153.581 505.115 153.581 504.359V4.41505Z"
|
||||
fill="#FCFCFC" />
|
||||
<path d="M127.984 160.194V477.639H76.7903V213.102H0V160.194H127.984Z" fill="#FCFCFC" />
|
||||
<path d="M383.952 477.639H435.145V213.102H460.742V477.639H511.935V160.194H383.952V477.639Z"
|
||||
fill="#FCFCFC" />
|
||||
<path
|
||||
d="M230.371 160.194H358.355V213.102H281.565V292.463H358.355V477.639H230.371V424.732H307.161V345.37H230.371V160.194Z"
|
||||
fill="#FCFCFC" />
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 942 B |
BIN
static/img/logo/tlsn-logo-white-on-blue.png
Normal file
|
After Width: | Height: | Size: 32 KiB |
17
static/img/logo/tlsn-logo-white-on-blue.svg
Normal file
@@ -0,0 +1,17 @@
|
||||
<svg width="529" height="548" viewBox="-15 -1 550 550" xmlns="http://www.w3.org/2000/svg">
|
||||
<rect
|
||||
fill="#243f5f"
|
||||
width="550"
|
||||
height="550"
|
||||
x="-15"
|
||||
y="-1" />
|
||||
<path
|
||||
d="M153.581 4.41505C153.581 1.08579 157.014 -1.04229 159.856 0.525709L202.517 24.065C203.907 24.8316 204.774 26.3268 204.774 27.9544V58.7885H226.105C228.461 58.7885 230.371 60.7624 230.371 63.1974V133.741L217.573 124.923V72.0154H204.774V504.359C204.774 505.115 204.586 505.859 204.227 506.519L182.897 545.751C181.266 548.75 177.089 548.75 175.458 545.751L154.128 506.519C153.769 505.859 153.581 505.115 153.581 504.359V4.41505Z"
|
||||
fill="#FCFCFC" />
|
||||
<path d="M127.984 160.194V477.639H76.7903V213.102H0V160.194H127.984Z" fill="#FCFCFC" />
|
||||
<path d="M383.952 477.639H435.145V213.102H460.742V477.639H511.935V160.194H383.952V477.639Z"
|
||||
fill="#FCFCFC" />
|
||||
<path
|
||||
d="M230.371 160.194H358.355V213.102H281.565V292.463H358.355V477.639H230.371V424.732H307.161V345.37H230.371V160.194Z"
|
||||
fill="#FCFCFC" />
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 1.0 KiB |