// COMPLETE THREAD

Re: Time release crypto

2 expanded posts ยท every known parent and child

NODE ccf6a80cRe: Time release crypto
>>What minimal requirements would be needed to support encrypted packets/files
>>that a holder could only decrypt after a certain date/time?

Technology can't solve the problem, only help a bit; algorithms
aren't timebound.  In particular, true security depends on only
being able to decrypt if you have the correct information, and there's
no way to create decryption information in the future from 
encryption pieces you have now without being able to create the 
same information now.

Tim's 1993 article suggests spreading data around with 
> independent escrow agents who handle large volumes of messages
> and agree to hold them for various amounts of time. 
and depending on reputations and market forces to ensure honesty. 

> The decryption key to the original message is itself broken
>up into several or many pieces and scattered to a network of
>"remailer"-like agents (they are essentially "remailers into the future,"
>by agreeing as part of their protocol to hold messages for some amount of
time). 

What Tim almost, but not quite, mentions here is Shamir Secret Sharing -
you can split messages into N pieces, of which any M can reconstruct
the message and any M-1 don't contain enough information to resolve 
their equations uniquely, leaving you with _no_ known correct bits.

Tim's message also talked about having lots of data flowing around in 
a remailer-like fashion, but that may not be untraceable by subpoenas,
#---
# Bill Stewart, Freelance Information Architect, stewarts@ix.netcom.com
# Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281
#---
NODE 4f038f8eRe: Time release crypto
On Tue, 19 Sep 1995, Bill Stewart wrote:

> Technology can't solve the problem, only help a bit; algorithms
> aren't timebound.  In particular, true security depends on only
> being able to decrypt if you have the correct information, and there's
> no way to create decryption information in the future from 
> encryption pieces you have now without being able to create the 
> same information now.

Some of the following is probably idiotically obvious, but to prevent an 
attack on such a time keeper, it could be tied in to the atomic clocks, 
it could poll several PC's and check their time... any significant major 
time change would be spotted immediatly...  that is you couldn't possibly 
change the time on many machines at the same time without having physical 
access to all the machines, etc.  Altering the time on an atomic clock 
would be visible to just about everyone, etc.

This in now way would prevent an attacker from stealing the passphrase to 
the time signing service, so it wouldn't prevent anyone from issuing 
false keys.  But by using a hardware random generator the time keeping 
service could know if it issued a key or not by storing all the keys it 
issued previously.

This would achive the following: even if a theif stole the key, with 
enough randomization, the stolen keys would show up as valid, but would 
not show up in the time server's database - which should be written to 
write-once-media such as worm, or CDROM, etc...  the stolen key would 
generate valid time signatures, but would not be on the database, so it 
would be clear it was forged.  To get around this, the bad guy would need 
constant physical access to the time keeper, not just a single black bag 
job.

This also means that this database must be publically searchable at all 
times.  Perhaps the generator phassphrase should also be changed randomly 
as time passes - but then these things too would have to be stored 
somewhere before the time the key expires...

This is probably a bit far fetched, but the time keeper could be tied 
into astronomical events - that is have it follow the path of planets, 
star systems, etc. and derrive time that way and compare it with what 
time it thinks it is.  This would require quite a lot of sensors and 
extra hardware to track stars, planets, etc...   The bad guy would have 
to do a lot more work to get around this...  basically what you want to 
do is track some totally unalterable event to keep track of time, and we 
presume the NSA cannot change the orbits of planets... yet. ;-)


Another method would be to set up a key breaking system which would 
accept weaker keys - say 300 bits or so, and start breaking them.  This 
wouldn't guarantee they wouldn't be broken before such and such time, and 
wouldn't prevent anyone from running their own on faster hardware, or 
building special hardware optimized to break it faster though...  but 
without the private key, the only way to break it would be to brute force 
it.

==========================================================================
 + ^ + |  Ray Arachelian | Amerika: The land of the Freeh. |   _ |>
  \|/  |sunder@dorsai.org| Where day by day, yet another   |   \ |
<--+-->|                 | Constitutional right vanishes.  |    \|
  /|\  |    Just Say     |                                 |    <|\
 + v + | "No" to the NSA!| Jail the censor, not the author!|    <| n
==========================================================================