NuCypher is a project to bring key management systems (KMS) to the blockchain, so that decentralized systems and applications can become more secure. For the NuCypher code review we start off with an example of how their tech works.
(When you’re done reading, visit the full NuCypher ICO review.)
Alice has sensitive data that she wants to be able to delegate access to
Alice encrypts her data using her own public key and stores it in the cloud, or decentralized storage
Alice delegates access to Bob. The data is rekeyed to Bob’s key in storage
Bob downloads the data and decrypts it with his private key
The data is rekeyed to Bob’s key in storage. The original signing could not happen with just the private key alone, otherwise rekeying won’t be possible. Let’s quickly jump into private and public keys.
Let’s say I take message “NuCypher Code Review” and I encrypt it with a private key. I would get
0xca92b9be89c0506044cacd947f1630f271aa8c2cb97916b65487f3944245b67b5f2166ff995c605a5ae1c8ac9bd77760f1e90837545fd5be9c87c4f9bf3c71f11b
Someone who gets hold of the above has no way to reverse engineer it. So what is the value in this? Given 3 inputs, the public key, the hash, and the original message, it is possible to prove that the above was indeed signed by the private key of the corresponding public key. You can confirm this by verifying the signature.
So now you know that I have the private key for the corresponding public key provided. This is how I can prove ownership.
The big thing here, is that with only the original hash, and not the original data, you can’t rekey this information. This is where other key systems come in place that allow for multi key ownerships. So my assumption is that NuCypher must have a similar implementation, let’s jump in.
nucypher-kms and mock-net are the two that interest me, so let’s grab nucypher-kms first.
We have the standard players in the tech stack game, kademlia, rpcudp, lmdb (this one is new), and Ethereum VM contracts.
At this point I realized that Umbral is actually the core, so we changed to pyUmbral
Very cool, so Alice can generate a re-key for Bob, by creating a new shared key via Alice’s private key and Bob’s public key. Bob can then re-encrypt based off of this.
So the process flow would be;
Alice signs data, stores data publicly. Bob wants access and requests access from Alice with his public key. Alice creates a new pair (not technically, but keeping it this way for simplicity), Bob can then decrypt the data with his private key.
Data in transit is never disclosed publicly unless one of the parties discloses it from their end. I like it, let’s keep going.
Back to nucypher-kms:
Good structure, good comments, good encapsulation. I like the layout and content so far.
This is nice, they keep their Alice and Bob theme through all of the code, they add in their user stories before each function and they keep function calls specific, like from_alice above, and having bob as an argument to create the policy between the two of them. This is code written with other readers in mind, I don’t see that often.
REST server with a few basic endpoints, nothing overly fancy.
Local storage using sqlite. The REST functions are solid, moving on.
Another nice implementation, p2p node swarm. Nodes can join and are requested to store encrypted data.
Nice straight forward implementation on Nodes.
So so far, we have the Umbra implementation that allows for the resigning, we have the basic policies implemented to allow for a contract to be made between two participants, and we have the base for the nodes to request storage from one another.
Let’s look at the blockchain side of things:
Time for some smart contract goodies. Escrow contract.
First need to understand PolicyManager, moving to it.
Still not sure what PolicyManager does, it’s a mix of storage policy and staking policy, it has both outlines. I’ll consult the whitepaper.
MinerEscrow, no slashing for misbehaving. This is vesting, not staking, since nothing is at stake. Still, a nice vesting contract for miners.
So, boot up a node, provide re-encryption cycles, minimum token stake required to become a node, rewarded for activity. The token economy seems a bit forced, but it’s standard nowadays to reward people like this, so going to move on.
NuCypher Code Review Conclusions:
Very good code, strong architecture, all core use cases have been proved. It’s a solid implementation with a high caliber skillset. It’s using the standard, ‘let’s incentivize people to provide CPU/Storage/Network by paying them in our token’ philosophy, the staking (vesting) and token economy does seem a bit pushed on top of the solution instead as a natural component to it, but I don’t have any fundamental issues with this approach. Decentralization is a different beast after all.
Not a blockchain, but a novel idea, is there really a demand for Decentralized Dropbox, Encrypted Slack, or patient-controlled electronic health records that you have to pay for? Don’t know, but it’s good code.
Commentaires