Carlos Pérez
Jul 17, 2018 · 11 min read

Today, We will talk about Parity’s Secret Store feature and it’s possibilities, also trying to explain as much as I can all the cryptographical and blockchain background that lives inside of it.

Fashion picture to make the post look more technical.

So.. What’s Secret Store? Why we want to have this thing enabled and running on our private/permissionated blockchain? Is it working or just ideas that one day… maybe…. will become real? Let’s go for it!

When we are on permissionated/private blockchain environments, it usually means we are trying to get apart of this uncontrolled ETH/BC… price volatility, in order to build blockchain applications on a business and community level.

Secret Store is a feature that Parity team developers have build on it’s ETH client that basically allows us to store on the blockchain a fragmented ECDSA key which retrievals are controlled by a SmartContract. All of this, running under a Threshold System that makes nodes unable to read the keys on it’s own and makes your documents or secrets totally safe.

Let’s try to split into different parts all of the explanation to understand better how our documents are even more secure when we use a Secret Store scheme:

That’s a basic and actual scheme that applies, for example, on mailing services:

figure 1 — SMTP/Mailing Webservice architecture

As We can see on figure 1, Alice (PC1) sends the mail even via (https) to the Outgoing mail server, who encrypts it and sends the data through the internet to Bob (PC2). Since the mail goes to Bob, he has the right permissions to decrypt it and read the data or download attached files.

What is the problem of that kind of schemes?

As we can see, the Outgoing and Incoming server owner/s, are able to read the data Alice wrote or attached to the mail. As they are the ones who encrypt the mail before and after the data travels around the World Wide Web.

It’s hard for a non-technical user to figure out to solve the next problems:

  • Encrypt the mail locally will be a solution.
    But leaving apart that a regular user doesn’t have the knowledge to do this properly, Alice will need to send the keys by mail possibly, which makes encryption useless because the mailing service servers will be able to read the key and then decrypt de data.
  • Alice also has to think about the idea that the data is stored on the mailing service servers and she can’t erase that info when she wants. That means that she has to trust that the mailing service is deleting an email when she selects that option on the browser.
  • Alice can’t send large amounts of data through the mailing service as they are limited to a certain size in MB. That will force she to split the data into parts, encrypt them separately and then, send de different Sk’s to Bob to let him decrypt the data. That’s a huge waste of time to send data which isn’t even secured. Appart of that, Bob, once has the data decrypted, will need to figure out how to assemble all the parts.

Notice that maybe Alice, doesn’t want to trust on a mailing service and she only wants to send data to Bob without mailing or messaging services and in a secure and fast way, but nowadays, it’s hard to do it on an efficient way.

So what can Secret Store do for Alice on that kind of schemes?

What this Parity feature can do for Alice is to generate and store on a distributed way an ECDSA key pair linked to a Key session.

All the parties involved on the Secret Store Scheme. (Link to Parity Technologies wiki section.)

Here we have a basic scheme that may bring some light to our explanations and definitions of the Secret Store.

  • Alice and Bob are the actors on our example. They want to share a secret (encrypted data on a secure and decentralized way).
  • In order to let the actors interact with the blockchain, a Secret Store API is opened on an specifical port on one of the nodes. (One of the Secret Store nodes will accept HTTP SS-API requests).
  • The Three nodes that compose the Secret Store module are configurated to serve as distributed ECDSA key-sessions generation engine, and as threshold-cryptosystem needed solvers.
  • On the top of this scheme, we have a Permissioning Smartcontract, where the sender of the actors (in our case Alice) will be able to set which adresses are or not allowed to retrieve the cryptogtaphic tools to decrypt the document.
  • Note that other regular nodes are also present on the blockchain (holding transactions, mining etc..). But they don’t take part on that key sharing session.

That means that Alice will be able to encrypt it’s document, mail, password, code etc.. with a Sk (Secret Key) generated by a threshold ecosystem of nodes ( threshold can be chosen by Alice). By doing this, Alice now only needs share a Document Key ID (which is a “link” to the key session opened by her) and share it altogether with the encrypted document with Bob.

Once this is understood, why this scheme provides a level of security unreachable by any data-sharing service until now?

If you remember the mailing service example, the servers were able to read the data flowing between them (Secret stuff that Alice Sent to Bob).
This also happens on Dropbox, Drive, and other storage services, where you have to trust on a 3rd party (it’s not using/reading your data, it’s securing it good enough etc…)

If we now analyze the Secret Store Scheme, we have to understand just two crucial differences:

  • Alice’s secret data has never been seen by any of the nodes, and obviously, isn’t stored on the blockchain, it’s stored encrypted on Alice’s PC/phone etc.. So she has the control and the rights to share this information with the people she wants, and most important, to give access to the addresses she wants on the permissioning Smart Contract.
  • Every Secret Store node, only saves a portion of the ECDSA key (which is totally useless). That means the decryption key can only be generated if a consensus is reached by an amount of SS-Nodes bigger than the threshold Alice chooses. Which comes to the fact that any node owner has the possibility to know the full decryption key, and adds decentralization on the equation. (We just solved the figure 1 schemes problem).
Average reaction after reading the last points.

Why the Threshold-Cryptosystem and the ECDSA split?

A cryptosystem is called a threshold cryptosystem, if in order to decrypt an encrypted message or to sign a message, several parties (more than some threshold number) must cooperate in the decryption or signature protocol. The message is encrypted using a public key and the corresponding private key is shared among the participating parties.

Let n be the number of parties. Such a system is called (t,n)-threshold if at least t of these parties can efficiently decrypt the ciphertext, while less than t have no useful information.

Here you have a mathematical approximation I’ve made. It pretends to help to understand better the “magic” of the threshold cryptosystems:

5 grade polynomial function.

Now, you just have to suppose that this polynomial function, can be as hard as we want, and then, the threshold-cryptosystem too. Also, think that this polynomial function can contain some parameters related to our ECDSA Sk (Secret Key).

One point in this example contains info about the function as the ECDSA key portion stored on the SS nodes does about the full ECDSA decryption key.
But with a single point, two points… or whatever number of points under the threshold (11) it’s impossible to get the hole curve function. As it’s impossible with less than t+1 Secret Store nodes collaborating, get any info about the full ECDSA Sk.

The full technical implementation and the details can be reviewed here: ECDKG: A Distributed Key Generation Protocol Based on Elliptic Curve Discrete Logarithm.

Efficient Multi-Party Digital Signature using Adaptive Secret Sharing for Low-Power Devices in Wireless Networks.

So now it’s pretty easy to see why is this interesting, this means that the ECDSA Sk it’s stored in the blockchain on a way that no node can use the info it has to decrypt any message on it’s own (as could happen on schemes like figure 1) and it’s information about the ECDSA Sk has no sense or value if the threshold isn’t reached.
Even reaching this threshold, they will only be able to generate cryptographic tools to let Bob decrypt the data, but nodes will never learn anything about other’s SK portions.

And this is in my opinion, a pretty important thread because makes even more private all the information you want to send to someone.

But wait for a second.. We’ve understood how Alice is able to encrypt her document, but now, she only has it’s document encrypted, the Document Key ID, and an opened session. How can Bob now receive this document and also decrypt it?

That makes us arrive tho the second point:

  • Now Alice only has to share her encrypted document and it’s Document Key ID with Bob for example through Whisper (which will be cool as **** because messages won’t stay there forever and this will even increase the security). But it can also be done over every single messaging/mailing service because we aren’t giving any info about the keys to decrypt the file. Alice can even store this encrypted data on a cloud service like Drive or Dropbox.
  • In fact, if you understood okay the last points, it doesn’t matter if Alice wants to share this encrypted file and it’s Document Key Id, because the key session can be controlled with a Smart Contract, which means that access can be restricted by Alice to everyone except Bob.
  • But We will talk about this later. Now, focusing on Bob, the only thing he will need to do is execute some commands on the user shell against the Secret Store HTTP API-Node (curls for example) on where he will sign the Document Key Id, send it to the server with some extra info, and after some interactions with it, Bob will receive the following cryptographic tools: decrypted_secret, common_point, decrypt_shadows.

That means two things:

  • Bob has the right permissions and Identity on the blockchain (Pk, address…) to be able to get the session keys and retrieve those parameters.
  • That parameters are the only thing Bob needs to decrypt Alice’s document.

Now that you’ve seen the full process, here I leave you the full workflows to summarize a little bit the explanations and show the full interaction process between the blockchain HTTP API open node (And the Secret Store environment), Alice and Bob.

Encrypting process:

Parity Technologies Work Flow structure of the encryption process.

Decryption process:

Parity Technologies Work Flow of the decryption process.

And there we have it, all of the processes between Alice, Secret Store nodes, and Bob.

Adding permissioning on the Secret Store Scheme.

So now that we have a way to share encrypted messages on a totally secure and distributed way, it’s time to define who can access to the key sessions and retrieve the Decrypt Shadows, the Common Point, and the Decrypted secret.

To do this, we will use a Smart Contract and Configure the Secret Store nodes to read and check the permissions from there and to let Alice, choose which Pk’s or accounts have access to the key session.

One simple example of this SmartContract will be the following:

So as we see, the nodes will first check if the Pk/account is requesting the parameters to decrypt Alice’s document, and Alice can choose which are valid, and which are not.

Note that more complex permissioning contracts can be done, your imagination is the only limit:

pragma solidity ^0.4.11;

contract SecretStorePermissions {
mapping (bytes32 => address[]) keyOwners;
mapping (uint => bytes32) keysIndex;
uint keysCount;

function addKey(address[] users, bytes32 key) public {
keyOwners[key] = users;
keysIndex[keysCount] = key;
keysCount = keysCount + 1;

function checkPermissions(address user, bytes32 document) public constant returns (bool) {
bool key_found = false;
address[] owners;
for(uint i = 0; i < keysCount; i++) {
if (keysIndex[i] == document) {
key_found = true;
owners = keyOwners[keysIndex[i]];
if (!key_found) { return false; }
for (uint j = 0; j < owners.length; j++) {
if (owners[j] == user) {
return true;
} return false;


So to get an idea of what will happen if Charlie and Bob try to get those params, I’ve made the full Thibaut’s Secret Store implementation in order to show the Secret Store nodes responses.

( I just wanted to point out that it’s a nicely written tutorial and you can find it on Parity GitHub’s Wiki. I also wanted to congratulate and say special thanks to Thibaut for all the support and info he provided to me, it was so much helpful ).

Here we have the results of the Smart Contract implementation on a blockchain running with Secret Store enabled and fully-configured:

The 3 SecretStore nodes running a PoA (Proof of Authority) blockchain.
The users node running and the responses captured.

Left side -> A regular node that Alice, Bob, and Charlie used to connect to the Blockchain that had Secret Store configured.

Upper right side -> Charlie’s response after trying to get the session key and retrieve the decryption parameters when that permission has not been granted to him by Alice on the permissioning Smart Contract. Note that he gets a 403 Forbidden Access error.

Downright side -> Bob’s response after trying to get the decryption parameters with the appropriate permissions. We can see the JSON response with all the decryption parameters.

What applications can Secret Store have? What can this feature revolution on the private/permissionated blockchain ecosystem?

  • An obvious one is what we talked at the starting part of the post and it’s the fact of being able to share data with others through a blockchain ecosystem. Data that no one will be able to read it (even node owners which is pretty important and was the handicap we had on previous schemes shown on figure 1 avobe).
  • And also mention that this scheme is GDPR friendly in order that no personal data or sensitive data is never deployed/uploaded to the blockchain, the user who encrypted it is the only one ho has the rights to share the document and the key session with others.
  • We can encrypt SmartContracts and create MarketPlaces with DAPPS giving developers the assurance that nobody will be able to read or copy their code. Making the DAPPS-design business much more viable as well as the Apps in the Android’s MarketPlace.
  • We can evolve the permissioning SmartContract in order to create a private-transactions ecosystem, which is something that most of the blockchains want to do.
  • We aren’t putting on the blockchain large amounts of data, instead, we just save our keys on a secure way, and then, we can save the encrypted data (which will be less heavy than the original) on our favorite cloud-storage service without any worries about our privacy.

So that’s all for today’s post. I hope you’ve learned something about what you’ve read.

Feel free to leave your comments, questions or contact me.

Special thanks to Thibaut, Jose Luis Muñoz, and all of my CaelumLabs teammates.

Have a nice week!


Caelum Labs

Blockchain adventures

Carlos Pérez

Written by

Blockchain & Rust Developer at Dusk Foundation. Passionate about Blockchain, networking, cryptography, and meerkats.

Caelum Labs

Blockchain adventures

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade