Three things that NuCypher's "Ursula" can do that vanilla public-key cryptography can't

The first 20 minutes of explanation of NuCypher have become fairly routine for us - explaining our mission, our process, and our initial cryptographic offering (usually including a shallow dive into Proxy Re-Encryption and Ursula, the Character in our narrative who performs this PRE operation).

Amidst a few early light-bulbs, discerning dapp developers at this point typically ask something like,"why can't I do the same things with traditional public key cryptography that I might do with Ursula?"

This is, of course, a great question.  There are three good answers - and several more OK answers.  This post will go through the three good answers and leave the reader to mull over the others.  

Disappearing Alice

Alice the Authority can set the parameters of a policy and go offline temporarily or permanently, knowing that Ursula will continue to respect the policy by performing re-encryptions.

In an orthodox "public key" cryptography scheme, the same actor who authorizes the granting of access (ie, decides which public key to use while encrypting the payload) also offers the content (ie, decides what to encrypt).

This means that this actor must remain online in order to continue to share new data with recipients.

This is not such a terrible inconvenience for the orthodox centralized web, because an expectation of that model is that a particular actor (the "Server") will remain online indefinitely.  Typically, the "Server" is the actor performing the duties of authorizing users and sharing content.

However, in a decentralized model, where nodes of roughly equal political standing seek to communicate, one or both nodes may wish to authorize other nodes to access subsequently generated content and then go offline, temporarily or permanently.

In the NuCypher cryptology, we describe this scenario as "Disappearing Alice" - Alice, the authority of the policy, may grant access to any number of Bobs for a time-frame of her choosing, and then go offline for a while or even delete her private keys.

Subsequently, devices and systems knowing the public key of the Policy (we call these friends "Enrico the Encryptor") can continue to share data on the Policy, even without knowing who the Bobs are (my personal speculation is that this feature may be specifically useful for blockchain-based games, but I haven't wrapped my head around exactly how just yet - soon).

This also means that Alice can disappear but leave a specific condition under which Bob is permitted access.  For example, Alice can instruct Ursula only to re-encrypt for a particular Bob if Bob (or his financier) sends funds to a particular address.  Conditional re-encryption is not something for which we've fully written out logic yet, but we're interested in adding these features on demand as use cases arise.

Very Small Enrico

Enrico the Encryptor can be a very small device, encrypting each message only once, while Ursula re-encrypts for a large number of recipients.

Once Alice has granted access, any device can share data with the Bobs.  These devices (again, "Enrico") might be very lightweight devices - perhaps with restricted CPU speed, a small power profile, or a narrow network connection.

Enrico only has to encrypt data once using a configurable encryption key - and only needs to perform conventional elliptic-curve operations - in order for Ursula to encrypt for all Bobs who have been granted access.  Especially in a high-throughput deployment, this can be a substantial resource savings.

Imagine a multimedia stream with 50,000 viewers and a key rotation rate of once every four seconds.  Orthodox PKE requires the streamer to conduct 750,000 encryptions per minute - requiring not only a fairly beastly rig but also perhaps consuming as much bandwidth as the stream itself.

By contrast, with NuCypher, Enrico can perform just 15 encryptions per minute, relying on NuCypher's worldwide, decentralized fleet of Ursulas to perform the 750,000 re-encryptions during that minute (50,000 times every 4 seconds).

This allows a potentially interesting frontier in privacy configuration because devices which create sensitive content no longer need to have the CPU or bandwidth to be able to encrypt that content for a wide but limited audience.

Revoke

When Alice wants a single Bob not to have access, she simply tells Ursula to revoke the Policy for that Bob.

Imagine that Alice grants access to ten Bobs in an orthodox "public key" system.  She tells 50 different devices or systems to encrypt for the 10 public keys of the Bobs

Now, Alice decides she wants to revoke access to one, with 9 Bobs retaining access.

Maybe in this case, Alice bails on decentralized tech and instead uses a centralized "key management" solution.  Or maybe that's not an option, because this is a decentralized application from the ground up, so Alice needs to actually modify the configuration of the devices to tell each of them to stop encrypting for Bob.

To do this, Alice needs to (verifiably) go around to each of those 50 devices and systems and reconfigure them to use the 9 keys of the remaining Bobs.

It may be a stretch to even call this revocation, but to the degree that it's cognizable, it surely leaves at least these requirements:

• Alice must maintain administrative access to every device and system that she wants to use to share data with the Bobs.
• The devices and systems sharing data must be permitted to know how many Bobs are able to read the data and what their public keys are.
• The devices and systems sharing data must be regarded as having sufficient privilege to witness additional grants and to revocations.

With NuCypher, the process is much, much simpler:

Alice sends a properly signed RevocationNotice to Ursula, and Ursula stops re-encrypting for that particular Bob.

This means that Alice needs only to retain custody of the DelegatingKey (the private material which allows Alice to grant and revoke) rather than needing to administer the individual systems and services doing the encryption.

Enrico just keeps on encrypting data blindly, never knowing (or needing to care) which Bobs have access.  This separation of concerns not only makes revocation far simpler in the dapp logic, but also ensures that the security concerns of the devices in the field doing the encryption are walled off from the details of the Policy membership.

It's not always clear which of these three features - or which combination of them - is part of the underlying need of a given distributed application idea.  If you think you might have a use case, we will happily poke holes in your idea until you're absolutely certain.  For that kind of treatment, feel free to stop into our Discord.