This is part of a multipart series, Part 1: What Distribution Key Generation Is, can be found here. After key generation, the next step for the Torus Network is naturally handling the access structure to the generated keys. Almost all web standards today are designed to cater to more centralized use cases, which does present hurdles when implementing decentralized infrastructure. When execution comes about, standards are also often not implemented to the T, the tech giants Google, Facebook, Amazon and Twitter all implement the OAuth in different ways.
Accommodating to this, the Torus network’s access structure has been designed to be generalisable so that it complies with varying standards of authentication. The base data structure is a many to many relationship between keys generated and verifiers-verifierIds, visually represented below:
When a user first interacts with the Torus Wallet, before he/she logs in, the client submits a Key Assignment transaction to the network. The transaction goes through a BFT layer (Tendermint) and on a decided valid Key Assignment a new key is assigned to a combination of verifierId (e.g. hello@tor.us) and verifier which are your typical login providers (e.g. Google, Facebook, Reddit). Key Assignments are also executed prior to interacting with a new account via the wallet, be it sending ETH or others. Developers can easily leverage this API themselves here.
The data structure also allows for users to peg multiple verifiers/verifierIds to a key, making it such that a threshold number of logins are required to access it. Not unlike a multi-sig wallet that is more widely known.
Apart from giving users access to the assigned key, Key Assignments also create a representative link between a public key and a users existing account. Similar to how ENS links names (toruslabs.eth) to an Ethereum Address, we do the same with Google/Reddit/Twitch accounts. As the network is dependent on threshold assumptions, we resolve a key These links can be used initially to provide a more intuitive experience to the end-user, abstracting public keys and illegible strings away, but the use cases don’t stop there. While integrating with Web2.0 structures presents many hurdles, we now have a system that can cryptographically represent those accounts. DocuSign on the blockchain is one good example of an application that could utilize this, a user could use their Google (or even a combination of accounts) to sign on documents for legal purposes. We’re excited to see what these links may empower in the future.
After assigning a key, all that’s left is for a user to retrieve his/her shares back into the trustless context of the Torus Wallet front-end. To do this, the user first logs in to a verifier, Google for example, and retrieves an authentication token. The token can be in the form of a signature or verification code but ultimately is used to prove a login, in Google’s case their OAuth token is a signature.
The Torus Wallet proceeds to relay this OAuth token to the nodes in the network, each individually verifying against Google’s public key that the user is who they say they are. In order to prevent the possibility of a rogue node from front-running you by taking your token, spinning up a browser and pretending to be you and thereby stealing your key, we use a commitment scheme on our token similar to Bracha’s Reliable Broadcast, to ensure that all nodes can be sure that most other nodes are aware of the commitment before it is finally revealed.
This is done by generating a temporary private key that nodes will use to encrypt all communication returned back to the client. The received token is then hashed from the first API, asking for a signature on this hashed token from all nodes, bundling these signatures together as a proof, and submitting the proof together with the plain un-hashed token to each node to get back our encrypted shares.
The idea here is that as an honest node, you will never give out shares for a token whose commitment has been seen before. You want to give out shares, but you cannot be sure that the final incoming request with proof is not by a front-runner. However, you know that to generate this proof, enough nodes must have received this token and encrypted a message for a recipient with this private key.
If a front-runner had intercepted the original commitment and gotten this proof for himself, the user would not receive enough signatures and would never have revealed this token, so this scenario would not be possible. Even if a front-runner is currently intercepting this message that contains a revealed token with proof, by encrypting the share with the associated temporary private key, the front-runner has no way of decrypting it. This sounds complicated and unlikely, but it is relatively easy to spot the attack.
Once the user has retrieved the shares, he/she Lagrange interpolates them and continues interacting with the chain or application that they are using. The next part in this series will cover the front-end security model that the key is kept in — the checks and balances in place to make it trustless.
Stay Tuned for Part 3
Join our community for updates on Part 3 of our deep dive into how Torus works, and keep abreast of our progression. Do drop us a line on any of our social channels if you’re keen on working with us to bring blockchain adoption to the mainstream.
