Skip to content

docs: fix typo in "threshholded" to "thresholded" #31

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
mdqst wants to merge 1 commit into
base: main
Choose a base branch
from
Open

docs: fix typo in "threshholded" to "thresholded" #31

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions docs/claim-creation.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -199,7 +199,7 @@ There you have it! The complete flow for creating a claim on a attestor.

## TOPRF

We support threshholded [OPRF](https://en.wikipedia.org/wiki/Oblivious_pseudorandom_function) to obscure sensitive data in a proof in a consistent way.
We support thresholded [OPRF](https://en.wikipedia.org/wiki/Oblivious_pseudorandom_function) to obscure sensitive data in a proof in a consistent way.

Let's take an example of where this may be used. Say you want your users to prove their DOB to you via some govt. ID, and simultaneously want to ensure no two users submit the same ID proof to you. To de-duplicate the data, you'll need to see their ID number, which they may not want to reveal to you.

Expand All @@ -209,7 +209,7 @@ This is where TOPRF comes in -- it allows you to verify the uniqueness of the ID

A simple hash such as SHA256 could work, though in certain cases, it may not be secure as hackers or malicious actors can use a rainbow table to reverse the hash.

OPRF gets around that by requiring a server (the attestor) to generate the hash, rate-limiting any attempts to build a rainbow table. Moreover, with TOPRF (threshholded OPRF), no single server can generate the hash -- it requires multiple servers to come together to generate the hash, further securing the data.
OPRF gets around that by requiring a server (the attestor) to generate the hash, rate-limiting any attempts to build a rainbow table. Moreover, with TOPRF (thresholded OPRF), no single server can generate the hash -- it requires multiple servers to come together to generate the hash, further securing the data.

### Can the attestor see the private data I am hashing?

Expand Down Expand Up @@ -324,4 +324,4 @@ Extracting application data from the transcript can get a bit tricky, since some
- The last byte of TLS 1.3 messages tells us the content type of the message. If it's `0x17`, it's application data.
- The record header of all TLS1.2 application data messages is `0x17`, thus making it easy to identify application data.

The implementation can be found [here](/src/utils/generics.ts?ref_type=head#L248).
The implementation can be found [here](/src/utils/generics.ts?ref_type=head#L248).