Many have called for a deep dive into a new protocol called 'NuCypher' that's had many people in the blockchain space excited for quite some time.

Admittedly, the aesthetic of their website and marketing is second to none in the blockchain space in terms of crypto project launches.

Normally, the buck would stop here for most blockchain projects as the actual technical merits of the protocol would matter little to the end user - since the 'end user' will be the investor in 99.9% of these cases.

## Why NuCypher is Different

NuCypher demands that we look into its technical underpinning because it proposes that it can provide cryptographic services for its users.

Specifically, on the front page of NuCypher's site, they state:

"Cryptographic Infrastructure for Privacy-Preserving Applications"

Followed by several digital cards that provide an overview of the project's supposed cryptographic capabilities.

Below are a few screenshots from the website detailing said abilities:

[1]

**A quick tl;dr of the content above:**

**Secrets Management**:*Manage secrets such as IAM tokens, database and SSH credentials, X.509 certificates, and signing/encryption keys across dynamic environments*.**Dynamic Access Control**:*Conditionally grant and revoke access to sensitive data to arbitrary numbers of recipients.***Secure Computation**:*Process encrypted data while preserving the confidentiality of the inputs and results*.

## First Impression

None of the capabilities listed above are beyond reason for a blockchain project.

Of course, if this is a token that we're talking about here - then, yes, users should be incredulous about whether the alleged capabilities of this project will actually be related to the underlying asset (which is launching soon according to the NuCypher website - but we'll get to that soon).

For now, let us continue to assess the information being given to us.

## Dissecting 'Proxy Re-encryption' (PRE)

The term, "Proxy Re-encryption" is certainly a new one that we've never heard of before.

Clicking the 'learn more' button leads us to the source of documentation for NuCypher's 'Proxy Re-encryption' cryptographic scheme.

Below is the proposed cryptographic scheme from a high level (excerpted from the documentation)

[2]

The photo above describes the scheme as:

"A type of public-key encryption (PKE) that allows a proxy entity to transform or re-encrypt data from one public key to another, without having access to the underlying plaintext or private keys."

Before even assessing this scheme, let's break down what's being said:

- In this scheme, there exists two parties as well as a message of some sort that must be encrypted buy one of those parts (let's call the pair, Alice and Bob).
- Since this is a PKI interaction (public-key infrastructure), Alice is able to successfully encrypt the message to Bob's public key (much like GPG / PGP).

What NuCypher appears to be proposing is the creation of a proxy client, whose purpose is to take that **exact same content from Alice**, then re-encrypt it to a **different recipient** (that's not Bob).

Quick math will tell us that in order for the 'proxy' agent in this case (human or not) to perform such a task, they **have to have Bob's private key**.

## Encryption and the Invertibility of Encryption / Decryption

The difference between most hash functions and encryption ciphers is that the latter are **invertible functions**.

From Gary Kessler's online book (renowned cryptographer), there are three types of encryption & decryption methods that are widely used and known in the world of cryptography.

Those are:

**Secret Key Cryptography**(SKC):*"Uses a single key for both encryption and decryption*" ; AKA symmetric encryption like AES (Rindjael) for example**Public Key Cryptography**(PKC):*"Uses one key for encryption and another for decryption ; also called asymmetric encryption"*; like PKI // just like how Bitcoin operates (private/public key pairs, but only the public key is shown)**Hash Functions**:*"Uses a mathematical transformation to irreversibly 'encrypt' information, providing a digital fingerprint."*; Many would disagree with considering one-way hash signatures to be a form of encryption, but in a sense, it is understandable to deem it as such and its probably any easier way to relay the concept of hashing to "lay folks" - which is essentially the idea of encrypting something in a mixed cipher of some sort w/o a viable decryption key (just a reliance on the knowledge required to reproduce the same output)

[3]

## Addressing the Implicit and Explicit Claims Made By NuCypher

Before delving into any accompanying research (for which there are no papers that have been published in the past 15+ years), let's take a closer look at what NuCypher is proposing in their 're-encryption' scheme.

The text above states:

"Umbral is NuCypher's threshold proxy re-encryption scheme. Alice (the data owner) can delegate decryption rights to Bob (the recipient) for any ciphertext intended for her, through a re-encryption process performed by a set of trust-minimized proxies. When a threshold of these proxies participate by performing re-encryption, Bob is able to combine these independent re-encryptions and decrypt the original message using his private key."

## First Issue: Delegation of 'Rights'

According to the excerpt above, an individual named Alice should be receiving some sort of message / mail / etc., that was originally encrypted to her public key.

This portion here is something that all blockchain users should be familiar with. The process for encrypting something to someone's key is very similar to the process Bitcoin leverages to 'sign' a transaction to someone's public key.

The only difference is that rather than proving to a network that one has a signature that matches the requisite public key (miniature proof of possession in the BTC script) needed to spend the transaction in question, it is up to Alice (or whoever the recipient is), to use their private key to decrypt the message sent to them.

Below is a graphical depiction of the process that breaks it down pretty succinctly for the more visually inclined learners out there:

## PKI is Stateless

One thing that is worth mentioning is that the PKI process that's being described by NuCypher in their documentation is a **stateless protocol** (by itself ; it can be wrapped within a stateful one though).

What does that mean?

For those familiar with GPG / PGP encryption, you are more than likely also aware of the fact that the other party does **not need to be online** for you to encrypt a message / file / etc., to their address.

You also do not need to be online to do so.

Assuming you know their public key, you'll be able to encrypt a message to them on the spot - alone - and without internet access. Delivery, of course, is another story

A graphic is provided below that gives another meaningful visual of how this process is process is typically carried out:

What is important to note here is that, at the moment that the message is **encrypted to another public key, the "control" over the message's state is now out of the hands of the one originally encrypting the message**

## Why You Have No Control Over Encrypted Text Once its Been Encrypted

This part is going to get a bit technical, but its necessary to break down why this is an impossibility (on a mathematical level).

Specifically, the following three elements are present in classical RSA public-key encryption:

- Extended Euclidean Algorithms

2. Multiplicative inverses of a variable's modulo

3. Euler's Phi Function & Theorem

## From a Higher Level

Essentially, RSA works on the premise of primes (elliptic curves are a bit different, we'll return to those later).

**Understanding Prime Factorization** = *This is the art of breaking down a number into its multiplicative bases. There is only one solution for every number on planet earth (Euclidean Theory)*

[4]

On the same webpage linked above, there's a calculator for those wishing to gain more "hands-on" experience with prime factorization.

Below is an example of the output that this tool will churn out:

Notice how there's a tree stemming from the top of the pyramid? If not, here's another example (with a much bigger number):

### The Overall Gist

In the examples that you saw above (with 15,000 and 1.5 million), the factorization of these values was pretty simple (lots of 2's and 5's).

## Higher Order Prime Numbers

As most know, a prime number is a number that is only divisible by 1 and itself (i.e., the number '11').

These numbers occur randomly in nature, dispersed throughout the infinite timeline of numbers in the wild. There is no limit to how many of these numbers there are, nor is there an intuitive formula to quickly identify all the prime numbers that will ever exist (assuming that this is something that's scaled up infinitely).

Conversely, if you multiply two primes together, you will always get a co-prime number (interesting, right?). For example, 11 x *7 = 77 (prime) ; 7 x *13 = 91 (prime) and so forth.

The foundation of RSA key creation is rooted in this very same concept, the only difference is that it expands on it by selecting two **huge prime numbers** to multiply together.

For the purpose of general understanding, let's suppose the product (i.e., key created) carries the variables, x and y (convenient, right?)

Typically there will be two other variables (i.e., a and b) that are included in the equation - where 'b' is a number that was also chosen beforehand (public).

Knowing what 'b' is makes it no more likely that one will be able to find 'a' in this equation above.

In addition, with sufficiently large primes (let's say 4096 bits or something), it should be virtually impossible for any computer of any capacity to factorize said prime and effectively 'decrypt' one's communications (this is all out the window when Quantum Computers get on the scene).

## Bigger Picture of What Was Explained

Essentially, all of that long-winded math above was done to drill in the point that the public key (produced in a PKI system) is oriented in such a way to where one can encrypt data to that public key to be decrypted by its accompanying private key due to the fact that there is a relationship between the private and public key (while the private key is deduced in a random fashion, the public key is not; however that knowledge of derivation method does not ease the load for an attacker simply trying to reverse engineer the private key in this scenario).

Using the mathematical property of 'multiplicative inverses' one is able to encrypt to a public key in a public key infrastructure which grants both users RSA keys (nowadays we've moved to elliptic & twisted edwards' curves).

## From StackExchange, here is the following theorem for deriving RSA keys

## Clarifying the 'Multiplicative Inverse' Statement

As noted in the best selected answer here on StackExchange (this is a really great site for thorough, analytical responses), "*Modular inverse can be computed with the Extended Euclidean Algorithm'*"

The miniature 'proof' (not for the hardness of the RSA problem but rather for the derivation of keys + multiplicative inverse theory is as follows):

A) d = e−1(modϕ(n))

B) So, if the attacker is not aware of ϕ(n)=(p−1)(q−1)

C) Then the problem cannot be solved *feasibly* without factorizing n = pq

Feasible in this instance essentially refers to *possible* (in the context of humanly obtainable).

## Switching Back Over to NuCypher

Given what was written above, it should be abundantly clear that there is no mechanism by which one would be able to "re-encrypt" a secret message to another party **without the accompanying decryption key** (which belongs to the entity whom the message was originally encrypted to).

Thus, if Alice wishes to redirect her messages to Bob, then she must essentially hand over her private key to Bob (without the benefit of engaging in symmetric encryption at all ; so one must assume that this would be an unencrypted community) to tell him where to find the message in question that she's looking to “redirect”.

## If a Proxy is Delegated, Then That Proxy Must Be Trusted

There is really no such thing as 'semi-trust' - either the entity in question is trusted or not.

Within the context of the protocol that NuCypher suggests (i.e., "threshold proxy re-encryption scheme"), it is suggested that there will be a threshold proxy re-encryption scheme.

The term 'proxy' is not explicitly defined, so there is no comment / speculation on what that means, but based on what was stated explicitly in the paragraph detailing 'Umbral', this process is allegedly supposed to be orchestrated via a set of "trusted-minimized proxies" (again, not sure who or what that's supposed to be).

## What is Being Described Makes Zero Sense

Generally, threshold cryptography is referred to in the sense of something that is being encrypted, which requires more than one key to decrypt.

Alternatively, there are Shamir's Secrets, which take a password / secret of some sort as its input and divide the output into pre-defined shards.

It is **strongly worth noting** that these secrets are necessary to **recreate the private key by itself ; not decrypt the data being sent to Alice**.

In either case, there seems to be no plausible explanation - given what we know to be possible & impossible / untrue - that would provide a pathway for NuCypher to enact their protocol's proposed scheme.

## Erroneous Use of the Word 'Delegate'

To reiterate a statement that was made earlier in this report, the public key encryption process is *stateless*.

Conversely, the TLS handshake and establishment of various session keys from then on (aka symmetric encryption), is **stateful** (meaning that two entities need to have an established line of communication between one another to engage in the protocol).

**Main Point** = *There can be no 'delegation' ; as described above when breaking down how RSA works semantically and mathematically, it is clear that the encryption process is a purely mathematical operation*

## No Authentication Methods Listed At All

If this cryptographic scheme proposed by NuCypher were legitimate, how would Bob ever know that the message that he's receiving has actually come from Alice?

This scheme could only have value to it if Bob were to have a reason to be in contact with Alice (which apparently he does since Alice believes Bob is worthy of being forwarded all of her encrypted messages).

And if this is the case, then Bob needs a reliable means of being able to authenticate **who sent the messages**.

Additionally, the re-encrypted message content should have some way to be authenticated before it even reaches Alice (done via decryption with AES in various modes ; chacha20-poly1305 / specifically poly1305 is the random nonce that serves as MAC / SipHash).

[6]

It would also be helpful to know exactly which cryptographic primitives will be used in the orchestration of this protocol as well, but that is not presented in the preliminary portion of the documentation (at least not on the page that we visited earlier with the now-invalidated cryptographic schemes).

## More Erroneous Claims Under the 'Secure Computation' Section

In a section of the website, labeled 'Secure Computation', it sadly appears that there are even more erroneous claims that are made by NuCypher regarding the capability of their project.

Specifically, there are nonsensical claims such as:

"Perform operations on encrypted data while preserving the confidentiality of the input and results."

[7]

This makes zero sense for several reasons, such as:

- Tampering with data (which is what this effective would be) would render the underlying encrypted blob more than likely unreadable (assuming that one was even successful in doing so anyway) ; again, these are
**mathematical operations that are taking place**, not an arbitrary delegation whose fate ultimately rest on the affirmation / denial of any entity or intent in the universe. - Without even mentioning the presence of cryptographic primitives (especially that of encryption schemes that come with IV values / MACs / hash signatures that provide a tag of some sort that is required to be viewed to ensure that the
**authenticity / integrity**of the message has been compromised...there is a guaranteed 0% chance that the sender of the encrypted information can allow the recipient to validate the underlying information with any degree of certainty. This is more than likely why typically asymmetrical encryption does not involve the encryption of data for which one would need to validate the confidentiality of 'inputs and outputs' [even that terminology is confusing because there are gerunds that are used throughout the sense (i.e., 'preserving') that yield the impression that encryption/decryption is some sort of process or remedial state of message X]).

Sadly, the Leonardo DiCaprio-in-Inception level mental gymnastics needed to make any facet of this proposed protocol logical is beginning to look increasingly absurd as we venture deeper into the proposed premise for NuCypher's operation.

## 'Secure Cloud Computing'

Moving further down into the project's documentation, yet another promise is given by the Biden team, which states:

"Perform operations on encrypted data in untrusted environments without revealing any information to the cloud provider."

[8]

Once again, not only is this proposal not possible, it is **also wholly illogical**.

Putting aside the fraudulent claim that there can be any meaningful computations done with encrypted data (which defies the very concept of encryption in the first process), the idea of being able to execute any sort of command, code, function etc. in the "cloud" (Where? The 'cloud' is not an actual finite location ...), without any information leaking in the environment that one is outright stupid to believe externally.

### Bonus Points For Outlining and Identifying the Erroneous Python Code

For some reason, NuCypher decided to provide a code snippet in an emulation-terminal box on their website next to the 'secure cloud computing' heading bearing the following:

```
import nufhe
...
ctx = nufhe.Context(0)
secret_key, cloud_key = ctx.make_key_pair()
...
ciphertext1 = ctx.encrypt(secret_key, bits1)
ciphertext2 = ctx.encrypt(secret_key, bits2)
...
# plaintext nand
reference = [not (b1 and b2) for b1, b2 in zip(bits1, bits2)]
#encrypted nand
vm = ctx.make_virual_machine(cloud_key)
result = vm.gate_nand(ciphertext1, ciphertext2)
# compare results
result_bits = ctx.decrypt(secret_key, result)
assert all(result_bits == reference)
```

Apart from the malformed syntax, referencing of undefined variables (i.e., 'make_virtual_machine', 'cloud_key', 'b1', 'b2', 'zip', etc.) the idea conveyed here - once again - makes frighteningly little sense .

In fact, what is written thus far in the documentation is so abysmally far from being rooted in any level of reality (as it pertains to code or even syntactical promises made throughout the documentation), that one has to question how a project like NuCypher has been able to survive for **as long as it has**, and even find itself in a position to hold a viable ICO / IEO / fundraiser of sorts where there is a legitimate valuation being given here above $0.

# References

[2]: https://www.nucypher.com/proxy-re-encryption

[3]: https://www.garykessler.net/library/crypto.html#types

[4]: https://www.calculatorsoup.com/calculators/math/prime-factors.php

[5]: https://crypto.stackexchange.com/questions/22490/rsa-key-generation-how-is-multiplicative-inverse-computed

[6]: https://www.adalabs.com/adalabs-chacha20poly1305.pdf