---

---
# NuCypher | Status Meeting 02-10-2018

Agenda:
- intros
- potential functionality in status
- proxy re-encryption
- potential implementation ideas

Questions:
- metadata leaks
- real-time communication support

Needs:
- multi-device operation
- "MacLane" Good use case as well

Participants:
- Corey | Status
- Andrea | Status
- Jacek | Status
- Arjun Hassard | NuCypher
- MacLane Wilkenson | NuCypher
- Michael Egorov | NuCypher
- Tux | NuCypher

Acronyms:
- PR - Proxy re-encrpytion
- PFS - perfect forward secrecy

Notes:
- MacLane: whats up
- Andrea: one to one chats
- paired wise encryption for multiparty
- tux: what is our threat model, similar to signal
- Andrea: for one-to-one, yes. Group, we haven't decided.
- Tux: that's fine, there's room for a lot, particularly with PR
- PFS with PR
- highly customized.
- Jacek: before details, two things:
1. censorship resistance
- excluding server based solutions
2. minimize metadata leaks
- gossip protocols for hiding routing and other such
- tradeoffs will always follow
- Tux: nucypher solves decentralized portion of this
- users can re-encrypt entire history
- Tux: what have you guys thought of so far?
- Jacek: Before that, quick into to how this group chat works
- What is it that's being re-encrypted exactly
- Andrea: I'll try and explain it in our own words
- MacLane: mostly accurate description
- also revocation potential
- similar to PGP (shows slides **PLEASE INCLUDE IF POSSIBLE**) https://github.com/nucypher/slides/blob/master/slides.pdf
- Jacek: what kind of online capability is possible:
- how often does a user need to perform things in order to chat? membership changes, ever message, etc
- Michael: the party does this, not individuals
- in pricincple, you can do it once for new members, but more beneficial for every message
- for PFS, you need every message
- as well as history of group chat
- Arjun: this is potentially an intersting input for customization (per user vs. per message type settings)
- Andrea: if we have PFS, we can't allow users to decrypt previous messages
- Michael: PFS for every message, not as bad performance-wise becasue PR is fast enough (milliseconds at most)
- slowest part is the request to a network to do it
- for performance optimizations, in principle, you could change symmetric keys less often. This has potential security trade-offs
- Corey: security implications of less often:
- Michael: how granularly you can revoke access and previous information
- Arjun: what do you guys invisage with the main goals?
- Jacek: we're providing access to the Ethereum network and allowing users to do whatever they want.
- we care more deeply about use cases in maybe communication aspect, but need generality.
- we'll be focusing on chat part and then make it as good of a secure messager as possible.
- Arjun: de-prioitize telegram-style chat
- Status: probably a good idea
- Andrea: how long does it take to do the PR process
- Michael: you generate key yourself, the time is the distribution of the key. Probabaly on the order of a second, mainly node communication time
- Corey: can the underlying existing network be leveraged?
- Michael: not good to combine flooding type messaging with specific delivery system like PR
- Jacek: Requirements for running a re-encryption node
- Michael: not that heavy. Biggest requirements would be if you need to run someting like the full ethereum state on your node. Re-encryption itself is fairly lightweight.
- minimal node - raspi could cope with this
- Jacek: how many per second with rPI
- Michael: approximation 20 ms/re-encrypt/core
- ~100 re-encrypt per sec for rPi
- Tux: re-encrypt is techically similar to sig verify, and less of a load
- pretty much a bignum multiply
- Jacek: Node discovery, how stable do you imagine the network to be and how much bandwidth to stay a participant in the network.
- Michael: we expect # nodes to be $O(10^3)$
- you can expect initial sync to involve couple MB
- doesn't need to run like that on mobile
- mobile is more sense to have lightclient approach where you don't have actual mobile to talk to decentralized network, but route through larger nodes
- Jacek: also curious about ongoing traffic:
- Michael: nodes should not come and go too often because they commit to uptime. Incentivized
- Jacek: what do we need to deploy to get a minimal MVP out?
- Michael: initially, we have python implementation
- need to do key-generation / re-encryption on side of client
- NuCypher needs to create a JS implementation
- we run golang everywhere
- Michael: do you have openssl available
- only thing client-side is re-encryption key-generation
- Tux: openssl bit - Go library is not full with PR part
- currently a binding to openssl go library
- Andrea: we'll look at it - TODO FOLLOW-UP
- Jacek: how much is open source
- Tux: pretty much everything except more recent research work not related to PR.
- Michael: PR good for controlling access, not necessarily computation
- Corey: how much do we break if you break?
- Jacek: What needs to go down for NuCypher to go down
- Tux: re-encryption key sent to N nodes, need response for M nodes. For PR to fail, you need to have more than M nodes to go offline
- Jacek: no central point of failure,
- Tux: correct, our organization is decentralized, completely.
- Michael: mechanism to request PR is more vulnerable than actual PR process.