- cypherpunks-legacy - lists.cpunks.org

GAK by TIS
by jya＠pipeline.com 17 Dec '03

17 Dec '03

Network World, August 26, 1996, Page 1 Key-escrow firewall ready to leave the country by Ellen Messner, Washington D.C. After months of talk about exporting encryption software, there will finally be action. Fulfilling the Clinton Administration's vow to end export restrictions on strong encryption products if they use key-escrow features, the U.S. government this week is expected to permit Trusted Information Systems, Inc. (TIS) to sell its Data Encryption Standard (DES)-equipped Gauntlet firewall overseas. Such exports will allow U.S.-based companies to standardize on an encrypting firewall for all global operations. The Department of Commerce is granting mass-market export status to a specific version of the Gauntlet firewall based on a key-escrow scheme that gives U.S. law enforcement access to a master key for decrypting IP datastreams. The master key for each firewall will reside at Oakland, Calif.-based Source Files, Inc., the third-party private key holder chosen under the government's groundbreaking plan. Vice President Al Gore has supported the Defense Department's view that unbreakable encryption should be controlled because it is a powerful weapon and subject to misuse by criminals and terrorists. However, Gore recently said the government will allow mass export of 64-bit encryption products if they use key escrow. The agreement with TIS is the first evidence that the policy is being put into practice. Until now, few companies other than banks could get the State Department and National Security Agency (NSA) to let them export 56-bit and higher Data Encryption Standard (DES) products. Only 40-bit products, easily broken with available computer resources, were allowed for mass-market export. "We're on the verge of a major shift," said TIS president Steve Walker last week. TIS expects to unveil a raft of other vendors in the network industry that will license the TIS data recovery method for accessing data encrypted with a session key. The government is also considering approving other third- party keyholders in addition to Source File, which has traditionally held source code in escrow on behalf of companies worried about the long-term viability of their suppliers. Just say no Not all are key-escrow converts, however. In fact, it is painfully clear that corporations will continue to balk at the prospect of their encryption keys being held by a third party or the government. Netherlands-based Royal Dutch Petroleum Co., with hundreds of subsidiaries and offices all over the world, is looking to ditch dedicated private lines and send encrypted IP traffic over the Internet instead. The State Department's mass-market license for the Gauntlet means TIS can compete to provide Royal Dutch Petroleum with its encrypting firewall. But Homayoon Tajalli, TIS vice president, acknowledged that the Dutch oil conglomerate is unwilling to hand its encryption keys over to Source File. Hence, as part of negotiations with the U.S. and Dutch governments, Royal Dutch Petroleum agreed to operate its own data recovery center for the Gauntlet master keys. Royal Dutch Petroleum would hand over the master encryption keys to to Dutch law enforcement, which in turn would give the keys to U.S. authorities "if the government shows up with a valid warrant," Tajalli said. TIS went to great lengths to broker the international arrangement, and hopes that not every firewall export will entail such laborious negotiations. Some firewall users are extremely ambiguous about the government's key-escrow plan. "I'm not sure I want the government to have that ability," said Doug Miller, information systems manager at Bluestone Corp. "At all cost, we've got to keep the government out of business operations." [End] Thanks to BC.

2 1

Re: DON'T Nuke Singapore Back into the Stone Age
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 6:35 AM 8/31/96, Arun Mehta wrote: >There are two sides to this: after all, it is the Singaporeans who finally >have to sort out this problem with their government, and denying them >the Usenet platform for discussion would only hinder that process. The point is to make clear to them that the Usenet and similar Web sites are global in nature, not subject to censorship without a very high local cost. If discussions of Lee Kwan Yew's dynasty are considered illegal, then Singaporans will have to choose not to carry the various newsgroups into which *I* post such messages! (This was done by many of us during the Karla Homulka and Teale trial in Canada a couple of years ago: Canada imposed press restrictions on discussion of the trial and the grisly evidence...and then was chagrinned to find that the global Net did not adhere to their notions of what should and could be discussed. They even seized copies of "Wired" at the border, very much akin to Singapore's stone age policies.) >Then again, inappropriate postings are the bane of the Internet: the consensus >on which the Net functions relies heavily on people not posting >inappropriately. This works imperfectly, as all long-time surfers of the Usenet will attest! And _never_ has it involved determinations of "inappropriate" by _governments_! Our point in protesting Singapore's actions (and Germany's, France's, America's, India's, etc., in other cases) is to technologically subvert their notions that their politicians can determine what the Net, Web, and Usenet carry. To be blunt, if Singapore wants to stop me from discussing the dictator Yew and his feeble son, they can't. Except by pulling the plugs on forums in which my posts are carried. I consider this a Good Thing (that politicians in Country A generally have no power to tell citizen-units in Country B what they can say and what they can't). The point of being sometimes "impolite" (*) is to "force their hand." (* I find it Orwellian that being "polite" is taken to mean not saying anything controversial. It was impolite for Salman Rushdie to write "The Satanic Verses," is was impolite for people to mention Karla Homulka in talk.politics.canada, it was impolite to point out that the prime minister of India drinks a glass of his own urine every day, it was impolite to refer to Bill Clinton's dalliances with Paula Jones, and so on. In a free society, all things are discussable. That various countries want to make the Net less free is not something we should support, even if it is more "polite" to accede to the wishes of their dictators, secret policemen, demagogues, preachers, and henchmen.) --Tim May -- [This Bible excerpt awaiting review under the U.S. Communications Decency Act of 1996] And then Lot said, "I have some mighty fine young virgin daughters. Why don't you boys just come on in and fuck them right here in my house - I'll just watch!"....Later, up in the mountains, the younger daughter said: "Dad's getting old. I say we should fuck him before he's too old to fuck." So the two daughters got him drunk and screwed him all that night. Sure enough, Dad got them pregnant, and had an incestuous bastard son....Onan really hated the idea of doing his brother's wife and getting her pregnant while his brother got all the credit, so he pulled out before he came....Remember, it's not a good idea to have sex with your sister, your brother, your parents, your pet dog, or the farm animals, unless of course God tells you to. [excerpts from the Old Testament, Modern Vernacular Translation, TCM, 1996]

10 12

Below-bit-level encoding
by Dale Thorn 17 Dec '03

17 Dec '03

Does anyone have info or know of a text source on less-than-bit-level file preparation? I presume the crypto techniques would be the usual stuff; I'd like to dig into bit deconstruction a little, and a text which has a chapter or more devoted to this and other esoteric file processing would be helpful. Note that this is not substitution or bit-packing or whatever. Thanx.

1 0

RE: Mimic Function Stego Programs?
by Adamsc＠io-online.com 17 Dec '03

17 Dec '03

On Fri, 30 Aug 1996 09:33:18 +0100, Andy Brown wrote: >> dictionary: 1=sofa 0=couch >> input: The couch is very comfortable >> output (0): The sofa is very comfortable. >> output (1): The couch is very comfortable. > >This idea generalises well from human to computer assembly languages. >You often have a choice of which instruction to use to achieve your goal, >and a stego assembler could quite easily be constructed. I *like* it! - "'Anonymity is bad,' says a source who wishes to remain anonymous." - Nuff' said. * Home: Chris Adams <adamsc(a)io-online.com> | http://www.io-online.com/adamsc/adamsc.htp * Autoresponder: send email w/subject of "send resume" or "send PGPKEY" * Work: cadams(a)acucobol.com | V.M. (619)515-4894 | (619)689-6579 * Member in good standing of the GNU whirled hors d'oeuvre

1 0

Re: Intel to rule the basic crypto engine market?
by Adamsc＠io-online.com 17 Dec '03

17 Dec '03

On Fri, 30 Aug 1996 19:42:31 -0700, Ross Wright wrote: >goverment (government) >alow (allow) >here cries (Should be hear) >atemps (attempts) >instpected (inspected) >believeing (believing) You know, we've all realized that even an anal retentive can use a spell checker on someone else's posts. Do we really need continual proof? - "'Anonymity is bad,' says a source who wishes to remain anonymous." - Nuff' said. * Home: Chris Adams <adamsc(a)io-online.com> | http://www.io-online.com/adamsc/adamsc.htp * Autoresponder: send email w/subject of "send resume" or "send PGPKEY" * Work: cadams(a)acucobol.com | V.M. (619)515-4894 | (619)689-6579 * Member in good standing of the GNU whirled hors d'oeuvre

1 0

encryption
by patrickbc＠juno.com 17 Dec '03

17 Dec '03

Will pay $5.00 for a good encryption program. Write to patrickbc(a)juno.com

1 0

Re: Real-time key server
by stewarts＠ix.netcom.com 17 Dec '03

17 Dec '03

At 04:30 PM 8/27/96 DST, "Osborne, Rick" <OSBORRI(a)msmail.northgrum.com> wrote: >In my research into keyservers, I find that none of them are realtime. > Sure, there are CGI interfaces to them, but that's not what I mean. I was >hoping for something along the line of a Finger or SMTP protocol, such that >a client connects to a host (say, keyserv.northgrum.com) on a certain port >(say, 5397) and goes through a realtime version of what is accomplished via >email. [...] >Why? Because: >1. I do not want to reinvent the wheel. >2. I would like to conform to existing standards. There are at least three shapes of wheel readily available. Some of the keyservers have had finger interfaces; there was one on wasabi.io.com for a while, though it may be inactive. John Perry may know where to find source code for it? Assuming you want PGP keys delivered in ASCII format, finger protocol should work just fine - you could easily enough hack your own fingerd server to live on the fingerd port, which gets PGP key files from a directory or database instead of from users' home directories, and run it on pgp.northgrum.com or whatever. You could even hack the existing finger code from {Free,Net}BSD, making sure to clean up any remaining sprintf()s and {*}get()s. Alternatively, a CGI query _is_ an easy way to do it, and there's existing code on the MIT keyserver that's blazingly fast. John Gilmore's SWAN project is using a DNS-based PGP key server; check out http://www.cygnus.com/~gnu/swan.html for more details. >Okay, I was told to not post to the list until I'd: >1. Lurked for a month, >2. Figured out who Detweiler was, >3. Found out about BlackNet and DC Nets, >4. Learned of at least three of David Chaum's innovations. >And at that point "[I] may be ready to post [my] first comments." > >Well, dammit, I can't wait that long. I need help now. I've only been on >for 2 weeks, I have no clue who Detweiler is (other than the >welcome message I haven't heard two words about him/her/it), and I know >enough to sound stupid about the other stuff. But if you still think I'm >worthy of listeneing to, then read on. Three out of four ain't bad, and Detweiler's been using his alias on the list for a couple of years and acting quite civilized :-) Some good reading sources are Bruce Schneier's book "Applied Cryptography" and Tim May's "Cyphernomicon" piece which is on the web somewhere. Also, asking for pointers to existing work does categorize you with the clueful minority..... # Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts(a)ix.netcom.com # <A HREF="http://idiom.com/~wcs"> Reassign Authority!

1 0

IDEA and timing attacks
by Bill Stewart 17 Dec '03

17 Dec '03

John Kelsey <jmkelsey(a)delphi.com> wrote in sci.crypt > > -----BEGIN PGP SIGNED MESSAGE----- > > [ To: sci.crypt ## Date: 08/24/96 03:11 am ## > Subject: IDEA and Timing Attacks ] > > I'm still kind-of recovering from this year's Crypto conference, but > I told several people I would post this. At the rump session this > year, I presented an arguably practical timing attack on many > implementations of IDEA. There are actually two attacks available, > but one requires extremely fine timing results. After I gave the > presentation, Willi Meier told me he had independently found the > same results, and had implemented the full attack (which I hadn't > yet done). > > There are two different attacks. The most practical is an > adaptive chosen-plaintext attack, which requires about 5*n*2^{16} > chosen plaintexts (read ``five n times two to the sixteenth''), > where the parameter n depends on the precision of timings available > and the timing variability of the implementation. The second attack > is ciphertext-only, but requires timing measurements precise enough > to detect the difference between a single multiply of a zero vs. > nonzero value. It requires about 5*n*2^{16} values, as well. > > The basic idea behind the attack is as follows: in many > implementations, a zero input into the multiply operation is handled > by an if statement, and so does not cause a multiply instruction to > actually be executed. The result on a 486 is that it is > significantly faster to multiply by a zero rather than a nonzero > value. This timing difference gives us a really nice way to learn > information about the internal values of the cipher. > > This presentation is necessarily not very good, since I can't embed > a diagram here. If you have a copy of _Applied Cryptography_, then > turn to the section on IDEA (page 321 in the hardback version of the > second edition). The diagram shows one round of IDEA, and then > (after the ellipses) the output transformation. > > The chosen plaintext attack works as follows: > > 1. Build a run of n*2^{16} chosen plaintexts, by choosing a > single value for X_1, and choosing n of each possible value for X_3, > with X_2 and X_4 taking on values at random. Time the encryption of > each batch of n plaintexts with the same X_3 value. > > 2. Choose a new value for X_1, and then build another run of > chosen plaintexts exactly as above. > > 3. For each of these two runs, if the value of Z_5 is not zero, > there should be a different value for X_3 that gives the lowest > encryption time. (These are the values that force the input to the > multiply with Z_5 to be zero.) Call these X_3 and X_3'. This gives > us two equations in two unknowns, and we can solve for it with a > 32-bit brute-force search. (There may be faster ways, as well.) > > (X_1 (*) Z_1) = (X_3 + Z_3) > (X_1'(*) Z_1) = (X_3'+ Z_3) > > We now have recovered Z_1 and Z_3. > > 4. Let's call the input to the multiply with Z_5 A. We can use > knowledge of Z_1 and Z_3 to force A to keep the same value. We then > choose three new runs of chosen plaintexts, each containing 2^{16} > batches of n plaintexts apiece. Each of these ensures that A and > X_2 are kept constant, so that we wind up three difference values > for A, X_2 and X_4 which correspond to zero inputs into the multiply > with Z_6. This means that we wind up with three equations in three > unknowns. > > (A (*) Z_5) + ((Z_2 + X_2 ) XOR (Z_4 (*) X_4 )) = 0 > (A' (*) Z_5) + ((Z_2 + X_2' ) XOR (Z_4 (*) X_4' )) = 0 > (A''(*) Z_5) + ((Z_2 + X_2'') XOR (Z_4 (*) X_4'')) = 0. > > This can be solved with a 48-bit brute force search (there are > probably faster ways). We now have 80 bits of IDEA's key, and can > brute-force search the remaining 48 bits. > > Note that this is actually an adaptive chosen-plaintext attack as > described. I'm pretty sure this can be turned into a proper > chosen-plaintext attack with some work, and I'll probably be hacking > on this in the next few weeks, as time allows. > > The ciphertext only attack is simpler in some ways. The first 32 > bits are extremely easy to recover--find the average time to encrypt > blocks with each value in their first and last 16 bits, and then > solve for the subkey values that would be necessary for those > multiplies to have zeros as their inputs. Next, we look for a > correlation between low encryption times and the values for Z_3 in > the output transformation that would result in zero inputs into the > previous round's MA box multiply. Finally, we attack the second > multiply in that MA box, using all four output values. The > approximate computational difficulty is 2^{48}, as before. > > There are other timing attacks on IDEA. We gave one in our paper at > Crypto this year (the one on related-key cryptanalysis of several > ciphers, by Bruce Schneier, David Wagner, and me), and the > related-key timing attack is where I got the idea to try a timing > attack on the whole cipher. > > All timing attacks are implementation-dependent to some extent. On > a Pentium, I suspect the timing attack will be considerably harder. > (One person I discussed the attack with said he thought it would > take longer to do the conditional branch for the if statement than > to do the multiply, so we might have zero multiplies taking more > rather than less time.) > > Most applications aren't really susceptible to timing attacks, > because of the way they're used. In addition, chosen-plaintext > attacks on block ciphers are pretty nicely thwarted by using CBC or > CFB modes. It is probably also possible to implement IDEA so that > it executes in constant time. I should point out that it is *NOT* > enough either to add random delays (which fall out if you add more > samples), nor to just get rid of the big timing difference with zero > inputs (though that will make timing attacks somewhat more > difficult). As long as internal (secret) information is being > leaked by timing, the cipher is probably vulnerable to some kind of > timing attack. > > --John Kelsey, jmkelsey(a)delphi.com / kelsey(a)counterpane.com > PGP 2.6 fingerprint = 4FE2 F421 100F BB0A 03D1 FE06 A435 7E36 > > -----BEGIN PGP SIGNATURE----- > Version: 2.6.2 > > iQCVAwUBMh7GKEHx57Ag8goBAQEqGQQApXRQUMWz3gpJIwGrLbVhcgcpSMXyrq0g > iTi2qjH7dJjmWugpLnbm18XHzOPZMKizdZ/gin1O3Rk89dXfqK4sIICwY3QmkwFR > ZQ2My4mTUn27ibjAjZTDuvxLXnqqoOFRrMUTQGIlMTCZdBooSWrif+pTLQbIsoPr > saHlDl2bWts= > =tWIq > -----END PGP SIGNATURE-----

1 0

DON'T Nuke Singapore Back into the Stone Age
by Arun Mehta 17 Dec '03

17 Dec '03

At 17:55 29/08/96 -0700, Timothy C. May wrote: >Personally, if this crackdown in Singapore happens, I intend to post >various anti-Singapore and anti-Lee Kwan Yew & Sons screeds to various >newsgroups that Singaporans might like to read. Then, if the Yew Dynasty >decides to pull the plug, it'll be to more and more groups. There are two sides to this: after all, it is the Singaporeans who finally have to sort out this problem with their government, and denying them the Usenet platform for discussion would only hinder that process. Then again, inappropriate postings are the bane of the Internet: the consensus on which the Net functions relies heavily on people not posting inappropriately. Of course, posting anti LKY stuff on a Singapore newsgroup might be perfectly appropriate -- it is the "more and more groups" part I am worried about. I quite frankly disapprove of the mail-bomb suggestions made on the list. Accessing the Internet is hard enough without these additional roadblocks. Mail-bombing one person on a server punishes everybody else on that server too. We need to work with the people in Singapore on this, not make enemies of them. I'm glad that the situation in Singapore is attracting much attention on this list, and that people want to do something about it. China is seriously interested in the experiment, and India will be too: the law here holds the ISPs responsible for ensuring that nothing objectionable and obscene is carried by them, and what simpler way to comply than to simply use the Singapore proxy. Right now, the law isn't being enforced, but soon some headline-seeking politician will point out this out, and the problem will be with us. So, it is important to nip the Singapore experiment in the bud. However, I think that the constructive approach, one which furthers the Net, "routes around", would work better. For instance, I'd love to see some smart venture capitalist fund a project that makes use of surplus, off-peak bandwidth on a transponder on any of the myriad satellites floating over Asia to download Web pages on request. Ideally, I should be able to send via pgp and anonymous remailer a request for a page, which would soon come beamed down unencrypted via satellite. No more waiting hours for the latest version of Netscape to download, and then restarting from scratch every time the line drops. Also, goodbye censorship. Even if the government decided to cut off Internet access completely, I'd still be able to receive what others such as Tim think might be of interest to me. How would this generate revenue? Well, there could be advertising appended to select pages, for instance. In any case, with so much uncertainity about how commerce on the net will work, and in good Internet tradition a la Netscape, it would probably be smarter to start with a free service, and figure out later how to make money from it, once it becomes popular. In a few years, satellite-based Internet access will become widespread and affordable. However, the next few years are really crucial. Governments are still trying to figure out how to deal with the Net, frame legislation, etc. This would be a good time to present them with a fait accompli. Hong Kong will revert to China next year. What better gift to the nervous freedom fighters there, than to help them with their Internet access? Maybe Hong Kong will take over China, instead of the other way around... I remember in Sculley's book "Odyssey: from Pepsi to Apple" he mentions how Steve Jobs finally convinced him to join Apple by asking if he wanted to sell sugared water for the rest of his life, or would he rather change the world. The Internet presents opportunities like that to far more people, and this, IMHO, is one of them: any would-be Sculleys out there? Arun Mehta Phone +91-11-6841172, 6849103 amehta(a)cpsr.org http://www.cerfnet.com/~amehta/ finger amehta(a)cerfnet.com for public key

2 1

Building the Singapore Free Press
by stewarts＠ix.netcom.com 17 Dec '03

17 Dec '03

Suppose you wanted to build a free press for a country like Singapore that has a government that doesn't want one - on the net, from the inside and outside. What tools would you need? Assume a Firewall Curtain proxy that can block sites and keywords but can't really block encryption. Also assume that the ISPs inside the Firewall Curtain can't do much to help you, given government licensing and other threats. How can you help people communicate with each other without interference? The Web isn't a bad tool for it, but it's easy to block specific web sites and specific host machines, so you'd need some combination of replication and DNS-manipulation to let sites change names conveniently and frequently. Has anybody developed a good DNS mechanism for reassigning namespace conveniently (e.g. a meet-me system allowing any machine to connect up to a given name, so anybody who wants to can be foobar23.remailer.net)? There are web conferencing tools that would be a decent user interface. You'd need some mechanism for anonymous submissions; remailers and web-based forms both work. Journalists have a long history under pseudonyms in British colonies and other non-free territory :-) You'd need a mechanism for finding the news from inside SG; search engines like AltaVista can pretty much handle that except that you need a method for sending encrypted requests, so the Firewall Curtain can't block them and the government can't tell what you're searching for. Perhaps an SSL-protected form with a CGI to submit to AltaVista? Does anybody know the protocols of the Firewall Curtain well enough to slide things into the cache? (This is an httpd hacking question....) What other tools would be useful? # Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts(a)ix.netcom.com # <A HREF="http://idiom.com/~wcs"> Reassign Authority!

1 0