Re: time dependant
One nice number-theoretic approach to the problem of preventing someone (including the original sender) from decrypting a message before a certain amount of time elapses can be found in the paper: Time-lock puzzles and timed-release Crypto by Ronald L. Rivest, Adi Shamir, and David A. Wagner. which is avaialable from: http://theory.lcs.mit.edu/~rivest/publications.html The difficulty with this problem, in general, is that the notions of cpu time and real time don't often coincide. Hope this help, Zulfikar.
Re: [Fwd: Export Administration Act of 1979]
At 11:49 AM 3/7/00 -0500, William Allen Simpson wrote: >It was reported that Clinton was keeping the export controls going by >executive order, even tho' congress had failed to re-authorize the >sunsetted legislation. Clinton has waged wars without congressional approval. We don't need no stinkin' laws, we're the government.
Re: time dependant
At 05:05 3/8/2000 +0800, Arrianto Mukti Wibowo wrote: >Hi, > >I want to know whether there is a crypto building block which doesn't allow >someone to open an encrypted message before a certain date. > >[Damn hard. Math functions don't grok "date". The only reasonable way >to do this without a trusted third party is to pick an encryption >algorithm that will take at least as long to decrypt (in likely >available computer time) as are needed. -Perry] Perry is right. If you have a trusted third party with a secure location, you could simply have the trusted third party release the key on the appointed date. ___ Michael Paul Johnson http://ebible.org/mpj
Re: time dependant
At 5:05 AM +0800 3/8/2000, Arrianto Mukti Wibowo wrote: >Hi, > >I want to know whether there is a crypto building block which doesn't allow >someone to open an encrypted message before a certain date. > >[Damn hard. Math functions don't grok "date". The only reasonable way >to do this without a trusted third party is to pick an encryption >algorithm that will take at least as long to decrypt (in likely >available computer time) as are needed. -Perry] > >In another word, I need to know several "date/time-related" crypto papers >around. Can somebody give me pointers? > Here is something I posted to sci.crypt on the subject in 1996. (You can find it at http://deja.com/usenet by searching on the thread: ' Cryptographically secured "Time Vaults" '): PGP and the Packwood problem. Arnold G. Reinhold January 19, 1996 The downfall of Senator Packwood of Oregon after his diaries were subpoenaed by the Ethics committee of the US Senate may have brought to justice a man who abused the public trust, but it must also worry historians. Even though Packwood helped surface his diaries by attempting to use them in his own defense, many politicians will be reluctant to keep candid, private diaries in the future. Cryptography can provide at least a partial answer to this problem. I would propose that some recognized historical societies publish a series of PGP public keys. The corresponding private keys would be held in escrow for a fixed time frame and then released to the public at one year intervals on or about December 31. Thus there might be a 1996 key which would become public on Dec 31, 1996, a 1997 key that would be revealed on December 31, 1997, and so on. The keys could be produced at a special event held in conjunction with a historical or cryptography meeting. Two hundred years worth of keys, say through the year 2100 could be generated at one session. The secret keys would be kept both in magnetic and printed form, say in a Swiss bank. Or the secret keys might also be split into thirds, with two copies of each third and distributed to six societies world wide. Anyone who wished could down load one of the keys from the standard key servers. The key fingerprints might be printed in one or more historical journals. A diarist could simply use the key to encrypt his work or use the key to encrypt his own private key. The later option would allow him access to his own diaries. He could destroy his unencrypted key when trouble arose, before it was subpoenaed. There is always the threat that a judge could attempt to subpoena the historical societies' private keys. That is why the keys should be kept in countries whose laws would make that difficult. Since the keys might be used by more than one individual, the societies might have a strong argument against releasing them. There is also the danger that technology might overtake the public key technology that was used in making the keys, In that case the historical societies could make new, longer keys. Since the existence of most diaries would still be secret, the diarists or their estates could super-encrypt with the new keys. The technology threat suggests another option for a secret diarist: He could make a guess as to when a certain key size is likely to be breakable. He could then make a key of that size and throw away the public key. If he did this in front of witnesses, he could have a subpoena-proof diary with confidence that his words would become readable eventually.
Re: time dependant
In message <010601bf8879$2f4c1980$82d08489@muki>, "Arrianto Mukti Wibowo" write s: > Hi, > > I want to know whether there is a crypto building block which doesn't allow > someone to open an encrypted message before a certain date. > > [Damn hard. Math functions don't grok "date". The only reasonable way > to do this without a trusted third party is to pick an encryption > algorithm that will take at least as long to decrypt (in likely > available computer time) as are needed. -Perry] > > In another word, I need to know several "date/time-related" crypto papers > around. Can somebody give me pointers? > In the future, it may be possible to base something like this on physical principles. For example (and if I haven't dropped a decimal point), Jupiter is never closer than about 2079 light-seconds from Earth. A message encrypted with the public key of a satellite in that orbit could not be received in the clear on Earth in less that 4158 seconds. One could postulate a network of such satellites at various distances -- but it would sure strain our technology to get any reasonable delays with a single hop. Second-best would be to use repeated decryptions -- say, a message addressed to Pluto Equilateral (about 5.5 light hours away), encrypted with its key, and containing a message encrypted with an Earthstation key. That message in turn is encrypted with Pluto Equilateral's key; iterate as needed. --Steve Bellovin
Re: time dependant
On Wed, Mar 08, 2000 at 05:05:24AM +0800, Arrianto Mukti Wibowo wrote: > Hi, > > I want to know whether there is a crypto building block which doesn't allow > someone to open an encrypted message before a certain date. > > [Damn hard. Math functions don't grok "date". The only reasonable way > to do this without a trusted third party is to pick an encryption > algorithm that will take at least as long to decrypt (in likely > available computer time) as are needed. -Perry] > > In another word, I need to know several "date/time-related" crypto papers > around. Can somebody give me pointers? I don't think it's exactly what you were asking for, but couldn't you encrypt the data with a session key and then not give the recipient the key until the certain date? A related method would be to encrypt the session/bulk key with a private key who's public key is in a cert which is not valid until the certain date. At least that way you can send the data (and encryted key and cert) at once and not require the recipient to connect back for the key. Unfortunately you're depending on the cert-verifying software that the recipient uses to actually enforce the cert's Validity... and current s/w is notoriously lax on that. Any software solution like that would be hackable on the recipient's machine. -- Eric Murray www.lne.com/~ericm ericm at the site lne.com PGP keyid:E03F65E5
time dependant
mukti wrote: > I want to know whether there is a crypto building block which doesn't allow > someone to open an encrypted message before a certain date. The way I'd do this is to split up the encryption key with a shared secret scheme, then give the shares to a number of trusted third parties, who agree to release the shares at the agreed-upon time and no sooner. If they all decide to cheat on their agreement, then you lose, although if the fraction over your threshold decide to stay honest, then you win even if the rest cheat. It sounds like there might be a business in this. It's relatively straightforward to implement, and there don't seem to be any excruciatingly difficult issues of trust and policy, just whether or not the trusted third party is going to follow the agreement. Raph
time dependant
Hi, I want to know whether there is a crypto building block which doesn't allow someone to open an encrypted message before a certain date. [Damn hard. Math functions don't grok "date". The only reasonable way to do this without a trusted third party is to pick an encryption algorithm that will take at least as long to decrypt (in likely available computer time) as are needed. -Perry] In another word, I need to know several "date/time-related" crypto papers around. Can somebody give me pointers? Thanxalot, -mukti Check out my homepage: www.geocities.com/amwibowo > NEW...! Scholarship information website (6/2/00) (bahasa Indonesia) www.geocities.com/amwibowo/beasiswa.html > Indonesian E-Commerce Resource Website (bahasa Indonesia) www.geocities.com/amwibowo/resource.html
Re: [Fwd: Export Administration Act of 1979]
At 11:49 3/7/2000 -0500, William Allen Simpson wrote:
>It was reported that Clinton was keeping the export controls going by
>executive order, even tho' congress had failed to re-authorize the
>sunsetted legislation. I asked my local congress-critter about it, and
>here is the response. I found it enlightening.
And quoted his congresscritter:
>Congress often lets programs ride until a consensus can be reached. There is
>some talk that the EAA may be reauthorized this year.
Following is some info on this, including a presidental declaration of
emergency and an excerpt from the Bernstein legal team docs.
-Declan
http://www.eff.org/bernstein/Legal/970107_supplemental.complaint
STATUTORY AND REGULATORY CONTEXT
7. The EAA expired on August 20, 1994.
8. The President has continued the EAR to the extent
permitted by law under authority of the International Emergency
Economic Powers Act ("IEEPA"), 50 U.S.C. sec. 1701 et seq. Executive
Order 12,924 (1994) ("EO 12924"), 59 Fed.Reg. 43437; Notice of Aug.
15, 1995, 60 Fed.Reg. 42767 (Aug. 17, 1995); Notice of Aug. 14, 1996,
61 Fed.Reg. 42527 (Aug. 14, 1996).
Date: Fri, 14 Aug 1998 11:35:05 -0700 (PDT)
From: Declan McCullagh <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
[Actually, it's just extending the existing one. So the White House can
continue to restrict exports of crypto software like Netscape and
Microsoft's web browsers. --Declan]
CONTINUATION OF EMERGENCY
REGARDING EXPORT CONTROL REGULATIONS
On August 19, 1994, consistent with the authority provided me
under the International Emergency Economic Powers Act (50 U.S.C. 1701
et seq.), I issued Executive Order 12924. In that order, I declared
a national emergency with respect to the unusual and extraordinary
threat to the national security, foreign policy, and economy of the
United States in light of the expiration of the Export Administration
Act of 1979, as amended (50 U.S.C. App. 2401 et seq.). Because the
Export Administration Act has not been renewed by the Congress, the
national emergency declared on August 19, 1994, must continue in
effect beyond August 19, 1998. Therefore, in accordance with section
202(d) of the National Emergencies Act (50 U.S.C. 1622(d)), I am
continuing the national emergency declared in Executive Order 12924.
This notice shall be published in the Federal Register and
transmitted to the Congress.
WILLIAM J. CLINTON
THE WHITE HOUSE,
August 13, 1998
VERISIGN ACQUIRES NETWORK SOLUTIONS
VERISIGN ACQUIRES NETWORK SOLUTIONS TO FORM WORLD'S LARGEST PROVIDER OF INTERNET TRUST SERVICES Mountain View, CA & Herndon, VA, March 7, 2000 - - VeriSign, Inc. (Nasdaq:VRSN), the leading provider of Internet trust services, and Network Solutions, Inc. (Nasdaq: NSOL), the world's leading provider of Internet domain name registration and global registry services, today announced the signing of a definitive agreement for VeriSign to acquire Network Solutions in an all-stock purchase transaction. This transaction combines two infrastructure leaders whose trust services support businesses and consumers from the moment they first establish an Internet presence through the entire lifecycle of e-commerce activities. Under the agreement, VeriSign will issue 2.15 shares of VeriSign common stock for each share of Network Solutions stock as constituted prior to the 2-for-1 split of Network Solutions stock to be completed on March 10, 2000. The transaction, valued at approximately $21 billion based on yesterday's closing price of VeriSign common stock, has been approved by both companies' Boards of Directors and is subject to approval by VeriSign and Network Solutions stockholders. The acquisition is expected to close in the third quarter of 2000, subject to customary conditions, including obtaining necessary regulatory approvals. The resulting company expects to add to its existing employee base to exploit new market opportunities. At closing, Network Solutions will become a subsidiary of VeriSign and CEO of VeriSign. [more at http://www.verisign.com/press/2000/corporate/netsol.html]
[Fwd: Export Administration Act of 1979]
It was reported that Clinton was keeping the export controls going by executive order, even tho' congress had failed to re-authorize the sunsetted legislation. I asked my local congress-critter about it, and here is the response. I found it enlightening. Now, they are checking to see whether there was any _explicit_ funding for the export controls. Perhaps that could be blocked, as a money- saving initiative. The last line might be taken as a call to action -- we need to watch. Original Message If congress did not accept his action, it could have legislated his executive order out of existence. Certainly, when the Republicans took control of congress in 1995, they could have rescinded his order if they did not want it to operate. Since 1994, the 104th, 105th and 106th congresses have chosen to allow the Export Administration Act to exist under emergency authority. Many, possibly, hundreds of programs whose authorization has run out, are in existence. Congress frequently appropriates funds for these programs. For example, the National Endowment for the Arts' authorization ran out. Even though many in the current majority would like to eliminate the NEA, each year it is funded because a majority of all members want to. It is not brought up for reauthorization because no one wants to engage in the fight. The authorization for the Great Lakes Environmental Research Lab has expired also. Even so, it is funded every year. Congress failed to reauthorize the Federal Aviation Administration. However, it continues to be funded. Reauthorization legislation was up last year, but no consensus was reached on certain key issues. Congress often lets programs ride until a consensus can be reached. There is some talk that the EAA may be reauthorized this year.
RE: X.BlaBla in PGP??? BWAHAHAHAHAHA!!!!
"Phillip Hallam-Baker" <[EMAIL PROTECTED]> writes: >I think you are probably refering to Ron's paper in FC'98. I presented an >alternative and somewhat radical architecture at RSA'99 which demonstrated >that it was practical to distribute revocation info in real time for a >population of 5 billion certs. There are many good alternatives (actually pretty much everything is better than CRL's, so it's difficult to come up with a bad alternative), but the problem they all have is that they're not CRL's. To paraphrase Bob Jueneman "The market has spoken. The answer is CRL's, although noone can quite remember what the question was". Given that it's going to be very difficult to make any headway against this unless you've got a vertical-market application where you can design things the way you want them, my approach has been to try to turn CRL's into a silk purse through some form of reprocessing (a CRL -> OCSP gateway would be an example of this). That way, you can pretend to have CRL's (giving the customer exactly what they asked for) while also having a system which works. The warning from Padlipsky's "Elements of Networking Style" is still appropriate here though for anyone trying to work around the problem of CRL's: "The schoolmen couldn't find how many teeth a horse had in Aristotle; a student suggested they look in some horses mouths. They expelled him". Peter.
Re: [Fwd: Export Administration Act of 1979]
LOTT EYES CLOTURE FOR EXPORT ADMINISTRATION REAUTHORIZATION: Senate leaders have yet to determine this week's schedule, but Senate Majority Leader Trent Lott, R-Miss., today said he would like to move tomorrow or Wednesday to a bill (S 1712) to reauthorize the Export Administration Act. The measure would rewrite the Cold War-era law regulating exports with dual commercial and military uses. Lott said he may have to file cloture to proceed because several senators object to the bill, contending that it could weaken national security. Bill sponsor Phil Gramm, R-Texas, and several committee chairmen met Friday to try to reach a compromise, but aides said they still have some work left. "We should move forward on this even if there are concerns about it," said Minority Whip Harry Reid, D-Nev. A cloture vote on either the bill or the motion to proceed could occur Wednesday if cloture is filed today.
