A new kind of auditing - cryptographic proof of online accounts


The technology

  • Based on an original algorithm as described in the whitepaper.
  • Provides cryptographic proof without MITM-ing your connection.
  • Install the Firefox/Chrome app PageSigner, start proving pages with one click.
  • No need to give login credentials to a third party.
  • What it can do

  • Prove your name and address if it's recorded on a trusted website
  • Prove you received a threatening private message from an internet troll
  • Prove you received a money transfer.
  • Prove your status as an elite trader with something better than a photoshopped statement.
  • Prove that a scammy website doctored the claims on its front page.
  • Once you've installed PageSigner for Firefox or Chrome, you can import some sample proof files from the examples page.

    PageSigner - the easy way to use TLSNotary

    A high level technical view of TLSNotary

    This is how the main Python TLSNotary application works; PageSigner has the same core design but with some extra usability features; after you're finished here, you can read more on that here.

    A user, called the 'auditee', wants to prove to another user, called the 'auditor', a certain fact attested to by an organisation (a bank, a government, a company etc.). This fact could be a monetary balance on an account, the fact of a money transfer, a particular set of identity information such as address, amongst others. The auditor and auditee create an encrypted messaging connection between each other over some neutral communication channel (such as IRC). The auditee connects to the website as normal and logs in, and then browses to the specific page that proves the required information. Then the auditor and auditee use their encrypted connection to negotiate secrets for the SSL/TLS session such that the auditor can find out what is on the page that the auditee loads, without gaining control of the connection or seeing the auditee's login details. The diagram below gives the outline of what happens.

    The auditee has the full defense against impersonation and eavesdropping that he would have in a normal TLS protected interaction with the server, modulo a reduction in the entropy of the secrets protecting the connection (still about 20 bytes or 160 bits, which is a huge amount of protection). The differences to a normal TLS connection (marked in green) allow the auditor to nevertheless get irrefutable proof of the content of the server response, for the single response (usually an html page) that the auditee chooses. This process can, and should, occur after the auditee has established his application-level login, and so by logging out before delivering the data, he can render any session cookies invalid.
    More details are available in the documentation on github.

    Support Development