Slashdot Mirror
After the Belfast Project Fiasco, Time For Another Look At Time Capsule Crypto?
JonZittrain (628028) writes "I'm curious whether there are good prospects for 'time capsule encryption,' one of several ways of storing information that renders it inaccessible to anyone until certain conditions — such as the passage of time — are met? Libraries and archives could offer such technology as part of accepting papers and manuscripts, especially in the wake of the 'Belfast Project' situation, where a library promised confidentiality for accounts of the Troubles in North Ireland, and then found itself amidst subpoenas from law enforcement looking to solve long-cold cases. But the principle could apply to any person or company thinking that there's a choice between leaving information exposed to leakage, or destroying it entirely. Some suggested solutions are very much out of the box."
So who gets to keep the half that goes on the website? What's to stop them from getting subpoenaed, hacked, or otherwise compromised?
You do not have a moral or legal right to do absolutely anything you want.
Launch the data into oputer space on a satellite, programmed to transmit the data after a set time period. For best results, send the machine on a massive period orbit to the outer solar system, or in a pinch, crash land it it on the Moon or Mars.
Governments will either have to give up, or else fund massive space project. Either way, we win.
May the Maths Be with you!
Send it on an elliptical orbit around the sun. Depending how many years you want before the key is back in our neighborhood, you select the appropriate orbit. Hmm, perhaps SpaceX should look into it and start commercializing such a service ;)
Violence is the last refuge of the incompetent. Polar Scope Align for iOS
Most modern cryptography works because it's difficult to solve certain math problems, but the limits of "difficult" keep getting bigger. It should be possible to make a rough estimate of how much processing power will be available to break your encryption by what date, to the parties of interest. Make your keys that strong, and hope you're close.
To build off of the Belfast Project example from TFS, a 50-year timespan might be reasonable. What kind of decryption ability might we have in 50 years? I'm no expert in cryptography, but an elliptic curve algorithm with a fairly-strong key seems reasonable to me. Encrypt it, destroy the plaintext, and forget about it. Forty-five years from now, a government might have the ability to decrypt the material, but they'd have to care, first. It might take sixty years for a data-crunching powerhouse like Google to decrypt it, and perhaps in sixty-five years, they'll see fit to run a PR stunt by unlocking the time capsule.
There's a lot of guesswork and estimation involved, but such is the nature of all time capsules. You're assuming that the capsule will be intact and unlockable at a future time, which necessarily involves predicting future capabilities.
You do not have a moral or legal right to do absolutely anything you want.
There is no way to do this purely in software, because there is no way for software to verify its inputs.
It ought to be conceptually possible to implement your "passage of time" example in tamper-proofed hardware, where the clock is part of the tamper-proofed payload.
They already do that. most DRM schemes aren't infinite. Streams aren't designed to be downloaded and stored. DRM authentication servers go dark after 5-10 years.
This would at least ensure those files could be made available after the DRM servers died.
i thought once I was found, but it was only a dream.
Communications with your lawyer are privileged. Give them your information with instructions on when and how to release it. Make sure to pay them in advance.
This is standard stuff in may novels because it kind of works.
Is it 100% effective? Maybe not. But it's a layer of protection. If you are especially paranoid, give one lawyer a 1-time pad encrypted hardcopy file. Give another the key.
The world is made by those who show up for the job.
Example - 10 keepers chosen, 4 in UK, 1 in Iceland, 2 in Australia, 1 in USA, 1 in Uruguay and 1 in Morocco. Policy chosen so that the cooperation of 7 is required to decrypt. Each keeper then is thus issued 84 strings. 1 agent dies, another agent gets busted, and a third agent becomes opposed to the decryption. This leaves 7 agents. They each send their key packages in to the time capsule curator, who decrypts each package, identifies which string within each package is need to form the key, XORs these strings, then arrives at a final decryption key. Even if an intelligence organisation manages to extract keys from 6 of the agents, they won't be able to decrypt. If on the other hand, they kill up to 3 of the agents and stop them returning their keys, the decryption can still go ahead. Ideally, you would want to set n and m according to perceived risk, plus the size of the data set. For example, 36 agents and 20 required would produce a key set which would fit into a cheap 8GB USB stick.
-- In the beginning was the WORD, and the WORD was UNSIGNED, and the main(){} was without form and void...
So who gets to keep the half that goes on the website? What's to stop them from getting subpoenaed, hacked, or otherwise compromised?
Nothing in principle. However, there are secret-sharing techniques that would make this more practical: it is possible to divide a secret into N parts; but construct the divided pieces such that anywhere from 1 to N of them are required to reconstruct the original secret.
This doesn't solve the problem in any fundamental way; but it does help. You can now control both the risk of the secret being permanently lost(increase the number of parties who have parts, possibly even providing a given part to more than one party) and control the risk of enough parties being compromised to reveal the secret(set the number of required parts equal to, or close to N, and distribute the parts among different jurisdictions, storage mechanisms, and so on).
No perfectly elegant solution; but at least you get to pick your poison.
I started working on software to do this a few years back. I concluded that all the software is already written if you have a need and the problems are all regarding the way the user wants to protect the information, how much money they have to spend and how careful they are. In other words, it's a social/societal problem and you could setup a consulting service to help people do it, but software probably wouldn't be much benefit.
Here is an example:
First encrypt all the things. Then give the encrypted file to anyone since you're going to assume for the sake of this slashdot post that the crypto is unbreakable (if you're unwilling to accept this assumption then feel free to divide the data the same way the key is outlaid).
Next establish some trusts in your name and appoint a number of people as trust managers. This should probably be more than one trust and definitely more than one person. You may even need to obscure who creates the trust depending on what you're hiding and who might want to get it. Try to make some of the trust managers overseas might be good if you're worried about long term survivability of your data, since stability of a country might be in question in 100 years or so.
Now, cut your key into two halfs (or more), write out instructions that the managers are to meet at some location at a certain date. None of the managers should know any of the other managers. For survivability you might give a duplicate copy of parts of the key to multiple people so if one person doesn't show up there is still a chance to recover from it.
Ultimately nobody has knowledge of anything. On the date in question the responsible people show up only with the knowledge they are supposed to arrive with their bit of information. It could be that they don't arrive anywhere at all and their instructions are to publish the information. Without having context only the receiver would know what the completed key was for, and even they might have only been instructed to hold on to data for 100 years then accept the key when it arrives.
This scheme works best if there are multiple companies around the world formed with the purpose of doing this for people, or if it was a common service asked for at banks/law offices/etc. If the lawyer is holding on to only one key for 100 years they might become curious and try to figure out what it's for. If it's one key amongst thousands then it's nothing more than a tiny amount of data they're paid to deal with. They would also be less likely to publish the information out of turn because it could be they're storing it for something worth less than the amount they're paid to escrow it.
It is certainly less conceptually doomed than DRM; but your standard tamper-resistant hardware is unlikely to cut it for this situation:
The fundamental issue arises if data retention is a serious concern: for common uses of tamper-resistant hardware, it isn't. It's just being used as an access token of some kind, so the actual secret is largely irrelevant, so long as the attacker doesn't get it. If it gets wiped, IT/customer service will just issue you another one.
With some sort of library/archival project, there presumably is some value to the secret, possibly a large one, and there can't be a credential-issuer(or I wouldn't bother to compromise your token, I'd just mail them a subpoena...), so you can't just destroy the secret casually.
This is a problem because 'zero the secret!' is basically the only response that a tamper-resistant system has available if it detects tampering. If that option is on the table, the attacker must negotiate any sensors and failsafes the designer felt like adding, correctly, or irrevocably lose what he came for. If it isn't, the attacker just has to avoid destroying the storage himself.
Adding time as a requirement just makes things more annoying: RTCs need continuous power, and that's both an avenue for attack(especially if we are working on the scale of human lifetimes, forcing your oscillator away from its expected frequency could shave years off the delay, even in the absence of any other attack) and an area more likely than silicon to fail by accident (you don't want to lose your data just because somebody slipped a counterfeit CR-2032 into the supply chain and it had only 20% of the lifetime you expected, do you?).
This also. Crimes should be solved. Its not a fiasco. They gave written testimony to a third party that was not their lawyer, that is admissible in court.
However, I think the particulars of this situation are such ( the troubles were a terrible thing that I don't want to see reignited ), that I would not have advised the Brittish/Northern Ireland authorities to have pursued it. They're risking the peace that was very hard fought. The only innocent parties in the conflict were the innocent civilians that were killed by all of the fighting. Certainly none of the combatants, including the British government, were.
Well.. maybe. Or Maybe not. But Definitely not sort of.
I was thinking about this task a few weeks ago from the point of view of a real-world application: you're travelling in a war zone and want to ensure that your files are safe *even from yourself, your friends, your employer, and everyone who cares about you*. Because if you're taken prisoner, they're not going to use a 30 million dollar supercomputing cluster to crack the encryption on your laptop; they're going to work you over with a pair of pliers, perhaps taking off a few body parts, until you tell them. And if you don't have the key, they'll just threaten harm to you to people you care about who do - assuming they can't outright capture said people as well. Nobody you now can be responsible for the key. The key has to be held by someone who by nature of their contract doesn't give a rat's arse about you and won't change their terms even to save your life.
But of course, what if they were compromised - legally (subpoena), or extrajudicially (someone with a pair of pliers)? So we get into the sitution where a server for a service that controls giving out of keys needs to be safe even from its owners. While terms for key storage involving personal judgement calls (such as "did the person contracting with us successfully make it out of the country and is no longer under coersion?") can't be automated, simple time locks can, so the issue simply comes down to, "Can you keep reliable running key storage system that can't be compromised even by physical access"? A potential solution to reliability (since any system tht locked will be immune to maintenance as well!) would be to store the every key on multiple running systems in different locations in hopes that at least one of them lives long enough to yield the key at the correct time. As for security, for example, even with full memory encryption, ram is vulnerable to cold boot attacks and the key to decrypting memory has to be stored somewhere, but one solution to that is storing critical portions of data only in CPU cache. But that's only one possible attack vector among many. At least you could respond to a subpoena, "Hey, maybe you have a way to get at this data, but I sure don't. If you'd like to fund a multi-million dollar research project on how to get ahold of it, I won't stand in your way, I'll be fully cooperative..." You could also make it harder by having a multi-part key, with each part held by different entities in different jurisdictions. Though that could increase reliability challenges.
In short, at the very least you can make it very, very difficult to get keys. Maybe you can't stop a secret NSA raid on all physical servers taking part the world over, but you could stop pretty much anything else.
Very well; let this abomination unto the Lord begin!
"Promise me, Red. If you ever get out... find that spot. At the base of that wall, you'll find a rock that has no earthly business in a Maine hayfield. Piece of black, volcanic glass. There's something buried under it I want you to have."
Security by burying things under rocks seems as good a technique as any, in geological time.
Easier idea. Put the data in a tiny pressurized capsule and drop it deep in the ocean. After a set amount of time the capsule is designed to inflate an air bladder, rise to the surface and transmit via radio frequency.
There's no way to retrieve this ahead of time because:
1. The ocean is vast and the capsule is tiny.
2. The ocean is so deep that you would have to send a robotic submarine to find it and no one would know where to look. If you can lose a plane at the bottom of the ocean, you can lose a 1 foot capsule even more easily.
You guys are thinking too much into this. Any third party you entrust your secret to (bank authorities, lawyers, software etc) is a potential point of breach.
Just keep your information in hard copy (papers, journals etc), put it in a box, lock it up and bury it. Entrust the secret and key to a son/daughter with strict instructions it is not to be opened until you pass away, with the warning that the secrets revealed may destroy the family.
The less people know about it, the more secure it is.
I'd rather trust family who have an interest in protecting your secrets rather than some stranger or worse, impersonal unthinking code. And having a living, thinking secret keeper who can respond to challenges and situations you may not even forsee is far more effective.
A hobbit. They can be trusted. Don't you know nothin'?
No. Then it'd have to be a whole key ring.
-- Alastair
Just destroy the data reliably. There is enough vision-less scum around that anything else will be far too risky.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I think this post may be the best in the thread because it answers the question (time based, not coy power), it's somewhat practical unlike astronomical solutions, and recent events show it would be secure. If multiple motivated governments can't find an airliner, someone in a Snowden-like position could be reasonably confident that a small container dropped even just off the coast of California would remain there for quite a long time.