It uses MPC and ZK to prove some data from a server (that uses TLS) is authentic given some request.

One of the simple demos is proving you received a DM from someone on twitter, without sharing your session token or login credentials with the other party.

Another idea is proving you know some exploit (think sql injection) without revealing how you did it.

Or proving you purchased some item off a website so you can review it on a neutral platform (amazon reviews but without amazon being able to manipulate the votes)

  • AtHeartEngineer@lemmy.worldOP
    link
    fedilink
    English
    arrow-up
    3
    ·
    1 year ago

    FYI its in rust, and its very much in alpha, but if you like diving in and are comfortable with rust, come play 😁

  • A1kmm@lemmy.amxl.com
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    Having to have a trustworthy notary interactively as part of the protocol during the TLS request seems like it shuts out a lot of applications.

    I wonder if it could be done with zk-STARKs, with the session transcript and ephemeral keys as secret inputs, and a CA certificate as a public input, to produce a proof of the property without the need for the notary. That would then mean the only roles are TLS server, prover, and verifier, with no interactive dependency between the prover and verifier (i.e. the prover could generate the proof first, that can non-interactively verified at any time later by any number of verifiers).