Key Escrow that Might Work

12. December, 2018

Instead of encrypting everything with a single government key, several government agencies need to provide new public keys every day. The private key must be under the control of a court. Each secure encryption channel needs to subscribe to one or more of those agencies. The court must delete those keys after six months.


  • No attacker will be able to monitor any channel of communication for a long period of time.
  • Generating and sharing new keys can be automated easily.
  • A single stolen key will just compromise a small fraction of the whole communication.
  • Judges will decide in court which messages can be deciphered during the storage period.
  • It’s still possible to decipher all messages of a person if there is a lawful need.
  • If a key is lost by accident, the damage is small.
  • No one can secretly decode messages.
  • The system can be adapted as attackers find ways to game it.


  • More complex than a single key or single source for all keys. It will break more often.
  • Pretty expensive.
  • Judges need to be trained to understand what those keys mean.
  • Keys will be in more hands, creating more points of attack.

Always remember that in a democracy, the law isn’t about justice but balancing demands. There are people afraid that embarrassing details of their private communicate will be exposed as well as people trying to cover the tracks of a crime.

Right now, there is no better way to determine which communication needs to be cracked open than a normal court case.


If we used one or a few keys to encrypt everything (just because it’s easier), that would put a huge attraction on this data. Criminals will go to great lengths to steal those. If there are many keys, each one of them becomes less important. The amount of damage each key can cause must be smaller in this case. It would also mean they would have to steal many keys which would raise chances to get caught.

I was wondering if one key per month would be enough but there is really no technical reason to create so few. We have the infrastructure to create one every few seconds but that might be overkill. Once per day or maybe once per hour feels like a sweet spot. Note: When the technical framework has been set up, it should be easy to configure it to a different interval.

If we spread the keys over several organizations, an attack on one of them doesn’t compromise everyone. Also, software developers and users can move around, making it harder for unlawful espionage to track them.

Police officers and secret services should not be left alone with the decision what they can watch. Individuals make mistakes. That’s one reason why you talk to a friend when you make important decisions. Therefore, the keys should be in the hands of the law.

The law isn’t perfect. My thoughts are that we would use the perfect system if it existed. Since we’re using the law, the perfect solution probably doesn’t exist or it doesn’t exist, yet. In either case, using court rulings is the best solution we have right now to balance conflicting demands. The keys could be confiscated when the case is started and destroyed when the case is closed to avoid losing access halfway through the proceedings.

Mistakes will happen. Systems will break, keys will be lost, important messages will become indecipherable, criminals will attack the system, idiots will put keys on public network drives. Is there a way that this can be avoided? I doubt it. Therefore, I try to design a system which shows a certain resilience against problems to contain the damage.

For example, a chat app can request keys from its source. If that fails, it has options:

  1. Use a previous key
  2. Log an error in another system which monitors health of the key sources
  3. Automatically ask a different source
  4. Tell the user about it and refuse to work
  5. Let the user chose a different source

The future of data

23. April, 2010

RFid Data Table from a BBC exhibition (CC: by-nc-nd)

People love to share. They share emotions, affection, information, files and personal data. But they don’t want to share that with everyone. Imagine sharing your bank statements with the IRS. Or that you just bought a very expensive TV set with a burglar. Or that you’re not at home for the next four weeks. Or photos and films of your children with a pedophile.

While people don’t talk about their private life in a public form, they do post it in social networks. They don’t want anyone to have a look at the data on their harddisks but they backup the very same data with online backup services. The line between private and the web is blurring.

Unfortunately, data can’t protect itself, so as soon as you put something online, anyone can see it, copy it, give it to someone else or keep a copy even after you deleted it yourself. The Internet doesn’t forget.

So the obvious solution is that data must become active. It must check who has permission to access it and only reveal its details to people who you have permission. How would that work?

Let’s have a look at ssh. At work, I’m accessing a server and work with an account but I have no idea what the password for that account is. How do I login? With my own credentials. I give a public key to the system administrator and he adds me to the list of people who can login. If he doesn’t want me anymore, he deletes the key from the list and I loose access. He doesn’t know my password and I doesn’t know his.

To achieve the same with data, the data must be encrypted. To decrypt it, users must ask a server for the decrypt key and identify themselves with their public key.

Of course, there are a couple of issues with this approach:

  1. First of all, it will bloat the data and make the processing (much) slower. Well, that might be an issue today but soon, progress will solve that.
  2. Users could decrypt the data once and then keep a decrypted copy. While this is true, is it an issue? First of all, these people had once access, so it will only become an issue if we want to revoke the access. Also, if they don’t backup the data regularly, a hardware failure will solve the problem sooner or later.

    Lastly, we could attach a license to data which disallows to share the decrypted copy with anyone. If anyone did, they could be sued for the license infringement. And let us not forget that most people won’t understand how this all works, so they won’t be able to do it. Plus as long as it works and it comfortable enough to use, they won’t see a reason to do it.

    For those who do understand the technology or want to abuse it, no amount of protection will be enough to stop them. This is why we have laws and courts.

  3. People could loose their data or their password. Happens all the time. But wouldn’t this approach solve both these issues? If all data was encrypted and there were servers to distribute credentials, people would have to remember just a single password for all services. The password could be strong and it could be changed with ease. Web sites could add users based on their public keys (just like ssh or OpenID). And there would be no need to worry about losing data since you could back it up with an online backup service since the encryption would happen before it is backed up.


%d bloggers like this: