Your Magical Privacy Toolbox

Do you use everything inside, or is it much larger than you think?

People think privacy in a single direction, but this is not very accurate.

Privacy is a complex tool, and it is very possible that you use it less effectively just because you miss some important angle of it.

TL;DR Use cryptography better to make your application cooler.

Through this article, we will touch 5 key takeaways that are usually missed by application owners.

Let’s explore them.

First of all, private data

Private data is simple: It is what you get when you encrypt something.

Regardless of your storage, once you encrypt with a secure key, it becomes private. Once encrypted, you can keep it in your own PC or upload it to the blockchain, there is no difference.

This point is important: You do not need to keep your data private, but only your encryption key. This is a very common mistake: You cannot assume something is more secure just because the access is not straightforward. This is not how cryptography works (check out Kerckhoffs’s Principle).

1^st Takeaway: Keep your encryption key secure, not your data.

Yet, plain encryption is not really flexible, and it has limited use cases. For instance, if you are interested in storing your files, documents, or photos; a very good solution can be to encrypt them with a key and upload it to the blockchain. This makes sure that as long as you keep your key, you can access your files anywhere any time.

This use case has 2 obvious flaws:

The first is that only you can execute on your data. You cannot really share your files with anyone or run an algorithm on it. If you are interested in only storage, no problem, but not many products are that simple. Let’s move on from this problem for now.

The second is that the key is a single point of failure: If you lose your key, everything is lost. Or if someone steals it, then they can access all files you have uploaded so far with it.

How to keep your key secure?

There is no perfect answer, but there are 2 practices that you should be well aware of to improve the problem.

One; Key rotation with deterministic key generation.

Do not use the same key over and over again, rotate it regularly. The observation here is that if different data points are secured with different keys, then the losing of a single key constitutes a smaller risk.

However, deriving and securing a random key each time can be costly. Moreover, if all keys are stored in the exact same way, then the security of the overall system does not really improve. Hopefully, cryptography again comes to the rescue.

It is actually enough if you have a master key that is only used during key rotation, and each other key that you use is a single way derivation of it: For instance, you can take the hash of your original key plus the hash of number of keys you had so far while deriving your next key. Since the master key is only accessed to regenerate keys, it is much less exposed, thus much more secure than each individual encryption key.

For instance, you can keep the master key in an offline device all the time, and only access it without an internet connection when you want to generate the next key rotation. Moreover, even if a temporary key is accessed, only some portion of data is at risk, since it is impossible to find other keys from the accessed one.

This solution requires you to store only a single key, as before, but decreases risk of theft dramatically. All thanks to hash functions.

2^nd Takeaway: Hash functions are great, and you probably do not use them enough. Key generation is a simple but powerful example.

Two; Public Key Encryption

In most systems, encryption is much more common than decryption. You may need to encrypt something each day, but you only decrypt when you want to reaccess it. So the question is, can we design a system to only use the key during decryption, but not encryption?

Yes, this also does exist! This is called public key encryption, which is very similar to signature in some sense (the exact opposite in fact). You have your private key, that you only use to decrypt your data, but all your encryption is done with the public key. In fact, even someone else can encrypt it for you!

This is quite useful. First of all, it decreases the amount of key usage you need. You get to be able to encrypt anything without risking your key at all. Moreover, you can even make your users or friends encrypt something for you.

3^rd Takeaway: You only need a key to decrypt, not encrypt. Use this for more flexible architectures.

How about private execution?

Private execution is an oxymoron as a term: Any execution you do is private if you do not share the data. But in the blockchain context, this actually means that you are able to make someone work on your data, without revealing your data to them. Small but important detail.

This is possible mainly with FHE (fully homomorphic encryption), MPC (multi party computation) or TEE (trusted execution environment). All these solutions have pros and cons; details really do not matter for this article. But beware of something important.

Even though private execution sounds cool, it is not a must in many cases. It addresses two very specific problems:

1. You are not able to perform the computation on your own, and you actually need someone else’s machine. Examples may be AI or genetic algorithms, not common in standard applications.

2. The computation should be done on multiple parties’ data simultaneously, without any party sharing their own. For instance, you want to learn the mean of some shared variable, but without knowing anyone’s specific data point (This is an amazing MPC use case by the way).

The point is that: If you are designing your own application, you probably do not need these two. Private execution is really an institutional use case more than anything, so the fact that it is not always practical is not a huge problem. I describe a powerful solution in the next chapter.

Nevertheless, in full honesty, no privacy solution is perfect without any private execution. Common examples are voting and blockchain payments. Faster FHE (that we will see in a relatively short time I argue) will enable amazing new use cases; but again, do not wait for them.

4^th Takeaway: Private execution is amazing, but not necessary in most cases. Keep reading to learn what is the alternative.

Finally, private proofs

As always, it all comes to zero-knowledge.

ZK is very common as a term in our ecosystem, but not many discuss its real potential. Being able to prove something in private is not a privacy solution, it is a completely different paradigm.

For instance, you may need to complete your ID verification in many contexts. But in very few, your actual data is relevant. The only thing you need is a proof that you have some information on your ID, like age, and nothing more.

ZK fills this gap. It allows us a way to design a system without any data at all. Data is not shared, it is not encrypted, it is not a secret. It is simply not there.

The main difference to conventional privacy tools is that most ZK systems have information theoretical privacy, meaning that they literally do not contain the information inside. This means that no attacker, even with quantum computing or an ultimate computer, can never ever get your data out of your proof. This is thanks to entropy and information theory.

So whenever you need to do something with your data, ask yourself this question: Do you really need the data itself, or you are just trying to get a conclusion from your data?

5^th Takeaway: Do not use your data, unless you absolutely have to.

Wrap up

Privacy is a complex concept. It is much more than we can describe in a short article.

The main point was that we do not use the technology we have as much as we can. So stop waiting for the next breakthrough, and discover the options you have in hand.

That’s why we are here to help.