December 2003 - cypherpunks-legacy

Delayed self-encrypting messages
by Paul Schauble 17 Dec '03

17 Dec '03

I have a need to distribute some information fairly widely, but it's critical that it not be openly revealed before a certain date. Consider the model of an embargoed press release. Can I do this with crypto technology? Can I send someone a message, and possible a program, such that the message can only be decrypted after a predetermined date? ++PLS

4 3

Re: Delayed self-encrypting messages
by dfloyd＠runner.utsa.edu 17 Dec '03

17 Dec '03

----- Begin Included Message -----

1 0

Re: New Yorker First Flame Author on TotN
by sidney＠taurus.apple.com 17 Dec '03

17 Dec '03

He was interviewed by Terry Gross on "Fresh Air", also a nationally syndicated public radio show, though not with call in, earlier this week, I think Wednesday. He came across as a very naive, "sensitive" guy, who was enamored over the possibility of an electronic academic utopian community and was rudely shocked when he first discovered the phenomenum of flaming there in his mailbox. The interview was focused on his feelings during his introduction to cyberspace and to flaming, what the world of e-mail and bulletin boards is like for technological newbies, and did not at all get into issues of pornography, anonymity, encryption, etc. He did not seem as if he would be competent to talk about those issues and he did not try to. -- sidney markowitz <sidney(a)apple.com> SK8board Punk Rocket Scientist [not speaking for Apple!] Advanced Technology Group voice: (408) 862-4319 Apple Computer, Inc., M/S 301-3D fax: (408) 974-8414 1 Infinite Loop AppleLink: SIDNEY Cupertino, CA 95014 Internet: sidney(a)apple.com

1 0

Time Locks-- Re: Delayed self-encrypting messages
by pcw＠access.digex.net 17 Dec '03

17 Dec '03

>----- Begin Included Message ----- > >>From owner-cypherpunks(a)toad.com Fri Jun 10 15:13 CDT 1994 >Date: Fri, 10 Jun 1994 13:04:07 -0700 >From: Paul Schauble <pls(a)crl.com> >To: Cypherpunks(a)toad.com >Subject: Delayed self-encrypting messages >Precedence: bulk > >I have a need to distribute some information fairly widely, but it's >critical that it not be openly revealed before a certain date. Consider the >model of an embargoed press release. > >Can I do this with crypto technology? Can I send someone a message, and >possible a program, such that the message can only be decrypted after a >predetermined date? > > > > ++PLS > > > >----- End Included Message ----- > >You could do the simple way, distribute the message, then a key at the >later date. To make sure the encrypted message is genuine, sign the message >encrypt it, then sign it again, to ensure that people know that the >encrypted text is okay. This is a good method, but let's say that you die in between? What happens? I wrote a paper on Crypto Time Locks that is a fair to okay solution. It was a loose extension on a scheme from Crypto 92 for reducing Junk Mail. Here's a summary: What you want is an encryption function f and its inverse f' such that computing f' takes some factor of n times longer than f. So if you want to lock things up for 128 days and you're willing to put in 1 day of computation time, then you look for a pair of f and f' such that n=128. One example of such a pair is DES with 48 bits of the key fixed. The locker chooses the extra 8 bits at random. The unlocker tries all 256 combinations until the correct answer is found. Actually, you want to don't want to use DES, you want to use a variant that I'll call k-DES for lack of a better name at this time. k-DES is DES with more than 16 rounds. It is DES with enough rounds to make it run for k units of time on the fastest, commonly available RISC chip. Note that this is an inherently serial computation. A better approach would probably be to use some sort of triple DES variation with more fixed bits to prevent birthday attacks. This simple version is succeptable to attacks by parallel machines. There are better versions that I don't have time to describe at this moment. You can also construct pairs of f and f' using public key functions. When you need to choose one of the two keys, set one to be 3 or 5 or some small number. That means that exponentiation for locking (encryption) will only take log(3) steps. But decryption could take log(X) steps where X is the other key. Note that the "strength" of RSA is not being used in this case. Everyone knows both keys. But decrypting with one is still a factor of n times longer. Copies of the extended paper are available to anyone curious. -Peter Wayner

1 0

Re: Time Locks-- Re: Delayed self-encrypting messages
by dfloyd＠runner.utsa.edu 17 Dec '03

17 Dec '03

(Timelock algorithm deleted) --- That is a good way for locking it up for a while, but if it is really time sensitive, the use of parallel key guessing machines would stick a sock in this method. Here are some (non crypto) alternatives that you can use if you want to delay giving out the key after posting the cyphertext of the message: 1: Give the key to a trusted party, like your attorney to give out. 2: Find some way of getting the key lost via transport via SMTP daemons. If a host gets mail regularly via a UUCP connection, bounce it X times off that host. 3: Get the key "lost" in snail mail by this route. Mail it to a friend or a neutral party (Many copies if you may be snuffed in the process, to many people, and make "smokescreen" mails too). This would only work for messages with a short delay (24-48 hours). 4: (Very farfetched, but I am running out of ideas) Use a laser to bounce the key off a far planet or some body and the light travelling to there and back may give a decent delay. I do not know how you would get a coherent message back though. BTW: The time-lock idea sounds good, the mail list driver echoed it twice :) PS: Anyone have any better ideas for a secure crypto way of doing this? ;)

2 2

UPDATE to "Please Tell Congress to Allow Encryption Export"
by Stanton McCandlish 17 Dec '03

17 Dec '03

R-IL Rep. Robert H. Michel's fax number has been changed. The current number is +1 202 225 9249. If Rep. Michel is your Congressman, please IMMEDIATELY ask him to help ensure that the Cantwell bill HR3627's crypto export provisions remain in the current Export Administration Act of 1994, HR 3937, and send a copy of your fax to the Chair of the House Intelligence Committee, Rep. Dan Glickman (D-KS), at +1 202 225 1991. If unable to fax, you can send your letter to glickman(a)eff.org, and it will be faxed or delivered by hand to Rep. Glickman by EFF. See ftp.eff.org, /pub/Alerts/export.alert for more information. -- Stanton McCandlish * mech(a)eff.org * Electronic Frontier Found. OnlineActivist F O R M O R E I N F O, E - M A I L T O: I N F O @ E F F . O R G O P E N P L A T F O R M O N L I N E R I G H T S V I R T U A L C U L T U R E C R Y P T O

1 0

Re: Delayed self-encrypting messages
by kentborg＠world.std.com 17 Dec '03

17 Dec '03

>An interesting research project would be to construct one of these to >sit in orbit. And I would even trust it to be pretty safe from physical tampering. The cost would be so high and the exposure from various space watchers rather certain. Good enough for me. Seems there are two ways so far mentioned to do this "embargo" trick: 1) Have a trusted and secure party hold your key until time. 2) Hide a key inside an expensive computation and then figure out how to get the NSA *really* interested in finding and publishing their crack of your code. If you estimated their abilities correctly your fuse will burn at the right speed, the time delay will be as you intended. (Gosh, is there a thriller novel in here some place?) I think I see a third: 3) Kinda "security through obscurity", but a dollop of "trusted" third party too. a) Encrypt the key and instructions for its distribution with Trent's public key. b) Add a message asking him not to open 'til Christmas. Encrypt again with his public key. c) Send it off on a remailer-goose chase to delay and further confuse the TLAs. Hell, maybe just skip "c". Or... Split the key into a n-of-m set of sharing fragments. Send each off to each of m Trent's. Hope that no more than m-n get lost, hope that the TLAs can't find/turn n of your Trents. -kb, the Kent who isn't as devious as he would like to be--but he is still reading cypherpunks. -- Kent Borg +1 (617) 776-6899 kentborg(a)world.std.com kentborg(a)aol.com Proud to claim 28:15 hours of TV viewing so far in 1994!

2 1

Delayed self-decrypting message
by Paul Schauble 17 Dec '03

17 Dec '03

I have a need to give several people an information file that is secured until a given date. Think of an embargoed press release for a model. Can I do this with crypto technology? Is there a way I can send out a file and perhaps a tool such that the file can be decrypted only after a given date? ++PLS

1 0

(None)
by Jeff Gostin 17 Dec '03

17 Dec '03

Paul Schauble <pls(a)crl.com> writes: > Can I do this with crypto technology? Can I send someone a message, and > possible a program, such that the message can only be decrypted after a > predetermined date? Easy to do! Send out encrypted text, along with a plaintext note explaining that the information is time sensitive. Further explain that the key needed to undo the encryption will be sent out at the appropriate time. Then, just sit tight, and wait for the time to come. --Jeff -- ====== ====== +----------------jgostin(a)eternal.pha.pa.us----------------+ == == | The new, improved, environmentally safe, bigger, better,| == == -= | faster, hypo-allergenic, AND politically correct .sig. | ==== ====== | Now with a new fresh lemon scent! | PGP Key Available +---------------------------------------------------------+

1 0

Re: back to programming projects...
by Jeff Gostin 17 Dec '03

17 Dec '03

Jim choate <ravage(a)bga.com> writes: > 2. messages will be cached and re-transmitted after a random delay. I intend > to generate a random number between 0 and 24. When the appropriate hour > arrives all messages with that time stamp will be sent encrypted. I would suggest getting a random number between 0 and 1440. This will allow messages to be sent out every minute. Of course, you could just make it once every 15 minutes (0-360) or every half hour (0-180). The idea is that there could be a rather large delay introduced to the process, and might make the remailer unpopular as a result. Mind you, I appreciate the effort and generosity. I'm just making suggestions. :-) --jeff

1 0