Nucypher conversation

[cammellos]

We had a chat with the nucypher team yesterday, this post will sum up what was discussed.
Here are the notes taken NuCypher | Status Meeting 02-10-2018 - HackMD

Nucypher provides a decentralized proxy-re-encryption scheme.

How it works (simplified):

1. Alice uploads a piece of encrypteddata to a supported storage layer backend (s3, ipfs, swarm are mentioned). This data is encrypted with her public key.

2. Alice can create a re-encryption key for Bob using his public key and uploads the re-encryption key to the nucypher miner’s network

3. Once the request has been accepted by the network, the data is re-encrypted using Bob’s re-encryption key and a reward (from Alice) is given to the miner in nu-cypher tokens

4. Bob can now request access to the data and is able to access it

The network

Nucypher is fully decentralized and backed up by a network of miners which are reward by the owner of the data to be rencrypted, this network is expected to be in the order of 1000s.
To request a re-encryption from nodes it would take around 1s.

Running a node

Running a node has modest cpu requirements as proxy-re-encryption is fast (20 ms for an operation)
bandwidth consumption is also modest (2 MB initial sync), but light client options can be explored.

Group chats

During our call we were mainly focused on group-chats and multi-device support, as these were mentioned as a few use-cases nucypher could be useful with.

A way we could integrate nucypher would be (simplified):

1. Alice encrypts a message once, uploads it to some form of storage
2. Alice creates a re-encryption key for each device/user pair and sends this to the network
3. Each device/user is now able to access the data

In contrast the current implementation would be:

1. Alice encrypts a message for each device/user pair
2. Alice sends a separate message for each device/user pair

Pros & Cons

This part is going to be highly subjective:

Pros

• Compared to pairwise encryption CPU/Bandwidth consumption is better (encrypt once, send once)
• Scales better than pairwise encryption
• Re-Encryption key can be retroactively given to other members, easily allowing new members to access previous data
• Potentially we can get rid of whisper, although some form of communication layer is still necessary (push notifications would do for example) to notify a user that a message has been sent
• Mailservers are not needed anymore, but the problem is just shifted to a different storage layer , IPFS (pinning), S3 (not centralized), Swarm (not ready?)

Cons

• Forces users to pay to send messages
• Price scales with the number of participants in the chat (you pay per re-encryption)
• Needs a form of storage to work (ipfs/swarm/s3)
• Relies on a third party (although fully decentralized) for a core functionality
• Darkness is not a concern of the protocol and likely little guarantees can be made

Please feel free to discuss and let me know if I missed something, I will post my thoughts in a separate post to provide a resemblance of objectivity.

[cammellos]

Personally, I can see how nucypher can be used to implement group chats, but I am not sure there’s enough reasons to do so at the moment:

1. Performance is probably the biggest reason for using nu-cypher, quoting their whitepaper as why you would use nucypher for group chats: “This avoids the overhead of encrypting and sending messages multiple times, individually for each participant.”.
   We can expect our current method (pairwise encryption) not to scale well.
   We have a few performance improvements though that can be done, similarly to what others in our situation did:

• Use whisper for multicasting (encrypt n messages, send 1)
• Use a hash ratchet, still guarantee PFS, bad PCS (encrypt once, send once), similarly to Files · master · matrix-org / Olm · GitLab , this would be trading off on security compared to double ratchet
  So overall I feel is premature to consider a more committal option.

2. Product implications, asking the user to pay to send messages is something we might want to do, but I feel at the moment is not something we can do, also difficult to explain the pricing model (the more users in the chat the more you pay?)

3. Reliance on a 3rd party. Although nucypher is fully decentralized, I feel it only answer the question: “Could the nucypher network exists after Nucypher?”, but at the moment, I feel the answer to “Would the nucypher network survive after Nucypher?” is no
   Adding nucypher services to our nodes (whisper + nucypher to give you an idea), seems like a more reasonable approach, but still fairly heavy-handed

I’d be happy to push out for a poc implementation using nucypher, as it is an interesting project and it might be that eventually is the right time to use, but I can’t help feeling that integrating with their product is unnecessary where we are at now.

[petty]

A few things:

• an additional pro of using proxy re-encryption is revocation of access to a group. This allows for dynamic private groups.
• There is a potential for us to use the tech of proxy re-encryption but not the nucypher network. I am not sure of the details of implementation, but Tux said that is something they would be willing to work with us on. This is potentially something our desktop nodes would serve as a service to light clients, or the mobile clients do it themselves… there is a lot of discussion to be had here.

[cammellos]

• an additional pro of using proxy re-encryption is revocation of access to a group. This allows for dynamic private groups.

I don’t think nucypher provides much benefits with regards of dynamic private groups in our use case, as they don’t pose much challenges and it’s a problem that has been solved before (in pairwise encryption you just don’t send a message to the user who left the group, if using symmetric-key encryption you need to re-key without the extra user, which is the same operation as creating a new group).

Moreover provided we use PFS, we would not need to revoke access, as each message is encrypted with a different key, using nucypher I guess we would just not create a re-encryption key for the user who left the group when creating a new message.

You can revoke access to previously encrypted messages with nu-cypher, but those have been potentially read and saved by the user, so not much value for us.

Providing nucypher services in our nodes is interesting, but what would be the benefit, other than being able to offload encryption to the network?

[Arj]

First of, we appreciate these discussions being public – it helps identify gaps in our communication, plus informs our product roadmap. I’ve attempted below to offer some clarity with regard to the design and economics of a potential NuCypher-powered group chat.

@cammellos

Product implications, asking the user to pay to send messages is something we might want to do, but I feel at the moment is not something we can do, also difficult to explain the pricing model (the more users in the chat the more you pay?)

The relationship between the size of a group chat and the cost is not obvious, because it depends to some extent on the way in which the NuCypher network is utilized. If we walk through an example with simple architecture and then estimate its cost, we can observe that a) the overall cost is likely to be very low and b) the cost per user does not change as the size of the group chat increases. Starting with a few design/integration assumptions:

• We configure the group chat so that its creation and maintenance involves securely distributing a shared secret (e.g. a sym key) via the NuCypher network to initial group members. This requires the establishment of one sharing policy per member, followed by the re-encryption of the secret. Once it is delivered, members can freely upload an unlimited number of encrypted messages to decentralized storage, to which all secret-holders have access. Here, the frequency of re-encryptions does not scale with the frequency of messages sent and received.
• Subsequent re-encryptions are required to refresh the shared secret with a new one – this can occur at a cadence appropriate for the security requirements, or when group membership changes. Although this does involve the NuCypher network, it does not necessarily incur extra costs on the group members. Network nodes are set up to perform this re-encryption without charging again, because the primary factor determining the cost of a sharing policy is its duration – i.e. how long the assigned nodes must remain reliably online, holding on to re-encryption keys – as opposed to the number of re-encryptions they must perform.
• Changes to group membership (i.e. adding, removing, joining, leaving) can also occur without incurring extra charges on the existing/remaining members. Adding one new member only requires a single new sharing policy, which can be paid for by that new member (or indeed, the group administrator if appropriate). From an economic standpoint, the removal of a member is similar, and can be architected in several ways – as simple as no longer sending them the latest shared secrets, or re-issuing fresh sharing policies for the whole group. Neither option requires extra payment to nodes, since the total time that they must fulfil their aforementioned duties (being reliably online, holding keys) does not change. In the latter case, the removed member also received a refund for their cancelled policy for unspent days. One can also maintain the same on-chain id during policy re-issuance, or even do the whole thing off-chain, hence gas costs are also minimized or entirely evaded.

For this example, the key takeaway is that the cost of a group chat increases at a 1:1 ratio with membership size, and hence with the number of potential payers. Therefore, one wouldn’t pay less to join a group chat with 10 members than a group chat with 100,000 members, since the other 9 and 99,999 respective members would each be covering the fee for their individual sharing policy.

Although network nodes may set their fees independently, we can estimate the overheads associated with specific use cases, yielding useful results with which to predict costs passed on to the end-user. In a competitive market, we can assume that margins will be tight and decrease over time. Let’s start with the following inputs:

• A NuCypher node runs 36 cores, which cost $1.59 per hour.
• Time per re-encryption per core is 0.25 ms.
• Split-key factor of 20 (each sharing policy is handled by 20 separate nodes). For simplicity’s sake, we’ll leave out this factor until the end.

From these assumptions, we calculate that a single node at full capacity can perform [4000 re-encryptions/second * 36 cores * 3600 seconds] = 518.4 million re-encryptions per hour. At $1.59 per hour, this means a node can theoretically provide around 326 million re-encryptions per $1 spent on computational power.

Now, to translate this into the cost of running a group chat, we’ll assume that we follow the hypothetical architecture choices outlined earlier. So, our group chat has 50 members, the shared secret is updated every minute, and each sharing policy has a lifetime of one year. This requires a total of [50 users to re-encrypt for every minute * 525,600 minutes] = 26.28 million re-encryptions to sustain the group chat over the course of the year. Plugging in 326m (re-encryptions per $1 spent), we conclude that each node assigned to this job must fork out around $0.08 in order to serve as access manager to this group chat. In practice, we split the re-encryption key amongst 20 nodes, so the total cost is actually $1.60. Passing along that cost to the user implies a lower-bound price per member of $0.03 per year. As discussed, the final figure would remain constant irrespective of group size.

[Arj]

@cammellos

Reliance on a 3rd party. Although nucypher is fully decentralized, I feel it only answer the question: “Could the nucypher network exists after Nucypher?”, but at the moment, I feel the answer to “Would the nucypher network survive after Nucypher?” is no

I think it’s entirely reasonable to be skeptical about claims of a network’s forthcoming non-reliance on the core team. However, it won’t be much longer before you’ll be able to judge the viability of a post NuCypher, Inc. network for real. We recently launched a federated testnet, where a group of third-parties (professional and hobbyist) successfully ran NuCypher software in order to spin up and maintain operational nodes – they’re actually already capable of providing a full re-encryption service. Unlike many projects, we do not intend to retain centralized components and slowly ‘grandfather’ in decentralized alternatives – right from mainnet launch the majority of nodes will not be run by the NuCypher team, and will operate independently of our existence. Currently, confirmed NuCypher node operators include institutions like Polychain and Y Combinator, POW miners like Bitmain and Bitfury, generalized miners like CoinFund and Bison Trails, staking-as-a-service providers like Staked.us, Figment, p2p.org, and of course, many independent community members.

It’s also worth adding that decentralization is deeply embedded into our underlying cryptographic scheme (threshold proxy re-encryption), and the access control service that this translates into. Splitting the re-encryption key into fragments brings greater benefits when these fragments are held on to by independent, highly distributed nodes. The more distributed the nodes, the greater the security and censorship-resistance of the network.

[Arj]

@petty

There is a potential for us to use the tech of proxy re-encryption but not the nucypher network. I am not sure of the details of implementation, but Tux said that is something they would be willing to work with us on. This is potentially something our desktop nodes would serve as a service to light clients, or the mobile clients do it themselves… there is a lot of discussion to be had here

As touched upon in my last post, threshold proxy re-encryption becomes a performant, scalable, resilient, uncensorable access control service when implementations of the scheme are run across a highly distributed and uniquely configured network. Establishing this network requires concentrated and domain-specific effort; bespoke cryptoeconomic design (staking, slashing, etc.), distribution mechanisms, community development, documentation, legal work, test networks, etc. There’s nothing stopping your desktop nodes from staking in our network though!