3

I have a number of time sensitive, embargoed pieces of information that I need to distribute over the Internet and have received at a precise time. I'm currently dealing with the problem by uploading to a shared Box.com folder at the time we wish to release, but since the data is large (100-200mb) and the receivers have varying levels of Internet access (from none to 1gbps+), this means that some people receive it hours later than our embargo time.

I have considered uploading the info early, but encrypted and emailing out the key at the last minute, but since not everyone has always-on Internet, that doesn't quite solve the problem (and getting to Internet access isn't always possible). Similarly, the volume of people receiving precludes a teleconference or similar where the password is given out (not to mention that sometime the data needs to be released at midnight).

Is there a method I can use to set up an encrypted archive on a time-release? Complicating matters; is there a method I can use that is relatively straightforward for non-technical users to set up on their own machines?

I'm wondering if there's a way to do this easily and relatively cheaply with trusted hardware, such as RSA tokens we can distribute, but not being able to necessarily trust the machines is a sticking point.

I only need granularity down to about the half-hour - this isn't financal market moving stuff.

Improve this question

2 Answers 2

Reset to default
4

Unfortunately (for you), computers are deterministic systems. What a computer can compute, it can compute -- and it can do so at a speed which depends quite heavily on the computer model. This means that you cannot enforce an exact timing without external events: without extra input, a computer is an isolated system and can reach any computable conclusion from the available data at a speed which will depend, roughly, on its price.

So you need a reliable clock somewhere in your system. When you envision publishing a decryption password, then you are the clock. Using encryption is a good idea since encryption concentrates secrets: instead of having to deal with 100 megabytes of data, you just have to publish a small size value (the decryption key), which can be small enough to be typed manually by a human or even uttered over a phone call.

At that point, you have a choice, which is where the clock is:

  • The clock could be in the physical hands of each customer. This calls for a tamper-resistant device which can store a key, includes a clock, and can perform some computations over both. This page pretends that the "VaultIC" line of USB tokens includes a real-time clock and can implement the TOTP generator for time-based passwords, so it has the needed potential. Some specific on-board programming would still be needed, though, to match your needs.

  • The clock is not in the physical hands of each customer. Instead, they must contact someone (e.g. you) (or be contacted) at the publication time. There are various ways to convey information in our modern world: Internet-based (Web, emails...), phone calls, SMS, radio... The idea here is that if customers cannot be expected to always have Internet access at the right time, they must have a link with the external world. If one of your customers is a Buddhist monk who lives as an hermit in a cave on the flank of an Himalayan mountain and goes to the nearest village only once a month, then that customer will be hard to reach; but, similarly, it does not matter much that he gets the embargoed information immediately since he does not have any contact with anybody -- such information is useless to him until his next contact with civilization.

    Publishing the decryption password on your Web site and sending it by email to the customers and sending it by SMS to the customers, ought to be sufficient. Customers who cannot be reached by any of these means are decidedly away from the connected World, and therefore can wait.

Improve this answer
1
  • VaultIC looks like the sort of thing I'm after; SMS is tricky because reliably sending SMS internationally (which is where a lot of the out of contact people are) is a tricky issue. I hadn't heard of VaultIC before today, but it looks very promising. Commented Feb 10, 2013 at 4:16
0

Not without internet access and even then, not really securely. Any local time on a computer could be changed, so it would have to be a cryptographically signed central time server, but even then, this falls in to the realm of DRM rather than encryption and is inherently weak unless you don't release the key until the given time. Simply put, you need to do it by distributing the key in some manner. Doing a time based key release is always going to be tricky, but there isn't really any other way to deal with it other than not releasing until the time and then distributing as quickly as possible, possibly through different channels for different individuals.

You might be able to work a hardware system that has a tamper resistant internal clock, but the logistics of that are going to be even trickier and more expensive.

Improve this answer
2
  • SecurID tokens aren't out of the question - the tricky part is how to arrange the files/crypto to only work with keys generated after a certain time. Commented Feb 10, 2013 at 2:38
  • SecurID wouldn't be all that secure because while you could require them to enter the current code, it lacks the faculties to time protect the key release. You could write a program that required a code after a given point to be entered, but that program would only really be able to obscure the key. Alternativly, I guess you could forward generate a number of codes and encrypt the key with each of those codes as a password, which would give a limited time to access the key, but it would also simplify offline attacks significantly as there would only be 100,000,000 possible keys. Commented Feb 11, 2013 at 13:49

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.