# Timestamp Based Encryption

## alienjon

I was wondering if anyone has heard of an encryption method that uses time as the key instead of a password or key pair - particularly if it is used to protect a storage/compression method (such as a zip, tar, etc...).

In other words, lets say I had a file or set of files that I could compress to a tar and set an encryption 'password' to it, except instead of a password I set a time (2015 11 12 13:30) or time range (10:00 - 14:00) and that the file can be accessed by anyone (or maybe anyone with a matching key pair) but only after the set time or within the time range.  Attempted access before, or otherwise outside, of the time specified would be rejected much as it would if a provided password is incorrect.

This may be a very specific problem set, but I wondered if anything like it exists.  A search for encryption and timestamp comes up with a whole separate concept.

----------

## Hu

I see people propose this sometimes.  The problem is that it cannot work as described.  You could use a particular time as the source for your key derivation function, but how do you enforce that the person trying to decrypt it does so in the time range you picked?  If they know you used a timestamp as the key, they can derive keys for every plausible timestamp until they find one, without regard to whether that timestamp is in the near future, near past, distant future, or ancient past.  The only way for this to work is to have the decryption key held in a secure store that will only disclose the key during the approved times.  At that point, you could use any standard encryption scheme, since the security is provided by the time locked vault, rather than by the algorithm.

----------

## alienjon

 *Hu wrote:*   

> The only way for this to work is to have the decryption key held in a secure store that will only disclose the key during the approved times.

 

This is more of what I had in mind.  It isn't that the decryption would require the original timestamp but, instead, would be held and only become available at the time or time frame defined during the encryption process (maybe timestamp is the wrong word to use here and is messing up a further search).  Think of a coo coo clock where the bird comes out on the hour.  There's a window of time starting exactly on the hour and lasting for maybe 5 or 10 seconds where the door opens, the bird comes out and does a little chirp before returning and the door closes.

The storage could easily follow other encryption patterns as you mentioned.  I had this thought such that anyone with access to the file could decompress its contents, but only during the timeframe identified when it was compressed in the first place.  Similarly, it could work with a password or key pair but both would fail unless access was attempted during that same timeframe.

----------

## Akkara

This is difficult to do without going to quantum magic where you entangle the q-bits holding the key with some others and then arrange for things to de-cohere within some timeframe, rendering it inaccessible.

You can encrypt the file with a random key, call it key1.  Then encrypt key1 with a second key (call it key2) and store the encrypted key1 in the file or somewhere secure (TPM chip perhaps).  Accessing the file requires knowing key2, which is used to decrypt key1, which is used to decrypt the file.  At the set time, arrange for something to overwrite the encrypted key1.

But this can be bypassed at any of several steps:- make a note of the encrypted key1 before it "expires"

- interfere with the expiry process

- save the decrypted contents of the tarfile

In short, it's probably impossible to do it unless you control everything about the environment that uses the decrypted contents.

What are you trying to do, anyway?

----------

## davidm

 *alienjon wrote:*   

>  *Hu wrote:*   The only way for this to work is to have the decryption key held in a secure store that will only disclose the key during the approved times. 
> 
> This is more of what I had in mind.  It isn't that the decryption would require the original timestamp but, instead, would be held and only become available at the time or time frame defined during the encryption process (maybe timestamp is the wrong word to use here and is messing up a further search).  Think of a coo coo clock where the bird comes out on the hour.  There's a window of time starting exactly on the hour and lasting for maybe 5 or 10 seconds where the door opens, the bird comes out and does a little chirp before returning and the door closes.
> 
> The storage could easily follow other encryption patterns as you mentioned.  I had this thought such that anyone with access to the file could decompress its contents, but only during the timeframe identified when it was compressed in the first place.  Similarly, it could work with a password or key pair but both would fail unless access was attempted during that same timeframe.

 

You need something which:

a) provides an input to the algorithm based on time

b) cannot be simulated or "faked" (e.g. setting your computer clock to a certain time)

That poses a big challenge and would require a lot imagination and thought probably to pull of.

Kind of a OT thing but sort of related.  As a teen I was always fascinated with the idea of EME communications (Earth-Moon-Earth) or "moon bounce".  The idea that there was a known delay was interesting and I considered that it would be neat to perhaps use it as like a "time capsule" and to be able to bounce signals off of other celestial bodies further distances away to arrive at a set time (due to space and light speed constant - for the moon as stated in the article it is around 2.4 seconds dpending) when the reflected/bounced signal would arrive back.  Of course there are some big technical problems with this idea but it reminds me a bit of what you want to do and made me think of it.  :Smile:   Anyway good luck with the project.  It sounds interesting.

----------

## Irre

 *alienjon wrote:*   

> I was wondering if anyone has heard of an encryption method that uses time as the key instead of a password or key pair

 Your idea is good, and it used to combine a known password with a generated.  Google "SecurID" for instance, where you have a separate hardware token to get a new 6 digit pin code every minute. 

(Clocks must be synchronized). 

Generate something like 354464 852457 778657 986560 594450. Let's say 778657 is the correct PIN. If the system also accept adjacent PINs, the clock can be adjusted! (My idea)

----------

## msst

 *Quote:*   

> The storage could easily follow other encryption patterns as you mentioned. I had this thought such that anyone with access to the file could decompress its contents, but only during the timeframe identified when it was compressed in the first place. 

 

And even with such an external "time vault" you can never have the decrypted content expire if it is in any way loaded or displayed on a system the person has full access to. He can simply grab and preserve the content then. So once decrypted within the timeframe = forever decrypted.

There have been rather foolish attempts to have images or emails "expire" on android, but of course it fails once the person seeing this has a rooted android and interferes by copying it in time or locking it against deletion.

----------

## Ant P.

 *alienjon wrote:*   

> I was wondering if anyone has heard of an encryption method that uses time as the key instead of a password or key pair - particularly if it is used to protect a storage/compression method (such as a zip, tar, etc...).

 

Yes, actually. The Linux ransomware that was in the news this week was cracked, trivially, as a result of using the timestamp as an encryption key.

That should tell you all you need to know.

----------

## alienjon

 *Akkara wrote:*   

> This is difficult to do without going to quantum magic where you entangle the q-bits holding the key with some others and then arrange for things to de-cohere within some timeframe, rendering it inaccessible.

 

I hate to say that this is beyond my knowledge of encryption (which is limited at best) though I imagine you are referring to how the bits themselves are rearranged in a seemingly meaningless order?

 *Akkara wrote:*   

> You can encrypt the file with a random key, call it key1. Then encrypt key1 with a second key (call it key2) and store the encrypted key1 in the file or somewhere secure (TPM chip perhaps). Accessing the file requires knowing key2, which is used to decrypt key1, which is used to decrypt the file. At the set time, arrange for something to overwrite the encrypted key1.
> 
> But this can be bypassed at any of several steps:
> 
>     - make a note of the encrypted key1 before it "expires"
> ...

 

Could the key itself be the timestamp, though?  Opening the file would compare to machine's timestamp and a match would decrypt the file (much as providing the correct password would decrypt an encrypted file).

That having been said, the brute force method for this idea (matching at least your second bypass thought) would be to change the machine's time (or at least simulate the change) until the right time is found.  I imagine even slight logic could find a pattern that would match the required timeframe.  In such a case a secondary protection method (such as password or key) would be required.

 *Akkara wrote:*   

> What are you trying to do, anyway?

 

Super top secret super stuff.  No, really.  I was driving home from work and my mind happened to wander to this from some other connected thoughts.  No particular application in mind, though, but when I looked online and didn't see anything immediately I wondered why.

 *davidm wrote:*   

> Kind of a OT thing but sort of related. As a teen I was always fascinated with the idea of EME communications (Earth-Moon-Earth) or "moon bounce". The idea that there was a known delay was interesting and I considered that it would be neat to perhaps use it as like a "time capsule" and to be able to bounce signals off of other celestial bodies further distances away to arrive at a set time (due to space and light speed constant - for the moon as stated in the article it is around 2.4 seconds dpending) when the reflected/bounced signal would arrive back.

 

Hadn't heard of this before!  Thanks for sharing the thought  :Smile: .  I imagine that it would take some precise calculations to figure out when and what information to even read, much less in a practical situation.

 *mas- wrote:*   

> And even with such an external "time vault" you can never have the decrypted content expire if it is in any way loaded or displayed on a system the person has full access to. He can simply grab and preserve the content then. So once decrypted within the timeframe = forever decrypted.

 

Do you mean that once it's opened someone could make a copy of the stored information (the copy of which wouldn't be protected)?  That would be true, but also true of any other method where once it's decrypted you could make any number of copies of the information.

 *Ant P. wrote:*   

> Yes, actually. The Linux ransomware that was in the news this week was cracked, trivially, as a result of using the timestamp as an encryption key.
> 
> That should tell you all you need to know.

 

Indeed?  I didn't hear about this.  Do you have a link to a story on this?

----------

## Ant P.

 *alienjon wrote:*   

> Indeed?  I didn't hear about this.  Do you have a link to a story on this?

 

http://labs.bitdefender.com/2015/11/linux-ransomware-debut-fails-on-predictable-encryption-key/

----------

## szatox

You can make an authentication system based on timestamps, such things existed for decades and are sometimes known as one-time passwords when you carry a calculator with a clock and some secret data inside, and it makes a password you can use for a very short time. It's Basically a bit awkward and inconvenient CHAP authentication, but it works pretty well, because accepting an answer to a challenge is an action you can perform or deny. It's your arbitrary decision.

Going the other way will not work. Doesn't matter what you do, once you encrypt something you receive a chiphertext. This chiphertext is invariable. It was the same 10 years ago as it is now, and in the next century it will still be the same.

Why shouldn't I set my wall clock to 2116? Why should a kid not click "I'm 18" button?

It's getting even worseIf you encrypt the same plaintext with another key. At this point there are 2 chiphertexts and only one of them has to be broken to reveal the information.

----------

## alienjon

Thanks for the discussion on this everyone, very interesting!

----------

