From tim at dierks.org Sat Mar 1 21:42:17 2003 From: tim at dierks.org (Tim Dierks) Date: Sat, 01 Mar 2003 21:42:17 -0500 Subject: Wiretap Act Does Not Cover Message 'in Storage' For Short Period (was Re: BNA's Internet Law News (ILN) - 2/27/03) In-Reply-To: Message-ID: <5.2.1.0.2.20030301213625.0aba0ec0@dierks.org> At 01:39 PM 2/27/2003 -0500, R. A. Hettinga wrote: >At 9:01 AM -0500 on 2/27/03, BNA Highlights wrote: > > WIRETAP ACT DOES NOT COVER MESSAGE 'IN STORAGE' FOR SHORT > > PERIOD > > BNA's Electronic Commerce & Law Report reports that a > > federal court in Massachusetts has ruled that the federal > > Wiretap Act does not prohibit the improper acquisition of > > electronic communications that were "in storage" no matter > > how ephemeral that storage may be. The court relied on Konop > > v. Hawaiian Airlines Inc., which held that no Wiretap Act > > violation occurs when an electronic communication is > > accessed while in storage, "even if the interception takes > > place during a nanosecond 'juncture' of storage along the > > path of transmission." Case name is U.S. v. Councilman. > > Article at > > > > For a free trial to source of this story, visit > > http://web.bna.com/products/ip/eplr.htm This would seem to imply to me that the wiretap act does not apply to any normal telephone conversation which is carried at any point in its transit by an electronic switch, including all cell phone calls and nearly all wireline calls, since any such switch places the data of the ongoing call in "storage" for a tiny fraction of a second. - Tim --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From mindfuq at comcast.net Sat Mar 1 21:24:29 2003 From: mindfuq at comcast.net (MindFuq) Date: Sun, 2 Mar 2003 02:24:29 +0000 Subject: Applied Cryptography: question on skid3 Message-ID: <20030302022429.GI3091@comcast.net> I have a question on what seems to be a defect in the Applied Cryptography book, and I couldn't get an answer out of Schneier or the cypherpunks mailing list. Could any of you please clarify my issue? My question is regarding Schneier's write up of SKID3 on page 56. He states that the protocol is not secure against man-in-the-middle attacks because no secrets are involved. I'm finding this hard to accept, because SKID3 uses a MAC, which requires a shared secret key between the two parties. I played out the scenario, and cannot see how a man in the middle could attack w/out knowing the secret key used in the MAC. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From perry at piermont.com Sun Mar 2 13:30:51 2003 From: perry at piermont.com (Perry E. Metzger) Date: 02 Mar 2003 13:30:51 -0500 Subject: NSA being used to influence UN votes on Iraq Message-ID: <87u1elk4dg.fsf@snark.piermont.com> http://www.observer.co.uk/international/story/0,6903,905899,00.html Quote from the article: The United States is conducting a secret 'dirty tricks' campaign against UN Security Council delegations in New York as part of its battle to win votes in favour of war against Iraq. Details of the aggressive surveillance operation, which involves interception of the home and office telephones and the emails of UN delegates in New York, are revealed in a document leaked to The Observer. The disclosures were made in a memorandum written by a top official at the National Security Agency - the US body which intercepts communications around the world - and circulated to both senior agents in his organisation and to a friendly foreign intelligence agency asking for its input. -- Perry E. Metzger perry at piermont.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ji at research.att.com Sun Mar 2 13:49:53 2003 From: ji at research.att.com (John Ioannidis) Date: Sun, 2 Mar 2003 13:49:53 -0500 Subject: NSA being used to influence UN votes on Iraq In-Reply-To: <87u1elk4dg.fsf@snark.piermont.com> References: <87u1elk4dg.fsf@snark.piermont.com> Message-ID: <20030302184952.GB10623@bual.research.att.com> Why is this even newsworthy? It's the NSA's responsibility to provide sigint and comint. Furthermore, if the delegates are not US citizens, and at least one end of the communication is outside the US, they are not even breaking any laws in doing so. If the delegations can't be bothered to protect their own communications, it's their tough luck if they get intercepted. /ji PS: I assume the "friendly foreign intelligence agency" is GCHQ? --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From rivest at mit.edu Sun Mar 2 14:27:00 2003 From: rivest at mit.edu (Ronald L. Rivest) Date: Sun, 02 Mar 2003 14:27:00 -0500 Subject: Wiretap Act Does Not Cover Message 'in Storage' For Short Period (was Re: BNA's Internet Law News (ILN) - 2/27/03) In-Reply-To: <5.2.1.0.2.20030301213625.0aba0ec0@dierks.org> References: Message-ID: <5.2.0.9.2.20030302140111.020d73c0@theory.lcs.mit.edu> Yes, I was amazed at this ruling as well. This ruling seems to fly in the face of the likely intent of Congress when it passed Wiretap Act. If things continue in this direction, we will soon have rulings and regulations that say: -- Carriers must put all calls in storage for a minimum period of time, sufficient to allow wiretapping. (Indeed, regulation may not be necessary, as digitization and buffering of communications is common practice; the transient use of storage to effect communications efficiency and reliability should not provide a wiretap loophole.) -- Wiretapping is OK for any phone calls that are routed through a satellite. -- It is OK for the government to house soldiers in your house, as long as there is even the tiniest opening somewhere in your house (e.g. a window open, or a chimney flue) so that "inside" and "outside" connect. -- Etc. I can also see a market developing for "storage-free" communications carriers. What happens when you inquire of your carrier as to whether it can provide such a guarantee or option? Cheers, Ron At 09:42 PM 3/1/2003, Tim Dierks wrote: >At 01:39 PM 2/27/2003 -0500, R. A. Hettinga wrote: >>At 9:01 AM -0500 on 2/27/03, BNA Highlights wrote: >> > WIRETAP ACT DOES NOT COVER MESSAGE 'IN STORAGE' FOR SHORT >> > PERIOD >> > BNA's Electronic Commerce & Law Report reports that a >> > federal court in Massachusetts has ruled that the federal >> > Wiretap Act does not prohibit the improper acquisition of >> > electronic communications that were "in storage" no matter >> > how ephemeral that storage may be. The court relied on Konop >> > v. Hawaiian Airlines Inc., which held that no Wiretap Act >> > violation occurs when an electronic communication is >> > accessed while in storage, "even if the interception takes >> > place during a nanosecond 'juncture' of storage along the >> > path of transmission." Case name is U.S. v. Councilman. >> > Article at >> > >> > For a free trial to source of this story, visit >> > http://web.bna.com/products/ip/eplr.htm > >This would seem to imply to me that the wiretap act does not apply to any >normal telephone conversation which is carried at any point in its transit >by an electronic switch, including all cell phone calls and nearly all >wireline calls, since any such switch places the data of the ongoing call >in "storage" for a tiny fraction of a second. > > - Tim > > > >--------------------------------------------------------------------- >The Cryptography Mailing List >Unsubscribe by sending "unsubscribe cryptography" to >majordomo at wasabisystems.com Ronald L. Rivest Room 324, 200 Technology Square, Cambridge MA 02139 Tel 617-253-5880, Fax 617-258-9738, Email --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From cryptography at ka9q.net Sun Mar 2 14:32:36 2003 From: cryptography at ka9q.net (cryptography at ka9q.net) Date: Sun, 02 Mar 2003 11:32:36 -0800 Subject: Columbia crypto box Message-ID: Interestingly enough, the public references long ago published the shuttle comm frequencies. Summarizing from: http://spaceflight.nasa.gov/shuttle/reference/shutref/orbiter/comm/orbcomm/ S-band PM forward link frequencies: 2,106.4 MHz (primary) or 2,041.9 MHz (secondary) S-band PM reverse link frequencies: 2,287.5 MHz (primary) or 2,217.5 MHz (secondary) S-band PM forward link frequencies, military missions: 1,831.8 MHz (primary) or 1,775.5 MHz (secondary) S-band PM reverse link frequencies: 2,287.5 MHz (primary) or 2,217.5 MHz (secondary) - same as civilian S-band FM downlink: 2,250.0 MHz Ku-band forward link: 13.755 GHz Ku-band reverse link: 15.003 GHz UHF AM frequencies: 296.8 MHz, 259.7 MHz, 243.0 MHz (emergencies only) and 279.0 MHz (EVA only) Now it's certainly possible that this is misinformation, except for the UHF frequencies 296.8 and 259.7, which many hams (including myself) have personally verified. --Phil --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From cryptography at ka9q.net Sun Mar 2 14:50:37 2003 From: cryptography at ka9q.net (cryptography at ka9q.net) Date: Sun, 02 Mar 2003 11:50:37 -0800 Subject: Columbia crypto box Message-ID: > As an aside, I've been seeing a *lot* of criticism in the popular > press about the alleged antiquity of the STS computers; all asking why > NASA isn't using the latest technology in its shuttles. Folks, I ask you > to take the latest bleeding-edge technology and subject it to significant > G-forces followed by introduction into a microgravity environ, have it > bounced around during re-entry and then _guarantee_ that it won't > experience a critical failure at the worst possible moment. That > floating-point error in your Pentium may seem catastrophic when you're > working in AutoCAD, but just have a look at the French Arianne rocket if > you want to see what such an error does to a spacecraft in flight. It's interesting that you would cite that particular failure, because it was ultimately caused by the use of obsolete computer hardware. The software writers were well aware that certain floating point variables might cause an exception when converted to fixed point. They even added range checks to many of these conversions. But they couldn't range check *every* variable before conversion because they didn't have enough CPU cycles; a design rule required that peak CPU utilization remain below 70%. So they had to pick and choose which conversions would be range checked. They deliberately left "horizontal velocity" unchecked because it wasn't possible (on Ariane 4) for that variable to increase quickly enough to cause a problem if the launcher flew normally. And if it wasn't flying normally, who cared? But Ariane 5 was designed to gain horizontal velocity much faster than Ariane 4... Had they used a newer, faster CPU they would have been able to range check *every* variable before conversion, or use a more modern architecture that wouldn't cause a fatal exception on an out-of-range conversion. But hardware conservatism prevailed, with disastrous results. Phil --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From rah at shipwright.com Sun Mar 2 15:01:00 2003 From: rah at shipwright.com (R. A. Hettinga) Date: Sun, 2 Mar 2003 15:01:00 -0500 Subject: [Lucrative-L] extensive cryptanalysis of Lucre Message-ID: --- begin forwarded text Status: RO From: "Patrick" To: Subject: [Lucrative-L] extensive cryptanalysis of Lucre Date: Sun, 2 Mar 2003 11:28:13 -0600 Sender: owner-lucrative-l at lucrative.thirdhost.com Reply-To: lucrative-l at lucrative.thirdhost.com I'm looking for cryptanalysis resources for Lucre. If you know of any publications or unpublished papers, please share. Patrick The Lucrative Project: http://lucrative.thirdhost.com ...................................................... To subscribe or unsubscribe from this discussion list, write to lucrative-l-request at lucrative.thirdhost.com with just the word "unsubscribe" in the message body (or, of course, "subscribe") --- end forwarded text -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From bill.stewart at pobox.com Sun Mar 2 15:29:22 2003 From: bill.stewart at pobox.com (Bill Stewart) Date: Sun, 02 Mar 2003 12:29:22 -0800 Subject: Roger Needham Died - from The Register Message-ID: <5.1.1.6.2.20030302122746.02cf5dc0@idiom.com> -------------------- Obit: Roger Needham By Guy Kewney, Newswireless.net Posted: 02/03/2003 at 12:13 GMT Sadly, we record the death of Roger Needham, computer pioneer... There isn't much more to say, except that the man who was the reason Microsoft set up its research centre in Cambridge, England, has had to lay down his life's work. Cancer ended a legend. He once told me that it was his idea that Microsoft stopped spending money on patenting its research ideas, and instead, to make the results available to other researchers. I wish I'd known him long enough to have some other stories to pass on myself; he left a long legacy of people who attributed their inspiration to having worked with him. Here's what his CV at Microsoft Research says: Roger M Needham, born 1935, was in computing at Cambridge since 1956. His 1961 PhD thesis was on the application of digital computers to problems of classification and grouping. In 1962 he joined the Computer Laboratory, then called the Mathematical Laboratory, and has been on the faculty since 1963. He took a leading role in Cambridge projects in operating systems, time sharing systems, memory protection, local area networks, and distributed systems over the next twenty years. Roger worked at intervals on a variety of topics in security, (his main research interest while with Microsoft) being particularly known for work with Schroeder on authentication protocols (1978) and with Burrows and Abadi on formalism for reasoning about them (1989). Roger graduated from the University of Cambridge in Mathematics and Philosophy in 1956, and then took the Diploma in Numerical Analysis and Automatic Computing in 1957. He had been in computing at Cambridge ever since. He succeeded Maurice Wilkes as Head of the Computer Laboratory from 1980 to 1995, was promoted Professor in 1981, elected to the Royal Society in 1985 and the Royal Academy of Engineering in 1993. He was appointed Pro-Vice-Chancellor in 1996. I only met him a couple of times, both times when Microsoft was doing corporate hospitality to publicise the work it was doing in the Cambridge research facility. He was as knowledgeable as any rumour could have suggested; and as tolerant of an ignorant journalist as any academic could ever be. And I shall never get to know him, now. Guy Kewney is the editor/publisher of Newswireless.Net ----------------------------------------------- --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From mindfuq at comcast.net Sun Mar 2 08:47:34 2003 From: mindfuq at comcast.net (MindFuq) Date: Sun, 2 Mar 2003 13:47:34 +0000 Subject: Wiretap Act Does Not Cover Message 'in Storage' For Short Period In-Reply-To: <5.2.1.0.2.20030301213625.0aba0ec0@dierks.org> References: <5.2.1.0.2.20030301213625.0aba0ec0@dierks.org> Message-ID: <20030302134734.GA1869@comcast.net> * Tim Dierks [2003-03-02 12:27]: > > This would seem to imply to me that the wiretap act does not apply to any > normal telephone conversation which is carried at any point in its transit > by an electronic switch, including all cell phone calls and nearly all > wireline calls, since any such switch places the data of the ongoing call > in "storage" for a tiny fraction of a second. I believe the reason behind the 'in storage' rule is that someone could protect non-transmitted information under the Wiretap Act by transmitting it needlessly. Then they could say that because the information was transmitted, law enforcement now needs the more difficult to obtain wiretap permit just to search the premesis. Example: I heard of a case a while back where an office had fax printouts lying around. Because these fax printouts were not in transmission at the point of interception, there was no need for a wiretap permit. And I think that's reasonable. I'm not sure that your example is correct, because in the cases you mention the wiretap is not actually accessing stored information; it's accessing a transmission (which may be stored elsewhere). However, if the eavesdropper were able to access the data at the point of storage that you describe, then they probably could weasel out of the Wiretap Act. I would not think it's easy to read registers off a microprocessor externally. What annoys me is how the FBI got away with abusing this rule in the Scarfo case. They planted a keyboard logger on Scarfo's keyboard. Then they planted a bug on his serial port. The two bugs compared the keystroke to the data leaving the serial port, and if the keystroke didn't leave the serial port instantaneously, they captured it, and they were able to successfully argue that they didn't intercept a transmission. Obviously email is composed before being sent, so the slimey bastards use this to conduct a disclosure attack on information that would otherwise be protected by the wiretap laws. One might argue that they intercepted a transmission between the keyboard and the computer. Here's how they weasel out of that: Title 3 requires a wiretap warrent to intercept *electronic* transmissions. I believe the FBI uses a keyboard logger that detects the *mechanical* pushing of keys, probably specifically to circumvent the wiretap law. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From mab at research.att.com Sun Mar 2 19:06:41 2003 From: mab at research.att.com (Matt Blaze) Date: Sun, 02 Mar 2003 19:06:41 -0500 Subject: Roger Needham Died - from The Register In-Reply-To: Message from Bill Stewart of "Sun, 02 Mar 2003 12:29:22 PST." <5.1.1.6.2.20030302122746.02cf5dc0@idiom.com> Message-ID: <200303030006.h2306fM30295@fbi.crypto.com> Sad, sad news. Roger's pioneering contributions to our art speak (volumes) for themselves, and our field is diminished by the loss of his future insights. But I will miss him most for his enormous generosity, his sharp wit, and his personal integrity. -matt > -------------------- > Obit: Roger Needham > By Guy Kewney, Newswireless.net > Posted: 02/03/2003 at 12:13 GMT > > Sadly, we record the death of Roger Needham, computer pioneer... > > There isn't much more to say, except that the man who was the reason > Microsoft set up its research centre in Cambridge, England, has had to lay > down his life's work. Cancer ended a legend. > > He once told me that it was his idea that Microsoft stopped spending money > on patenting its research ideas, and instead, to make the results available > to other researchers. I wish I'd known him long enough to have some other > stories to pass on myself; he left a long legacy of people who attributed > their inspiration to having worked with him. > > Here's what his CV at Microsoft Research says: > > Roger M Needham, born 1935, was in computing at Cambridge since 1956. His > 1961 PhD thesis was on the application of digital computers to problems of > classification and grouping. In 1962 he joined the Computer Laboratory, > then called the Mathematical Laboratory, and has been on the faculty since > 1963. He took a leading role in Cambridge projects in operating systems, > time sharing systems, memory protection, local area networks, and > distributed systems over the next twenty years. > > Roger worked at intervals on a variety of topics in security, (his main > research interest while with Microsoft) being particularly known for work > with Schroeder on authentication protocols (1978) and with Burrows and > Abadi on formalism for reasoning about them (1989). > > Roger graduated from the University of Cambridge in Mathematics and > Philosophy in 1956, and then took the Diploma in Numerical Analysis and > Automatic Computing in 1957. He had been in computing at Cambridge ever > since. He succeeded Maurice Wilkes as Head of the Computer Laboratory from > 1980 to 1995, was promoted Professor in 1981, elected to the Royal Society > in 1985 and the Royal Academy of Engineering in 1993. He was appointed > Pro-Vice-Chancellor in 1996. > > I only met him a couple of times, both times when Microsoft was doing > corporate hospitality to publicise the work it was doing in the Cambridge > research facility. He was as knowledgeable as any rumour could have > suggested; and as tolerant of an ignorant journalist as any academic could > ever be. And I shall never get to know him, now. > > Guy Kewney is the editor/publisher of Newswireless.Net > > ----------------------------------------------- > > > --------------------------------------------------------------------- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ggr at qualcomm.com Sun Mar 2 19:09:17 2003 From: ggr at qualcomm.com (Greg Rose) Date: Mon, 03 Mar 2003 11:09:17 +1100 Subject: Some good words needed... Message-ID: <5.1.0.14.2.20030303105541.02878cc0@203.30.171.11> After a long effort, I finally got agreement from my company to make our encryption algorithms freely available. (See http://www.qualcomm.com/press/pr/releases2003/press1161.html if you care.) Somewhat unexpectedly, we now have a number of queries saying basically "That's unpatriotic, giving it away to the terrorists!" Note that they were already *available* to them, it just wasn't free for all uses! So I guess it's unpatriotic to fail to make money from these terrible weapons. I won't even get into the issue of me being a furriner in the first place. Anyway. I'm perfectly capable of writing my own words on the subject, but I also know that they've been written many times before. What are people's "favourite", succinct expressions of why it's OK to give away encryption algorithms? To keep the list uncluttered, I suggest people send me suggestions, and I'll compile, collate, and report back to the list. thanks and regards, Greg. Greg Rose INTERNET: ggr at qualcomm.com Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199 Level 3, 230 Victoria Road, http://people.qualcomm.com/ggr/ Gladesville NSW 2111 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From tim at dierks.org Sun Mar 2 19:44:06 2003 From: tim at dierks.org (Tim Dierks) Date: Sun, 02 Mar 2003 19:44:06 -0500 Subject: Wiretap Act Does Not Cover Message 'in Storage' For Short Period In-Reply-To: <20030302134734.GA1869@comcast.net> References: <5.2.1.0.2.20030301213625.0aba0ec0@dierks.org> <5.2.1.0.2.20030301213625.0aba0ec0@dierks.org> Message-ID: <5.2.1.0.2.20030302190118.0b1acca0@dierks.org> At 01:47 PM 3/2/2003 +0000, MindFuq wrote: >* Tim Dierks [2003-03-02 12:27]: > > > > This would seem to imply to me that the wiretap act does not apply to any > > normal telephone conversation which is carried at any point in its transit > > by an electronic switch, including all cell phone calls and nearly all > > wireline calls, since any such switch places the data of the ongoing call > > in "storage" for a tiny fraction of a second. > >I believe the reason behind the 'in storage' rule is that someone >could protect non-transmitted information under the Wiretap Act by >transmitting it needlessly. Then they could say that because the >information was transmitted, law enforcement now needs the more >difficult to obtain wiretap permit just to search the premesis. You may be correct as to intent, but the originally forwarded article says: > The court relied on Konop > v. Hawaiian Airlines Inc., which held that no Wiretap Act > violation occurs when an electronic communication is > accessed while in storage, "even if the interception takes > place during a nanosecond 'juncture' of storage along the > path of transmission." Case name is U.S. v. Councilman. which includes the phrase "along the path of transmission." In order to avoid overreaction to a nth-hand story, I've attempted to locate some primary sources. Konop v. Hawaiian Airlines: http://laws.lp.findlaw.com/getcase/9th/case/9955106p&exact=1 My understanding is that Konop v. Hawaiian Airlines was a lawsuit by Robert Konop against his former employer, Hawaiian Airlines. Mr. Konop had operated a website where he published a variety of allegations about Hawaiian, and he restricted access to that site by username and password. A manager at Hawaiian gained the permission of two other employees of the airline to use their names in accessing the website; Konop found out about the access and sued Hawaiian. Among other grounds, he claimed that management viewing his site constituted an "interception" of electronic communications in violation of the wiretap act. I won't go into any argument about the plausibility of this claim; I'll just summarize the legal proceedings thereafter. The federal district court which heard the case granted summary judgement against Konop on the wiretap claims; the 9th circuit court of appeals then reversed the district court's decision on the wiretap claims. Thereafter, the 9th circuit withdrew that opinion, then affirmed the district court's original judgement against Konop. Thus, the end result is that the wiretap claim does not hold. Why? Amid other reasoning, the court refers to an old friend, Steve Jackson Games, Inc. v. United States Secret Service. In summary, the fifth circuit court determined that e-mail stored on a machine was not protected by the wiretap act, because an "electronic communication" cannot be "intercepted" in the same way that a "wire communication" can be. This reasoning has been upheld with respect to voicemail messages. There is a footnote that specifically addresses the interesting question: that all electronic messages involve storage at some point, so the wiretap act is meaningless with respect to electronic communication. The crucial conclusion is: >While this argument is not without appeal, the language and structure of >the ECPA demonstrate that Congress considered and rejected this argument. >Congress defined "electronic storage" as "any temporary, intermediate >storage of a wire or electronic communication incidental to the electronic >transmission thereof," 18 U.S.C. ? 2510(17)(A), indicating that Congress >understood that electronic storage was an inherent part of electronic >communication. Nevertheless, as discussed above, Congress chose to afford >stored electronic communications less protection than other forms of >communication. United States of America vs. Bradford S. Councilman: http://pacer.mad.uscourts.gov/dc/opinions/ponsor/pdf/councilman2.pdf The Government charged Mr. Councilman with conspiracy to violate the wiretap act. Apparently, they claim that he used the contents of electronic mail passing through his service for commercial gain. The judge seems quite aware of the implications of the decision and the effect of the Konop precedent, but dismisses the charge. Based upon this rationale, it seems that one cannot be convicted of violating the wiretap act unless one actually taps into electric signals. For example, it would seem to continue to be illegal to intercept 802.11 RF signals, but possible not be illegal to plug a cable into an ethernet hub and copy all traffic on the subnet (since most hubs "store" packets internally for transmission), and perfectly OK to subvert a router to forward copies of all packets to you. I'd be interested in any opinions on how this affects the government's need to get specific wiretap warrants; I don't know if the law which makes illicit civilian wiretapping illegal is the same code which governs the government's ability (or lack thereof) to intercept communications. - Tim --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From rah at shipwright.com Sun Mar 2 20:59:11 2003 From: rah at shipwright.com (R. A. Hettinga) Date: Sun, 2 Mar 2003 20:59:11 -0500 Subject: Wiretap Act Does Not Cover Message 'in Storage' For Short Period (was Re: BNA's Internet Law News (ILN) - 2/27/03) Message-ID: --- begin forwarded text Status: RO From: Somebody To: "R. A. Hettinga" Subject: Re: Wiretap Act Does Not Cover Message 'in Storage' For Short Period (was Re: BNA's Internet Law News (ILN) - 2/27/03) Date: Sun, 2 Mar 2003 14:09:05 -0500 Bob, Technically, since their signal speed is slower than light, even transmission lines act as storage devices. Wire tapping is now legal. ----- Original Message ----- From: "R. A. Hettinga" To: Clippable Sent: Sunday, March 02, 2003 3:04 PM Subject: Re: Wiretap Act Does Not Cover Message 'in Storage' For Short Period (was Re: BNA's Internet Law News (ILN) - 2/27/03) > > --- begin forwarded text > > > Status: RO > Date: Sun, 02 Mar 2003 14:27:00 -0500 > To: Tim Dierks , "R. A. Hettinga" , > cryptography at wasabisystems.com > From: "Ronald L. Rivest" > Subject: Re: Wiretap Act Does Not Cover Message 'in Storage' For Short > Period (was Re: BNA's Internet Law News (ILN) - 2/27/03) > > > Yes, I was amazed at this ruling as well. > > This ruling seems to fly in the face of the likely intent of > Congress when it passed Wiretap Act. > > If things continue in this direction, we will soon have > rulings and regulations that say: > > -- Carriers must put all calls in storage for a minimum > period of time, sufficient to allow wiretapping. > (Indeed, regulation may not be necessary, as digitization and > buffering of communications is common practice; the > transient use of storage to effect communications > efficiency and reliability should not provide a wiretap > loophole.) > > -- Wiretapping is OK for any phone calls that are routed > through a satellite. > > -- It is OK for the government to house soldiers in your > house, as long as there is even the tiniest opening somewhere in > your house (e.g. a window open, or a chimney flue) > so that "inside" and "outside" connect. > > -- Etc. > > I can also see a market developing for "storage-free" communications > carriers. What happens when you inquire of your carrier as to > whether it can provide such a guarantee or option? > > Cheers, > Ron > > At 09:42 PM 3/1/2003, Tim Dierks wrote: > >At 01:39 PM 2/27/2003 -0500, R. A. Hettinga wrote: > >>At 9:01 AM -0500 on 2/27/03, BNA Highlights wrote: > >> > WIRETAP ACT DOES NOT COVER MESSAGE 'IN STORAGE' FOR SHORT > >> > PERIOD > >> > BNA's Electronic Commerce & Law Report reports that a > >> > federal court in Massachusetts has ruled that the federal > >> > Wiretap Act does not prohibit the improper acquisition of > >> > electronic communications that were "in storage" no matter > >> > how ephemeral that storage may be. The court relied on Konop > >> > v. Hawaiian Airlines Inc., which held that no Wiretap Act > >> > violation occurs when an electronic communication is > >> > accessed while in storage, "even if the interception takes > >> > place during a nanosecond 'juncture' of storage along the > >> > path of transmission." Case name is U.S. v. Councilman. > >> > Article at > >> > > >> > For a free trial to source of this story, visit > >> > http://web.bna.com/products/ip/eplr.htm > > > >This would seem to imply to me that the wiretap act does not apply to any > >normal telephone conversation which is carried at any point in its transit > >by an electronic switch, including all cell phone calls and nearly all > >wireline calls, since any such switch places the data of the ongoing call > >in "storage" for a tiny fraction of a second. > > > > - Tim > > > > > > > >--------------------------------------------------------------------- > >The Cryptography Mailing List > >Unsubscribe by sending "unsubscribe cryptography" to > >majordomo at wasabisystems.com > > Ronald L. Rivest > Room 324, 200 Technology Square, Cambridge MA 02139 > Tel 617-253-5880, Fax 617-258-9738, Email > > --- end forwarded text > > > -- > ----------------- > R. A. Hettinga > The Internet Bearer Underwriting Corporation > 44 Farquhar Street, Boston, MA 02131 USA > "... however it may deserve respect for its usefulness and antiquity, > [predicting the end of the world] has not been found agreeable to > experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' > --- end forwarded text -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From adam at cypherspace.org Sun Mar 2 21:04:43 2003 From: adam at cypherspace.org (Adam Back) Date: Mon, 3 Mar 2003 02:04:43 +0000 Subject: NSA being used to influence UN votes on Iraq In-Reply-To: <20030302184952.GB10623@bual.research.att.com>; from ji@research.att.com on Sun, Mar 02, 2003 at 01:49:53PM -0500 References: <87u1elk4dg.fsf@snark.piermont.com> <20030302184952.GB10623@bual.research.att.com> Message-ID: <20030303020443.A4186930@exeter.ac.uk> Why is US secret service eavesdropping and dirty tricks against UN votes on Iraq news worthy? Because it's an attempt to pervert the political process, and sabotage the political representation of other UN member countries. I'm sure it is a little more than delegations bothering to protect their comms; there is plenty of room in physical bugs, black bag jobs, political bribery, and even potentially individual blackmail whatever crypto the delegates may be using. Adam On Sun, Mar 02, 2003 at 01:49:53PM -0500, John Ioannidis wrote: > Why is this even newsworthy? It's the NSA's responsibility to provide > sigint and comint. Furthermore, if the delegates are not US citizens, > and at least one end of the communication is outside the US, they are > not even breaking any laws in doing so. > > If the delegations can't be bothered to protect their own > communications, it's their tough luck if they get intercepted. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From die at die.com Sun Mar 2 22:19:56 2003 From: die at die.com (Dave Emery) Date: Sun, 2 Mar 2003 22:19:56 -0500 Subject: Columbia crypto box In-Reply-To: References: Message-ID: <20030303031956.GE11496@pig.die.com> On Sun, Mar 02, 2003 at 11:32:36AM -0800, cryptography at ka9q.net wrote: > Interestingly enough, the public references long ago published the > shuttle comm frequencies. Summarizing from: > The frequencies have never been secret, but in recent years some or perhaps even almost all of the Ku band TDRSS relayed telemetry and TV and a good bit of the S band relayed traffic has been encrypted. This was, I have been given to understand, part of the upgrades to the comms and TV systems on the shuttle completed in the last few years which converted analog TV transmission to digital TV. This encryption was originally publicly justified in part on the grounds that medical information was passed between crew and physicians on the ground and that federal privacy laws required protection of this information. And as far as I know, NASA while publishing link frequencies (which I have no particular reason to believe are wrong), has never released full details of modulation, multiplexing, error correction coding, randomization, interleaving, frame sync formats, channel assignments and scale factors for the data even for those links and modes that aren't encrypted. And actual link frequencies are but a small part of the data base of information one would need to successfully intercept useful information from the shuttle links - even 1980s to early-90s era digital telemetry signals are pretty complex and non trivial to deal with even if you know the frequency. Finally, the TDRSS spacecraft are also used for relaying information from NRO spacecraft and other classified military missions, and there is a significant chance that at least some of the details of the access protocols and signal formats used with these spacecraft are classified in order to protect sensitive military links. -- Dave Emery N1PRE, die at die.com DIE Consulting, Weston, Mass. PGP fingerprint = 2047/4D7B08D1 DE 6E E1 CC 1F 1D 96 E2 5D 27 BD B0 24 88 C3 18 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From juicy at melontraffickers.com Sun Mar 2 22:55:53 2003 From: juicy at melontraffickers.com (A.Melon) Date: Sun, 2 Mar 2003 19:55:53 -0800 (PST) Subject: double shot of snake oil, good conclusion Message-ID: <0c248779bfc3c36c1d9db576541fbf48@melontraffickers.com> Ed writes claiming this speculation about Palladium's implicatoins is mis-informed: > while others speculated on "another potentially devastating effect", > that the DRM could, via a loophole in the DoJ consent decree, allow > Microsoft to withhold information about file formats and APIs from > other companies which are attempting to create compatible or > competitive products I think you misunderstand the technical basis for this claim. The point is Palladium would allow Microsoft to publish a file format and yet still control compatibility via software certification and certification on content of the software vendor who's software created it. Your other claims about the limited implications for whistle-blowing (or file trading of movies and mp3s) I agree with. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From frantz at pwpconsult.com Sun Mar 2 23:48:03 2003 From: frantz at pwpconsult.com (Bill Frantz) Date: Sun, 2 Mar 2003 20:48:03 -0800 Subject: Columbia crypto box In-Reply-To: Message-ID: At 11:32 AM -0800 3/2/03, cryptography at ka9q.net wrote: >UHF AM frequencies: 296.8 MHz, 259.7 MHz, 243.0 MHz (emergencies only) >and 279.0 MHz (EVA only) > >Now it's certainly possible that this is misinformation, except for >the UHF frequencies 296.8 and 259.7, which many hams (including >myself) have personally verified. IIRC, 243.0 is the military flight emergency frequency. (Corresponding to 121.5 for civilian use). I would expect the shuttle to have that frequency available. Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | Due process for all | Periwinkle -- Consulting (408)356-8506 | used to be the | 16345 Englewood Ave. frantz at pwpconsult.com | American way. | Los Gatos, CA 95032, USA --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From rah at shipwright.com Mon Mar 3 08:35:53 2003 From: rah at shipwright.com (R. A. Hettinga) Date: Mon, 3 Mar 2003 08:35:53 -0500 Subject: Delta Air Lines Boycott Underway (note revised URL: www.boycottdelta.ORG) Message-ID: --- begin forwarded text Status: RO To: rahettinga at earthlink.net From: Bill Scannell Date: Mon, 03 Mar 2003 03:32:58 -0600 Subject: Delta Air Lines Boycott Underway (note revised URL: www.boycottdelta.ORG) In response to Delta Air Line's utter lack of concern with the privacy of their customers demonstrated by their participation in a test of the CAPPS II system, a Delta disinvestment campaign has been launched at: http://www.boycottdelta.org . In the event that the name servers have not yet propagated, the site can be reached at: http://216.240.45.67 The idea of citizens having to undergo a background investigation that includes personal banking information and a credit check simply to travel in his or her own country is invasive and un-American. The CAPPS II system goes far beyond what any thinking citizen of this country should consider reasonable. If enough people refuse to fly Delta, then it is likely that other airlines will refuse to implement this sadly misguided and anti-democratic system. The boycott will remain in full effect until Delta Air Lines publicly withdraws from any involvement with the testing of CAPPS II. Press Contact: Bill Scannell (bill at scannell.org) --- end forwarded text -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From egerck at nma.com Mon Mar 3 16:06:33 2003 From: egerck at nma.com (Ed Gerck) Date: Mon, 03 Mar 2003 13:06:33 -0800 Subject: double shot of snake oil, good conclusion References: <0c248779bfc3c36c1d9db576541fbf48@melontraffickers.com> Message-ID: <3E63C3D9.4AE3E21D@nma.com> "A.Melon" wrote: > Ed writes claiming this speculation about Palladium's implicatoins is > mis-informed: > > > while others speculated on "another potentially devastating effect", > > that the DRM could, via a loophole in the DoJ consent decree, allow > > Microsoft to withhold information about file formats and APIs from > > other companies which are attempting to create compatible or > > competitive products > > I think you misunderstand the technical basis for this claim. The > point is Palladium would allow Microsoft to publish a file format and > yet still control compatibility via software certification and > certification on content of the software vendor who's software created > it. We are in agreement. When you read the whole paragraph that I wrote, I believe it is clear that my comment was not whether the loophole existed or not. My comment was that there was a much more limited implication for whistle-blowing because DRM can't really control what humans do and there is no commercial value in saying that a document that I see cannot be printed or forwarded -- because it can. > Your other claims about the limited implications for whistle-blowing > (or file trading of movies and mp3s) I agree with. And that's what my paragraph meant. Cheers, Ed Gerck --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From egerck at nma.com Mon Mar 3 16:28:54 2003 From: egerck at nma.com (Ed Gerck) Date: Mon, 03 Mar 2003 13:28:54 -0800 Subject: Comments/summary on unicity discussion Message-ID: <3E63C916.31E993CC@nma.com> List: The recent thread on "AES-128 keys unique for fixed plaintext/ciphertext pair" included a discussion on unicity, with some broken dialogues. I wrote -up a summary that I'm sending to this list as a possible seed for further comments. I apologize for any mistakes or imprecision, as I'm not trying to be as exact as possible -- just sufficiently exact for the purpose at hand. I also provide below the online references for Shannon's works [Sha48, Sha49] that are important to this discussion. The AES thread discussion is NOT included here. 1. WHAT IS UNICITY? There are three different contexts to answer to this question! 1.a. Unicity Definition: Shannon [Sha49, page 693] defined "unicity distance" (hereafter, "n") as the least amount of plaintext which can be uniquely deciphered from the corresponding ciphertext, allowing one to determine, without doubt, the key that was used for encryption. The "amount" of plaintext (i.e., "n") can be measured in any units the user may find convenient, such as bits, bytes, letters, symbols, etc. Actually, Shannon used "letters" in his paper. NOTE 1: This is a definition. There is no proof involved here. 1.b. Unicity Model: As first given by Shannon [Sha49] under some restrictive assumptions, specially the "random cipher" assumption, the mathematical expression for unicity can be cast in the following unfolded expression (his original expression was n = H(K)/D, where D is the redundancy): n = H(K)/[|M| - H(M)] where the quantities are: n = unicity; least message length that can be uniquely deciphered H(K) = entropy of keys used in encryption |M| = maximum possible entropy for the plaintext H(M) = entropy of actual message, the plaintext and the entropies are calculated accordingly to the desired units (bits, bytes, letters, symbols, etc.), which also define the unit for n. NOTE 1: The model for unicity has no probability error with a tail to infinity because only entropy values are used in the formula of n and by *definition* of entropy the entropy is already a limit to infinity. NOTE 2: It does not matter how the attacker may try to decipher the message. The attacker can of course use brute-force and try out all keys or he can use short-cuts, it is his choice and he is entirely free to use any method he desires. The work involved may be small, quite large or even unbounded -- the amount of work is actually unspecified. NOTE 3: Shannon's definition of "random cipher" was that "all decipherments must produce a random flat distribution over all bits in the plaintext space." 1.c. Unicity Value: The numerical value of n. It is important not to confuse a model with a measurement. Models predict measurements, and do so within an error range. What is the the error range for measuring n? First, note that the model works for any ciphertext, any plaintext. And for any such pairs, the result "n" is predicted by the model even if an attacker has unbounded resources, including infinite time. The value of "n" depends on the maximum possible entropy for the plaintext, the plaintext entropy, the entropy of the keys and the assumption that the cipher is a random cipher. Since all good ciphers should be a random cipher, for those ciphers the model provides a good approximation to what "n" actually is. The practical difficulty of reliably estimating the plaintext entropy and even the key entropy (which errors contribute to an error in "n") has nothing to do with the model itself or its error for "n", but on the errors for the quantities on which it depends -- however, it's not so hard to obtain good estimates and several are well-known. NOTE 1: Estimating the entropy of English (and other languages) has been the subject of considerable study. Various authors have measured H(M) for English texts and found values that lie between 1.0 and 1.5. The standard value quoted is 1.2, close to average of the extreme values. Even though each author has a different text, different preferred words, and different style preferences, we all come pretty close to the entropy value of 1.2. However, XML text (which is in English) is more redundant than natural English and should have a lower entropy. On the other hand, English text that is sent by SMS in cell phones has messages such as "Chk tat 4 u 2", where the redundancy is reduced and the entropy should be higher. NOTE 2: The benefit of compression is to increase unicity even if the compression algorithm is fully known to the attacker. If the plaintext is compressed before encipherment, then we rightly expect its entropy per compressed character to increase -- even though its entropy per English character does not increase. This is often confusing and may provide the wrong impressions that nothing is gained by compression or that we may need to "hide" the compression algorithm from the attacker. 2. READING THE FINE PRINT Of further importance and often ignored or even contradicted by some statements in the literature such as "any cipher can be attacked by exhaustively trying all possible keys", I usually like to call attention to the fact that any cipher (including 56-bit-key DES) can be theoretically secure against any attacker -- even an attacker with unbounded resources -- when the cipher is used within its unicity. Not only the One-Time Pad is theoretically secure, but any cipher can be theoretically secure if used within the unicity distance. Thus, indeed there is a theoretically secure defense even against brute-force attacks, which is to work within the unicity limit of the cipher. And, it works for any cipher that is a good random cipher -- irrespective of key-length or encryption method used. It is also important to note, as the literature has also not been very neat in this regard, that unicity is always referred to the plaintext. However, it may also be applied to indicate the least amount of ciphertext which needs to be intercepted in order to attack the cipher -- within the ciphertext/plaintext granularity. For example, for a simple OTP-cipher, being sloppy works because one byte of ciphertext links back to one byte of plaintext -- so, a unicity of n bytes implies n bytes of ciphertext. For DES, however, the ciphertext must be considered in blocks of 8 bytes -- so, a unicity of n bytes implies a corresponding modular number of 8 bytes. 3. ONLINE REFERENCES [Sha48] Shannon, C. Communication Theory of Secrecy Systems. Bell Syst. Tech. J., vol. 28, pp. 656-715, 1949. See also http://www3.edgenet.net/dcowley/docs.html for readable scanned images of the complete original paper and Shannon's definition of "unicity distance" in page 693. Arnold called my attention to a typeset version of the paper at http://www.cs.ucla.edu/~jkong/research/security/shannon.html. [Sha49] Shannon, C. A Mathematical Theory of Communication. Bell Syst. Tech. J., vol. 27, pp. 379-423, July 1948. See also http://cm.bell-labs.com/cm/ms/what/shannonday/paper.html Anton also made available the following link, with notes he took for Claude Crepeau's crypto course at McGill. See page 24 and following at http://crypto.cs.mcgill.ca/~stiglic/Papers/crypto1.ps (Anton notes that it's not unlikely that there are errors in those notes). Comments are welcome. Cheers, Ed Gerck --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From egerck at nma.com Mon Mar 3 20:21:25 2003 From: egerck at nma.com (Ed Gerck) Date: Mon, 03 Mar 2003 17:21:25 -0800 Subject: Scientists question electronic voting Message-ID: <3E63FF95.708674AF@nma.com> Henry Norr had an interesting article today at http://sfgate.com/cgi-bin/article.cgi?file=/chronicle/archive/2003/03/03/BU122767.DTL&type=business Printing a paper receipt that the voter can see is a proposal that addresses one of the major weaknesses of electronic voting. However, it creates problems that are even harder to solve than the silent subversion of e-records. For example, using the proposed system a voter can easily, by using a small concealed camera or a cell phone with a camera, obtain a copy of that receipt and use it to get money for the vote, or keep the job. And no one would know or be able to trace it. Of course, proponents of the paper ballot copy, like Peter Neumann and Rebecca Mercuri, will tell you the same thing that Peter affirmed in an official testimony before the California Assembly Elections & Reapportionment Committee on January 17, 2001, John Longville, Chair, session on touch-screen (DRE) voting systems, as recorded by C-SPAN (video available): "...I have an additional constraint on it [a voter approved paper ballot produced by a DRE machine] that it is behind reflective glass so that if you try to photograph it with a little secret camera hidden in your tie so you can go out and sell your vote for a bottle of whiskey or whatever it is, you will get a blank image. Now this may sound ridiculous from the point of view of trying to protect the voter, but this problem of having a receipt in some way that verifies that what seems to be your vote actually was recorded properly, is a fundamental issue." I was also in Sacramento that same day, and this was my reply, in the next panel, also with a C-SPAN videotape: ".. I would like to point out that it is very hard sometimes to take opinions, even though from a valued expert, at face value. I was hearing the former panel [on touch screen DRE systems] and Peter Neumann, who is a man beyond all best qualifications, made the affirmation that we cannot photograph what we can see. As my background is in optics, with a doctorate in optics, I certainly know that is not correct. If we can see the ballot we can photograph it, some way or another." But, look, it does not require a Ph.D. in physics to point out that what Peter says is incorrect -- of course you can photograph what you see. In other words, Peter's "solution" goes as much of this DRE discussion has also gone -- it's paying lip service to science but refutes basic scientific principles and progress. After all, what's the scientific progress behind storing a piece of paper as evidence? And, by the way, are not paper ballots what were mis-counted, mis-placed and lost in Florida? Finally, what we see in this discussion is also exactly what we in IT security know that we need to avoid. Insecure statements that create a false sense of security -- not to mention a real sense of angst. This statement, surely vetted by many people before it was printed, points out how much we need to improve in terms of a real-world model for voting. This opinion is my own, and is not a statement by any company. Cheers, Ed Gerck --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From rah at shipwright.com Mon Mar 3 20:23:56 2003 From: rah at shipwright.com (R. A. Hettinga) Date: Mon, 3 Mar 2003 20:23:56 -0500 Subject: Report of plans by U.S. to spy on U.N. states questioned Message-ID: http://dynamic.washtimes.com/twt-print.cfm?ArticleID=20030303-14680312 The Washington Times www.washingtontimes.com Report of plans by U.S. to spy on U.N. states questioned Published March 3, 2003 From combined dispatches LONDON - A British Sunday newspaper reported yesterday that the United States is waging a "secret" campaign to eavesdrop on U.N. Security Council delegations in New York in its battle to win votes in favor of war against Iraq. The London Observer said it had obtained a memo describing what it called a "dirty tricks" surveillance operation that involves interception of the home and office telephone calls and the e-mail of U.N. delegates. However, the authenticity of the memorandum was called into question and it was not clear from the text published by the newspaper that "secret" surveillance, interception of telephone calls and e-mail, or other extraordinary measures were suggested. The Observer story was widely reported throughout the Middle East and Europe and could complicate U.S. and British efforts to win a new resolution in the Security Council. The Observer said the memo was written by a top official at the National Security Agency (NSA), the U.S. agency that intercepts communications around the world, and circulated by e-mail to senior agents in the organization and to a friendly foreign intelligence agency. The newspaper said the memo was directed at senior NSA officials and advises them that the agency is "mounting a surge" aimed at gleaning information not only on how delegations on the Security Council will vote on any second resolution on Iraq, but also "policies," "negotiating positions," "alliances" and "dependencies" - the "whole gamut of information that could give US policymakers an edge in obtaining results favourable to U.S. goals or to head off surprises." The Observer identifies "Frank Koza" as chief of staff in the "Regional Targets" section of the NSA. Citing sources in Washington that it did not identify, the newspaper said the NSA initiative was backed by National Security Adviser Condoleezza Rice and had sparked divisions within the Bush administration. The newspaper said that it had shown the memo to three former intelligence operatives, whom it also did not identify, who judged its "language and content" as authentic. The newspaper also said it had confirmed that a man named Frank Koza does work for the NSA at a senior post in the "Regional Targets" division of the organization. The memo's authenticity was questioned by Internet reporter Matt Drudge, who cited several misspellings - including the name of the memo's author - on the document as published by the Observer, and an incorrect version of the agency's "top secret" stamp. Mr. Drudge, in an article posted on his Web site (www.drudgereport.com), noted that the memo used British spellings such as "favourable," "emphasise" and "recognise" instead of the American use of the letter "z" in the spellings, and that the spelling of the author of the memo was changed from "Frank Koza" to "Frank Kozu" on the Observer Web site (www.observer.co.uk) The Observer posted a footnote late Sunday after receiving "many queries from the United States," saying it changed the spellings for the convenience of its British audience. The newspaper attributed other errors to typographical mistakes. A later version of the Observer Web site spelled the author's name correctly as "Frank Koza," but printed it all in upper case, followed by three question marks. The memo describes orders to staff at the NSA to step up surveillance "particularly directed at ... U.N. Security Council members" to provide up-to-the-minute intelligence on their voting intentions. The memo, dated Jan. 31, makes clear that the targets of the heightened surveillance effort are the delegations from the so-called "middle six" delegations at the U.N. headquarters in New York, according to the British weekly. The six are Angola, Cameroon, Chile, Mexico, Guinea and Pakistan. The United States, Britain and Spain have sponsored a new U.N. resolution declaring Iraq in noncompliance with earlier U.N. demands that it disarm, which would in effect authorize the use of force. Nine votes are required to adopt the resolution to avoid a veto by one of the five permanent members: the United States, Britain, China, France and Russia. The United States and Britain are lobbying for support while France and Russia are lobbying to defeat the resolution without having to use their vetoes. -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From gnu at toad.com Mon Mar 3 20:47:06 2003 From: gnu at toad.com (John Gilmore) Date: Mon, 03 Mar 2003 17:47:06 -0800 Subject: NSA being used to influence UN votes on Iraq In-Reply-To: <20030302184952.GB10623@bual.research.att.com> Message-ID: <200303040147.h241l6B31089@new.toad.com> JI questioned: > Why is this even newsworthy? It's the NSA's responsibility to provide > sigint and comint. Furthermore, if the delegates are not US citizens, > and at least one end of the communication is outside the US, they are > not even breaking any laws in doing so. If the US found a similar memo from the French government, you can be sure it would be published immediately as newsworthy. At least in the lapdog US press. NSA's instructions to find tidbits usable to sway Security Council members were newsworthy in the UK, because the UK government is warmongering to suck up to the US, while the UK populace is opposed to the war. So "dirty tricks" being played by the US and UK governments to impose their will on the world are interesting to the UK populace. Most people regard wiretapping their opponents as an evil act, violative of privacy norms. Some people condone it in international relations on self-defense grounds; if your own life is threatened, then you gouge the other guy's eyes out, or chop off his hand, despite being revolted by doing that in normal life. But when wiretapping is used to overturn a legitimate sovereign government, which poses no obvious threat, then wiretapping is not justifiable on self-defense grounds. Civilized morality, rather than brute survival, becomes the defining standard. And the US is violating the standards of civilized morality by wiretapping its opponents (and its allies and neutrals) in an attempt to start a war of aggression. > If the delegations can't be bothered to protect their own > communications, it's their tough luck if they get intercepted. Tell me, how well have the cypherpunks done, after a decade, at protecting their own communications? We're still mostly talking in the clear, as far as I can tell. And no cypherpunk, to my knowledge, is well defended against the kinds of miniature bug that would routinely be planted in every suit jacket laundered anywhere near the UN Building. What was most interesting for me about that NSA message was that it said they needed to add "surge capacity" on some countries on the Security Council. Notably absent from the list was Mexico, which is on the Security Council. I guess NSA is already monitoring Mexican diplomatic communications so well that they didn't need to add any capacity. John PS: I spent a few weeks in Mexico last month. The majority of Mexicans want peace, as does their populist leader. Spain tried to sway Mexican president Vicente Fox from the peace position, and got nowhere. People who have recently experienced war first-hand tend to view it as more of a last resort, compared to people who have only experienced war via TV, videogames, and economic downturns. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From gowenwilliams at ntlworld.com Tue Mar 4 03:27:04 2003 From: gowenwilliams at ntlworld.com (Owen Williams) Date: Tue, 4 Mar 2003 08:27:04 +0000 Subject: M209B Message-ID: <146F6A48-4E1B-11D7-BE67-00306557AABA@ntlworld.com> Hi, My M209-B is on EBay with a start price of ?200 and a low reserve of ?800. http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&category=135&item=3211600913& rd=1 Anyone interested? Dr. Owen Williams Faculty of Applied Design and Engineering, Swansea Institute of Higher Education, Mount Pleasant Campus, Swansea, SA1 6ED --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From david.hopwood at zetnet.co.uk Mon Mar 3 16:42:38 2003 From: david.hopwood at zetnet.co.uk (David Hopwood) Date: Mon, 03 Mar 2003 21:42:38 +0000 Subject: Applied Cryptography: question on skid3 References: <20030302022429.GI3091@comcast.net> Message-ID: <3E63CC4E.B59CD5FC@zetnet.co.uk> MindFuq wrote: > I have a question on what seems to be a defect in the Applied > Cryptography book, and I couldn't get an answer out of Schneier or the > cypherpunks mailing list. Could any of you please clarify my issue? > > My question is regarding Schneier's write up of SKID3 on page 56. He > states that the protocol is not secure against man-in-the-middle > attacks because no secrets are involved. I'm finding this hard to > accept, because SKID3 uses a MAC, which requires a shared secret key > between the two parties. I played out the scenario, and cannot see > how a man in the middle could attack w/out knowing the secret key used > in the MAC. You're correct, AFAICS. -- David Hopwood Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From smb at research.att.com Wed Mar 5 14:30:54 2003 From: smb at research.att.com (Steven M. Bellovin) Date: Wed, 05 Mar 2003 14:30:54 -0500 Subject: Wiretap Act Does Not Cover Message 'in Storage' For Short Period (was Re: BNA's Internet Law News (ILN) - 2/27/03) In-Reply-To: Your message of "Sun, 02 Mar 2003 20:59:11 EST." Message-ID: <20030305193054.18B187B4D@berkshire.research.att.com> In message , "R. A. Hettinga" wr ites: > >--- begin forwarded text > > >Status: RO >From: Somebody >To: "R. A. Hettinga" >Subject: Re: Wiretap Act Does Not Cover Message 'in Storage' For Short Perio >d (was Re: BNA's Internet Law News (ILN) - 2/27/03) >Date: Sun, 2 Mar 2003 14:09:05 -0500 > >Bob, > >Technically, since their signal speed is slower than light, even >transmission lines act as storage devices. > >Wire tapping is now legal. > No, that's not waht the decision means. Access to stored messages also requires court permission. The (U.S.) ban on wiretapping without judicial permission is rooted in a Supreme Court decision, Katz v. United States, 389 U.S. 347 (1967) (http://caselaw.lp.findlaw.com/scripts/getcase.pl?navby=case&court=us&vol=389&invol=347) which held that a wiretap is a search which thus required a warrant. I don't think there's ever been any doubt that seizing a stored message required a warrant. But in an old case (OLMSTEAD v. U.S., 277 U.S. 438 (1928)) the Court had held that the Fourth Amendment only protected material things, and therefore *not* conversations monitored via a wiretap. That decision was overturned in Katz. The crucial difference, from a law enforcement perspective, is how hard it is to get the requisite court order. A stored message order is relatively easy; a wiretap order is very hard. Note that this distinction is primarily statutory, not (as far as I know) constitutional. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From tim at dierks.org Wed Mar 5 14:40:20 2003 From: tim at dierks.org (Tim Dierks) Date: Wed, 05 Mar 2003 14:40:20 -0500 Subject: Wiretap Act Does Not Cover Message 'in Storage' For Short Period (was Re: BNA's Internet Law News (ILN) - 2/27/03) In-Reply-To: <20030305193054.18B187B4D@berkshire.research.att.com> References: Message-ID: <5.2.1.0.2.20030305143458.0b2cdf38@dierks.org> At 02:30 PM 3/5/2003 -0500, Steven M. Bellovin wrote: > >From: Somebody > > > >Technically, since their signal speed is slower than light, even > >transmission lines act as storage devices. > > > >Wire tapping is now legal. > >The crucial difference, from a law enforcement perspective, is how hard >it is to get the requisite court order. A stored message order is >relatively easy; a wiretap order is very hard. Note that this >distinction is primarily statutory, not (as far as I know) >constitutional. Furthermore, it's apparently not illegal for a non-governmental actor to retrieve stored information which they have access to, although it might be illegal for them to wiretap a communication even if they had access to the physical medium over which it travels. I disagree with "Somebody"'s claim; I don't think that claim would go anywhere in court, since a transmission clearly falls under the category of "wire communication", and it's clear that transmission lines are the very entities the wiretap act has always been intended to protect, so Congress' intent is quite clear, regardless of any argument about "storage". - Tim --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From jsd at monmouth.com Wed Mar 5 16:57:17 2003 From: jsd at monmouth.com (John S. Denker) Date: Wed, 05 Mar 2003 16:57:17 -0500 Subject: Wiretap Act Does Not Cover Message 'in Storage' For Short Period In-Reply-To: <5.2.1.0.2.20030301213625.0aba0ec0@dierks.org> References: <5.2.1.0.2.20030301213625.0aba0ec0@dierks.org> <5.2.1.0.2.20030301213625.0aba0ec0@dierks.org> <5.2.1.0.2.20030302190118.0b1acca0@dierks.org> Message-ID: <3E6672BD.4000505@monmouth.com> Tim Dierks wrote: > In order to avoid overreaction to a nth-hand story, I've attempted to > locate some primary sources. > > Konop v. Hawaiian Airlines: > http://laws.lp.findlaw.com/getcase/9th/case/9955106p&exact=1 [US v Councilman:] > http://pacer.mad.uscourts.gov/dc/opinions/ponsor/pdf/councilman2.pdf Well done. Thanks. > I'd be interested in any opinions on how this affects the government's > need to get specific wiretap warrants; I don't know if the law which > makes illicit civilian wiretapping illegal is the same code which > governs the government's ability (or lack thereof) to intercept > communications. 0) IANAL. But as to the question of "same code", the answer is clearly "no". 1) As to government-authorized intercepts, see http://www.eff.org/Privacy/Surveillance/Terrorism_militias/20011031_eff_usa_patriot_analysis.html which gives a plain-language discussion of at least eight different standards under which some sort of authorization could be obtained. Also note that neither Konop nor Councilman involved government intercepts, so you can't learn anything about authorized intercepts by studying them. Also note that post-9/11 laws have superseded everything you might previously have known on the subject. 2) As to intercepts by civilians, it's wrong, and it may be punishable under many different theories and standards, including invasion of privacy, copyright infringement, computer trespass, computer vandalism, simple theft of things of value, and who-knows-what else. 3) As to unauthorized intercepts by government agents, in "theory" it is exactly the same as item (2), but in practice your chance of seeing anybody punished for it is comparable to your chance of seeing a State Trooper ticketed for speeding, tailgating, weaving, and failing to signal turns enroute to the donut shop. They're doing God's work, you know; why should mere laws and bills of rights apply to them? About the best you can realistically hope for is the exclusionary rule (illegally siezed evidence can't be used against you) but I wouldn't necessarily count on that. 4) Crypto-related sidelight: I wonder what would have happened if Konop had encrypted his sensitive data. (eBook format or the like. :-) Then could he have used the draconian provisions of the DMCA against his opponent (Hawaiian Airlines)????? --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From jsd at monmouth.com Wed Mar 5 20:03:40 2003 From: jsd at monmouth.com (John S. Denker) Date: Wed, 05 Mar 2003 20:03:40 -0500 Subject: Wiretap Act Does Not Cover Message 'in Storage' For Short Period (was Re: BNA's Internet Law News (ILN) - 2/27/03) In-Reply-To: <20030305193054.18B187B4D@berkshire.research.att.com> References: <20030305193054.18B187B4D@berkshire.research.att.com> Message-ID: <3E669E6C.3080603@monmouth.com> Steven M. Bellovin wrote: > The (U.S.) ban on wiretapping without judicial permission is rooted > in a Supreme Court decision, Katz v. United States, 389 U.S. 347 > (1967) > (http://caselaw.lp.findlaw.com/scripts/getcase.pl?navby=case&court=us&vol=389&invol=347) > which held that a wiretap is a search which thus required a warrant. > I don't think there's ever been any doubt that seizing a stored > message required a warrant. But in an old case (OLMSTEAD v. U.S., 277 > U.S. 438 (1928)) the Court had held that the Fourth Amendment only > protected material things, and therefore *not* conversations > monitored via a wiretap. That decision was overturned in Katz. Well, there could have been one other slight source of doubt, namely the theory that communications "with no expectation of privacy" are not private and intercepting them is free-for-all. Talking out loud in a public place, for instance. US laws going back to 1934 if not earlier made it clear that most wired transmissions were to be considered private. Wireless is a horse of a different color. IANAL but the last time I looked, there was no federal law against intercepting most wireless signals, but you were (generally) not allowed to disclose the contents to anyone else. I don't know what that means in practice. Perhaps I can act on the information, so long as I don't "disclose" it? Plus there is a welter of state laws. And cellphone transmissions are a more- protected special case. =================== In the communication industry (e.g. for tariff purposes) the usual test for whether something is a "stored" message is whether the storage adds value to the service. The delay that occurs in a store-and-forward network does not make it a "storage" service. This criterion has been very closely examined in connection with fly-by-night voice-over-IP telephony schemes, most of which are competitive only if they don't have to pay the tariffs that phone companies have to pay. The tariffs distinguish IP from telephony on the theory that IP is used to access "stored" data -- but if IP is used for telephony that theory goes out the window. Big mess. =================== The reason why wiretap warrants are (were?) harder to get is because they are insidious: If somebody comes to my house to sieze my papers I generally know about it. But if somebody siezes my bits while they are entrusted to some third party's wire, how am I supposed to know? For this reason and others, I very much doubt that Congress intended different treatment for -- data in transit on a wire versus -- data in transit in a store-and-forward switch. The intention, I assume, was a distinction between data in transit and data truly stored at the endpoint, under control of the end user. We should want the standards for siezing data in transit to be just as high as the standards for a "sneak and peek" search warrant, considerably higher than for an ordinary above-board search warrant. Since the Konop case didn't involve warrants or government searches, I doubt anything that judge says will have much effect on this issue. I think we should be much more worried about the USA PATRIOT act and the son-of-PATRIOT act that Ashcroft's aides say isn't being drafted. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From talg at cs.stanford.edu Wed Mar 5 20:15:15 2003 From: talg at cs.stanford.edu (Tal Garfinkel) Date: Wed, 5 Mar 2003 17:15:15 -0800 Subject: double shot of snake oil, good conclusion In-Reply-To: <3E63C3D9.4AE3E21D@nma.com> References: <0c248779bfc3c36c1d9db576541fbf48@melontraffickers.com> <3E63C3D9.4AE3E21D@nma.com> Message-ID: <20030306011515.GB7313@stanford.edu> > DRM can't really control what humans do and there is no commercial > value in saying that a document that I see cannot be printed or > forwarded -- because it can. I believe you are overlooking the assumed threat model, and thus the value of document control systems like the one that Microsoft is proposing. The benefit of systems like this is to aid in managing the huge amounts of confidential internal documents that enterprises generate and would like to keep out of paper form, thus out of the hands of dumpster divers and not left around on desktops, to prevent accidental propagation of internal documents, etc. Imposing access controls that rely on users not being explicitly mallicous are not "snake oil" and are not a new idea, nor is the recognition of their limitations. In systems that impose mandatory access controls of the more traditional type (ala Bell LaPadula), the user can always violate the *-property (i.e. no write down) by simply typing information from a high level document into a lower level document. Clearly, you could do the same thing with the system Microsoft is proposing, but preventing this type of attack is not the objective. The value of these type of controls that they help users you basically trust who might be careless, stupid, lazy or confused to do the right thing (however the right thing is defined, according to your company security policy). --Tal --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From t.c.jones at att.net Wed Mar 5 20:22:08 2003 From: t.c.jones at att.net (t.c.jones at att.net) Date: Thu, 06 Mar 2003 01:22:08 +0000 Subject: Chiasmus for Windows Message-ID: <20030306012211.250A35E42D@mononoke.wasabisystems.com> http://www.bsi.de/fachthem/chiasmus/indexeng.htm Interesting - the Germans are the ones that want everything to be open source? no? ..tom --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From I.Brown at cs.ucl.ac.uk Wed Mar 5 21:39:42 2003 From: I.Brown at cs.ucl.ac.uk (Ian Brown) Date: Thu, 6 Mar 2003 02:39:42 -0000 Subject: Scientists question electronic voting In-Reply-To: <3E63FF95.708674AF@nma.com> Message-ID: <000001c2e389$ab2b94e0$6601a8c0@happy> Ed Gerck wrote: > Printing a paper receipt that the voter can see is a proposal > that addresses one of the major weaknesses of electronic > voting. However, it creates problems that are even harder to > solve than the silent subversion of e-records. > > For example, using the proposed system a voter can easily, by > using a small concealed camera or a cell phone with a camera, > obtain a copy of that receipt and use it to get money for the > vote, or keep the job. And no one would know or be able to trace it. As a voter could record what they did with pencil-and-paper or a mechanical voting machine. The partial defence in all three systems is that the voter should be able to void the vote after photographing a "receipt" to hand over later to the vote-buyer, and then cast a real vote. In the UK, for example, you can obtain a new ballot paper from a polling station official in exchange for a "spoiled" one. I believe Rebecca Mercuri has always suggested that a voter should be able to confirm whether a receipt printed by an electronic voting machine correctly records their intended vote, and if not to void it. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From wrodger at pobox.com Wed Mar 5 22:16:51 2003 From: wrodger at pobox.com (Will Rodger) Date: Wed, 05 Mar 2003 22:16:51 -0500 Subject: Wiretap Act Does Not Cover Message 'in Storage' For Short Period (was Re: BNA's Internet Law News (ILN) - 2/27/03) In-Reply-To: <3E669E6C.3080603@monmouth.com> References: <20030305193054.18B187B4D@berkshire.research.att.com> <20030305193054.18B187B4D@berkshire.research.att.com> Message-ID: <5.2.0.9.0.20030305221242.00a70e80@mail.comcast.net> John says: >Wireless is a horse of a different color. IANAL but >the last time I looked, there was no federal law >against intercepting most wireless signals, but you >were (generally) not allowed to disclose the contents >to anyone else. No longer, if it ever was. It's a crime, as evidenced by the wireless scandal a few years back when some Democrat partisan intercepted communications of Republican leadership in Florida, then talked. The simple act of interception was illegal. Will Rodger --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From frantz at pwpconsult.com Thu Mar 6 02:14:40 2003 From: frantz at pwpconsult.com (Bill Frantz) Date: Wed, 5 Mar 2003 23:14:40 -0800 Subject: Scientists question electronic voting In-Reply-To: <3E63FF95.708674AF@nma.com> Message-ID: At 5:21 PM -0800 3/3/03, Ed Gerck wrote: >Henry Norr had an interesting article today at >http://sfgate.com/cgi-bin/article.cgi?file=/chronicle/archive/2003/03/03/BU1227 >67.DTL&type=business > >Printing a paper receipt that the voter can see is a proposal that addresses >one of the major weaknesses of electronic voting. However, it creates >problems that are even harder to solve than the silent subversion of >e-records. > >For example, using the proposed system a voter can easily, by using a >small concealed camera or a cell phone with a camera, obtain a copy of >that receipt and use it to get money for the vote, or keep the job. And >no one would know or be able to trace it. The best counter to this problem is widely available systems to produce fake photos of the vote, so the vote buyer can't know whether the votes he sees in the photo are the real votes, or fake ones. The easiest way to implement is to let people photograph the paper on the sample/practice -- not for real voting -- machine that poll workers use to teach voters how to use the real machines. Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | Due process for all | Periwinkle -- Consulting (408)356-8506 | used to be the | 16345 Englewood Ave. frantz at pwpconsult.com | American way. | Los Gatos, CA 95032, USA --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From gnu at toad.com Thu Mar 6 03:19:34 2003 From: gnu at toad.com (John Gilmore) Date: Thu, 06 Mar 2003 00:19:34 -0800 Subject: Delta CAPPS-2 watch: decrypt boarding passes! Message-ID: <200303060819.h268JYB28653@new.toad.com> Delta Air Lines is the guinea pig for the CAPPS-2 intrusive database search on every passenger. They'll be doing this in three cities, starting THIS MONTH. First, if you were thinking of flying, be sure not to fly on Delta. See http://boycottdelta.org. Second, if you're stuck on Delta, or want to watch their system, then please report back (to me, gnu at delta.toad.com, or to the cryptography list) about how the airport checkin and screening process has changed. We should be able to rapidly figure out which cities they are doing this in, based on the airline's behavior changes. For example, some stories say that the system will require more info from you, like your home address and date of birth. Other stories say that no new info is collected. One has pointed out that Delta's frequent flyer program has collected birthdate info for years. I suggest flying WITHOUT tying your flight into the frequent flyer database. Also, most news stories claim that your boarding pass will have "encrypted" on it a "red/yellow/green" flag that tells the security screeners whether to: * Block you from getting on the flight * Search the hell out of you * Let you walk through with minimal hassle The stories report that the security screeners at the checkpoint might have new machines to run your boarding pass through (to "decrypt" this info). This could all be disinformation. If true, it should be easy to spot, particularly if you've flown through these airports before. And, besides identifying what cities they're doing this in, we should also start examining a collection of these boarding passes, looking for the encrypted "let me through without searching me" information. Or the "Don't let me fly" information. Then we can evaluate how easy it would be to turn one into another. (Don't mistake a system that claims to provide security for one that actually does.) I'll restate just for the record that I oppose this entire program, as well as the unconstitutional demand for ID before traveling in the US. I'm suing Ashcroft, TSA, and Homeland Security over it. We're currently awaiting Judge Illston's decision on the government's motion to dismiss the case as frivolous. (How many of you who thought it was frivolous eight months ago, still think it is?) http://cryptome.org/freetotravel.htm John --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ben at algroup.co.uk Thu Mar 6 06:47:22 2003 From: ben at algroup.co.uk (Ben Laurie) Date: Thu, 06 Mar 2003 11:47:22 +0000 Subject: Proven Primes Message-ID: <3E673549.9040309@algroup.co.uk> I'm looking for a list or lists of sensibly sized proven primes - all the lists I can find are more interested in records, which are _way_ too big for cryptographic purposes. By "sensibly sized" I mean in the range 512-8192 bits. I'm particularly after Sophie Germain primes right now, but I guess all primes are of interest. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From don at mit.edu Thu Mar 6 10:02:09 2003 From: don at mit.edu (Don Davis) Date: Thu, 6 Mar 2003 10:02:09 -0500 Subject: 3-rotor enigma on ebay: $5200 Message-ID: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=2162414185 i saw this on the boing-boing blog. - don davis, boston - --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ptrei at rsasecurity.com Thu Mar 6 10:13:22 2003 From: ptrei at rsasecurity.com (Trei, Peter) Date: Thu, 6 Mar 2003 10:13:22 -0500 Subject: Scientists question electronic voting Message-ID: > Ian Brown[SMTP:I.Brown at cs.ucl.ac.uk] wrote: > > > Ed Gerck wrote: > > Printing a paper receipt that the voter can see is a proposal > > that addresses one of the major weaknesses of electronic > > voting. However, it creates problems that are even harder to > > solve than the silent subversion of e-records. > > > > For example, using the proposed system a voter can easily, by > > using a small concealed camera or a cell phone with a camera, > > obtain a copy of that receipt and use it to get money for the > > vote, or keep the job. And no one would know or be able to trace it. > > As a voter could record what they did with pencil-and-paper or a > mechanical voting machine. > > The partial defence in all three systems is that the voter should be > able to void the vote after photographing a "receipt" to hand over later > to the vote-buyer, and then cast a real vote. In the UK, for example, > you can obtain a new ballot paper from a polling station official in > exchange for a "spoiled" one. I believe Rebecca Mercuri has always > suggested that a voter should be able to confirm whether a receipt > printed by an electronic voting machine correctly records their intended > vote, and if not to void it. > I'd prefer that the printed receipt be retained at the polling station, after the voter has had an opportunity to examine it. This serves two purposes: First, it prevents the vote selling described above, and second, if a recount is required, it allows the recount to be done on the basis of a trustworthy record, already certified by the voter as accurate. This loses some of the economic benefits of all-electronic systems, since security still needs to be provided for the receipts for some period, but is far less prone to invisible abuse. Peter Trei --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From mads at opencs.com.br Thu Mar 6 10:15:58 2003 From: mads at opencs.com.br (Mads Rasmussen) Date: Thu, 6 Mar 2003 12:15:58 -0300 Subject: ENC: Proven Primes Message-ID: <23F980CFF4C45B4792FFF3CE015C541A025C2D@olimpia.opencs.com.br> > -----Mensagem original----- > De: Ben Laurie [mailto:ben at algroup.co.uk] > Enviada em: quinta-feira, 6 de mar?o de 2003 08:47 > Para: Cryptography > Assunto: Proven Primes > > I'm looking for a list or lists of sensibly sized proven primes - all > the lists I can find are more interested in records, which are _way_ too > big for cryptographic purposes. > > By "sensibly sized" I mean in the range 512-8192 bits. I'm particularly > after Sophie Germain primes right now, but I guess all primes are of > interest. You might look at the IKE groups The Internet Key Exchange (IKE) http://www.ietf.org/rfc/rfc2409.txt "More MODP Diffie-Hellman groups for IKE" http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-modp-groups-05. txt Regards, Mads --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From astiglic at okiok.com Thu Mar 6 10:37:51 2003 From: astiglic at okiok.com (Anton Stiglic) Date: Thu, 6 Mar 2003 10:37:51 -0500 Subject: Proven Primes References: <3E673549.9040309@algroup.co.uk> Message-ID: <002401c2e3f6$64a0b970$d0966395@p1038mobile> ----- Original Message ----- From: "Ben Laurie" To: "Cryptography" Sent: Thursday, March 06, 2003 6:47 AM Subject: Proven Primes > I'm looking for a list or lists of sensibly sized proven primes - all > the lists I can find are more interested in records, which are _way_ too > big for cryptographic purposes. I'm not aware of such a list. If you can't find any you can generate the list yourself using ECPP (Elliptic Curve Primality Proving), an implementation of which is available here http://www.lix.polytechnique.fr/~morain/Prgms/ecpp.english.html The result of ECPP is guaranteed (no probability of error), and provides a certificate of primality for integers that are proven to be prime. A competing algorithm is the Jacobi Sums test, but it is much more complicated, so implementation errors are not to be disregarded, with ECPP the verification of a primality certificate is simple to implement, so you can make sure that there were no errors in the implementation of the proving algorithm. There is also the new algorithm by Agrawal, Kayal and Saxena, but I don't believe that it is efficient in practice for the sizes of integers you are looking at. Also note that if you assume the Extended Riemann Hypothesis (ERH) to be true, you can use the Miller-Rabin algorithm in a deterministic fashion in polynomial time with no probability error. The ECPP package is easy to use and fast. The site gives benchmarks for proving 512-bit primes: Pentium III (450MHz) 4.4 sec Solaris 5.7 9.5 sec Alpha EV56 (500MHz) 4 sec I suggest you generate potential Sophie Germain primes q using your favorite library (I use OpenSSL for example) and then use the ECPP package to verify that in fact both q and 2q + 1 are really prime. --Anton --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From lloyd at acm.jhu.edu Thu Mar 6 10:32:27 2003 From: lloyd at acm.jhu.edu (Jack Lloyd) Date: Thu, 6 Mar 2003 10:32:27 -0500 (EST) Subject: Proven Primes In-Reply-To: <3E673549.9040309@algroup.co.uk> Message-ID: I believe the IPSec primes had been proven. All are SG primes with a g=2 Check RFC 2412, draft-ietf-ipsec-ikev2-05.txt, and draft-ietf-ipsec-ike-modp-groups-05.txt However, I don't seen any primality proof certificates included in the texts. On Thu, 6 Mar 2003, Ben Laurie wrote: > I'm looking for a list or lists of sensibly sized proven primes - all > the lists I can find are more interested in records, which are _way_ too > big for cryptographic purposes. > > By "sensibly sized" I mean in the range 512-8192 bits. I'm particularly > after Sophie Germain primes right now, but I guess all primes are of > interest. > > Cheers, > > Ben. > > --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From I.Brown at cs.ucl.ac.uk Thu Mar 6 10:38:11 2003 From: I.Brown at cs.ucl.ac.uk (Ian Brown) Date: Thu, 6 Mar 2003 15:38:11 -0000 Subject: Scientists question electronic voting In-Reply-To: Message-ID: <000201c2e3f6$6c1e24d0$6601a8c0@happy> Peter Trei wrote: > I'd prefer that the printed receipt be retained at the > polling station, after the voter has had an opportunity to > examine it. This serves two purposes: First, it prevents the > vote selling described above, and second, if a recount is > required, it allows the recount to be done on the basis of a > trustworthy record, already certified by the voter as accurate. Indeed, that's essential for both the reasons you state. Mercuri's design is for the voter to see the printed receipt behind a glass screen. They then press a "Yes" or "No" button to either vote and send the receipt to the trustworthy record, or void it and send the receipt to the bin. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From jsd at monmouth.com Thu Mar 6 10:44:00 2003 From: jsd at monmouth.com (John S. Denker) Date: Thu, 06 Mar 2003 10:44:00 -0500 Subject: Wiretap Act Does Not Cover Message 'in Storage' For Short Period (was Re: BNA's Internet Law News (ILN) - 2/27/03) In-Reply-To: <20030305193054.18B187B4D@berkshire.research.att.com> References: <20030305193054.18B187B4D@berkshire.research.att.com> <20030305193054.18B187B4D@berkshire.research.att.com> <5.2.0.9.0.20030305221242.00a70e80@mail.comcast.net> Message-ID: <3E676CC0.1010809@monmouth.com> Will Rodger wrote: > John says: > > > Wireless is a horse of a different color. IANAL but > > the last time I looked, there was no federal law > > against intercepting most wireless signals, but you > > were (generally) not allowed to disclose the contents > > to anyone else. > > > No longer, if it ever was. It's a crime, as evidenced by the wireless > scandal a few years back when some Democrat partisan intercepted > communications of Republican leadership in Florida, then talked. The > simple act of interception was illegal. Next time, before disagreeing with someone: a) Please read what he actually wrote, and b) Don't quote snippets out of context. Three sentences later, at the end of the paragraph that began as quoted above, I explicitly pointed out that > cellphone transmissions are a more-protected special case. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From astiglic at okiok.com Thu Mar 6 10:52:50 2003 From: astiglic at okiok.com (Anton Stiglic) Date: Thu, 6 Mar 2003 10:52:50 -0500 Subject: Scientists question electronic voting References: Message-ID: <003601c2e3f8$736ea1e0$d0966395@p1038mobile> ----- Original Message ----- From: "Bill Frantz" To: "Ed Gerck" ; Sent: Thursday, March 06, 2003 2:14 AM Subject: Re: Scientists question electronic voting [..] > The best counter to this problem is widely available systems to produce > fake photos of the vote, so the vote buyer can't know whether the votes he > sees in the photo are the real votes, or fake ones. > > The easiest way to implement is to let people photograph the paper on the > sample/practice -- not for real voting -- machine that poll workers use to > teach voters how to use the real machines. An extortionist could provide their own camera device to the voter, which has a built in clock that timestamps the photos and does some watermarking, or something like that, which could complicate the counter-measures. But this problem already exists with current non-electronic voting scheme. It depends on the value attributed to a vote (would an extortionist be willing to provide these custom devices?). --Anton --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From bear at sonic.net Thu Mar 6 11:25:54 2003 From: bear at sonic.net (bear) Date: Thu, 6 Mar 2003 08:25:54 -0800 (PST) Subject: Scientists question electronic voting In-Reply-To: Message-ID: On Wed, 5 Mar 2003, Bill Frantz wrote: >The best counter to this problem is widely available systems to produce >fake photos of the vote, so the vote buyer can't know whether the votes he >sees in the photo are the real votes, or fake ones. blink, blink. you mean *MORE* widely available than photoshop/gimp/illustrator/etc? Let's face it, if somebody can *see* their vote, they can record it. and if someone can record it, then systems for counterfeiting such a record already exist and are already widely dispersed. If the republicans, democrats, greens, libertarians, natural law party, and communist party all offer you a bottle of beer for a record of your vote for them next year, there's no reason why you shouldn't go home without a six-pack. Bear --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From egerck at nma.com Thu Mar 6 12:02:48 2003 From: egerck at nma.com (Ed Gerck) Date: Thu, 06 Mar 2003 09:02:48 -0800 Subject: Scientists question electronic voting References: <003601c2e3f8$736ea1e0$d0966395@p1038mobile> Message-ID: <3E677F38.C4002959@nma.com> Anton Stiglic wrote: > An extortionist could provide their own camera device to the voter, which > has > a built in clock that timestamps the photos and does some watermarking, or > something like that, which could complicate the counter-measures. But this > problem already exists with current non-electronic voting scheme. > It depends on the value attributed to a vote (would an extortionist be > willing to provide these custom devices?). This is not possible for current paper ballots, for several reasons. For example, if you take a picture of your punch card as a proof of how you voted, what is to prevent you -- after the picture is taken -- to punch another hole for the same race and invalidate your vote? Or, to ask the clerk for a second ballot, saying that you punched the wrong hole, and vote for another candidate? The same happens for optical scan cards. These "proofs" are easily deniable and, thus, have no value to prove how the voter actually voted. Likewise, electronically, there is no way that a voter could prove how he voted, even if the confirmation screen does list all the choices that the voter has chosen, if that screen has two buttons: "go back", "confirm", and a suitable logic. After the voter presses "confirm" the voter sees a "thank you" screen without any choices present. The logic canbe set up in such a way in terms of key presses and intermediate states that even photographing the mouse cursor on a pressed "confirm" button does not prove that the voter did not take the mouse out and, instead, pressed the "go back" button to change his choices. On the other hand, photographing a paper receipt behind a glass, which receipt is printed after your vote choices are final, is not readily deniable because that receipt is printed only after you confirm your choices. To deny that receipt the voter would have to say that the machine erred, which, if proved otherwise, could lead to criminal charges (e.g., the machine would be taken off the polls and, after the polls close the machine would be tallied; if the electronic tally would agree with the paper tally, the voter would be in trouble). Protection against providing voters a receipt, voluntary or not, is often overlooked by those who are not familiar with election issues. For example, the first press release by MIT/Caltech principals after Nov/2000 said that the solution would be to provide the voter with a receipt showing how they voted. Later on, MIT/Caltech reformed that view and have been doing an excellent job at what I see as a process of transforming elections from art to science, which is a good development after Nov/2000. Cheers, Ed Gerck --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ben at algroup.co.uk Thu Mar 6 12:01:44 2003 From: ben at algroup.co.uk (Ben Laurie) Date: Thu, 06 Mar 2003 17:01:44 +0000 Subject: Proven Primes In-Reply-To: <002401c2e3f6$64a0b970$d0966395@p1038mobile> References: <3E673549.9040309@algroup.co.uk> <002401c2e3f6$64a0b970$d0966395@p1038mobile> Message-ID: <3E677EF8.7070609@algroup.co.uk> Anton Stiglic wrote: > ----- Original Message ----- From: "Ben Laurie" > To: "Cryptography" Sent: Thursday, > March 06, 2003 6:47 AM Subject: Proven Primes > > > >> I'm looking for a list or lists of sensibly sized proven primes - >> all the lists I can find are more interested in records, which are >> _way_ too big for cryptographic purposes. > > > > I'm not aware of such a list. If you can't find any you can generate > the list yourself using ECPP (Elliptic Curve Primality Proving), an > implementation of which is available here > http://www.lix.polytechnique.fr/~morain/Prgms/ecpp.english.html The > result of ECPP is guaranteed (no probability of error), and provides > a certificate of primality for integers that are proven to be prime. > A competing algorithm is the Jacobi Sums test, but it is much more > complicated, so implementation errors are not to be disregarded, with > ECPP the verification of a primality certificate is simple to > implement, so you can make sure that there were no errors in the > implementation of the proving algorithm. I'm not convinced any of those binaries are going to run on my system (which is FreeBSD), and anyway, if I'm going to use a binary to do ECPP I may as well shove it through Mathematica - much prettier UI :-) Is their no free implementation of ECPP? Is there at least a free verifier? > There is also the new algorithm by Agrawal, Kayal and Saxena, but I > don't believe that it is efficient in practice for the sizes of > integers you are looking at. Also note that if you assume the > Extended Riemann Hypothesis (ERH) to be true, you can use the > Miller-Rabin algorithm in a deterministic fashion in polynomial time > with no probability error. Oh? > The ECPP package is easy to use and fast. The site gives benchmarks > for proving 512-bit primes: Pentium III (450MHz) 4.4 > sec Solaris 5.7 9.5 sec Alpha EV56 (500MHz) > 4 sec > > I suggest you generate potential Sophie Germain primes q using your > favorite library (I use OpenSSL for example) and then use the ECPP > package to verify that in fact both q and 2q + 1 are really prime. Sounds like a plan. Thanks very much for the info. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From astiglic at okiok.com Thu Mar 6 12:26:07 2003 From: astiglic at okiok.com (Anton Stiglic) Date: Thu, 6 Mar 2003 12:26:07 -0500 Subject: Scientists question electronic voting References: <003601c2e3f8$736ea1e0$d0966395@p1038mobile> <3E677F38.C4002959@nma.com> Message-ID: <001001c2e405$7b71a510$ac9c6395@p1038mobile> ----- Original Message ----- From: "Ed Gerck" [...] > This is not possible for current paper ballots, for several reasons. For > example, if you take a picture of your punch card as a proof of how you > voted, what is to prevent you -- after the picture is taken -- to punch > another hole for the same race and invalidate your vote? Or, to ask the > clerk for a second ballot, saying that you punched the wrong hole, > and vote for another candidate? The same happens for optical scan > cards. These "proofs" are easily deniable and, thus, have no value > to prove how the voter actually voted. > > Likewise, electronically, there is no way that a voter could prove how he > voted, even if the confirmation screen does list all the choices that the voter > has chosen, if that screen has two buttons: "go back", "confirm", and a > suitable logic. After the voter presses "confirm" the voter sees a "thank you" > screen without any choices present. The logic canbe set up in such a way > in terms of key presses and intermediate states that even photographing > the mouse cursor on a pressed "confirm" button does not prove that the voter > did not take the mouse out and, instead, pressed the "go back" button to > change his choices. Well the whole process can be filmed, not necessarily photographed... It's difficult to counter the "attack". In you screen example, you can photograph the vote and then immediately photograph the "thank you", if the photographs include the time in milliseconds, and the interval is short, you can be confident to some degree that the vote that was photographed was really the vote that was casted. You can have tamper resistant film/photograph devices and whatever you want, have the frames digitally signed and timestamped, but this is where I point out that you need to consider the value of the vote to estimate how far an extortionist would be willing to go. --Anton --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From dgarcia at hollyfeld.org Thu Mar 6 12:17:56 2003 From: dgarcia at hollyfeld.org (Daniel Garcia) Date: Thu, 6 Mar 2003 12:17:56 -0500 (EST) Subject: 3-rotor enigma on ebay: $5200 In-Reply-To: Message-ID: On Thu, 6 Mar 2003, Don Davis wrote: > http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=2162414185 > i saw this on the boing-boing blog. Interesting, when i try to look at this from work (over in brighton, actually), i get: Dear User: Unfortunately, access to this particular category or item has been blocked due to legal restrictions in your home country. Based on our discussions with concerned government agencies and eBay community members, we have taken these steps to reduce the chance of inappropriate items being displayed. Regrettably, in some cases this policy may prevent users from accessing items that do not violate the law. At this time, we are working on less restrictive alternatives. Please accept our apologies for any inconvenience this may cause you, and we hope you may find other items of interest on eBay. But I can hit it from my dsl line at home (right up the road). I guess Verizon T1-land is restricted... --Dg -- Wir mussen wissen; wir werden wissen Daniel Garcia - dgarcia at silentnoise.org - http://silentnoise.org MCH/EN/RE S* W N+++ PEC++ !D A a+ C++ G QJ+ 666 Y+ Z* pgp D9720875 - fingerprint EF70 3635 60D7 FBF4 EC57 684A 5088 E8B0 D972 0875 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From egerck at nma.com Thu Mar 6 12:38:25 2003 From: egerck at nma.com (Ed Gerck) Date: Thu, 06 Mar 2003 09:38:25 -0800 Subject: double shot of snake oil, good conclusion References: <0c248779bfc3c36c1d9db576541fbf48@melontraffickers.com> <3E63C3D9.4AE3E21D@nma.com> <20030306011515.GB7313@stanford.edu> Message-ID: <3E678791.A7131CFF@nma.com> Tal Garfinkel wrote: > The value of these type of controls that they help users you basically > trust who might be careless, stupid, lazy or confused to do the right > thing (however the right thing is defined, according to your company > security policy). It beats me that "users you basically trust" might also be "careless, stupid, lazy or confused" ;-) Your point might be better expressed as "the company security policy would be followed even if you do NOT trust the users to do the right thing." But, as we know, this only works if the users are not malicious, if social engineering cannot be used, if there are no disgruntled employees, and other equally improbable factors. BTW, one of the arguments that Microsoft uses to motivate people to be careful with unlawful copies of Microsoft products is that disgruntled employees provide the bulk of all their investigations on piracy, and everyone has disgruntled employees. We also know that insider threats are responsible for 71% of computer fraud. Thus, the lack of value of these type of controls is to harass the legitimate users and give a false sense of security. It reminds me of a cartoon I saw recently, where the general tells a secretary to shred the document, but make a copy first for the files. Cheers, Ed Gerck --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From egerck at nma.com Thu Mar 6 12:48:32 2003 From: egerck at nma.com (Ed Gerck) Date: Thu, 06 Mar 2003 09:48:32 -0800 Subject: Scientists question electronic voting References: <003601c2e3f8$736ea1e0$d0966395@p1038mobile> <3E677F38.C4002959@nma.com> <001001c2e405$7b71a510$ac9c6395@p1038mobile> Message-ID: <3E6789F0.65680AD8@nma.com> Anton Stiglic wrote: > -Well the whole process can be filmed, not necessarily photographed... > It's difficult to counter the "attack". In you screen example, you can > photograph > the vote and then immediately photograph the "thank you", if the photographs > include the time in milliseconds, and the interval is short, you can be > confident > to some degree that the vote that was photographed was really the vote that > was casted. > You can have tamper resistant film/photograph devices and whatever you want, > have the frames digitally signed and timestamped, > but this is where I point out that you need to consider the value of the > vote to > estimate how far an extortionist would be willing to go. The electronic process can be made much harder to circumvent by allowing voters to cast any number of ballots but counting only the last ballot cast. Since a voter could always cast another vote after the one that was so carefully filmed, there would be no value for such film. BTW, a similar process happens in proxy voting for shareholders meeting, where voters can send their vote (called a "proxy") before the meeting but can also go to the meeting and vote any way they please -- trumping the original vote. Much work needs to be done, and tested, to protect the integrity of public elections. Even with all such precautions, if the choices made by a voter are disclosed (ie, not just the tally for all voters) then a voter can be identified by using an unlikely pattern -- and the Mafia has, reportedly, used this method in Italy to force (and enforce) voter choices in an otherwise private ballot. Cheers, Ed Gerck --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From DaveHowe at gmx.co.uk Thu Mar 6 12:49:50 2003 From: DaveHowe at gmx.co.uk (David Howe) Date: Thu, 6 Mar 2003 17:49:50 -0000 Subject: Scientists question electronic voting References: <003601c2e3f8$736ea1e0$d0966395@p1038mobile> <3E677F38.C4002959@nma.com> Message-ID: <013601c2e408$d36e7ce0$c71121c2@sharpuk.co.uk> at Thursday, March 06, 2003 5:02 PM, Ed Gerck was seen to say: > On the other hand, photographing a paper receipt behind a glass, which > receipt is printed after your vote choices are final, is not readily > deniable because that receipt is printed only after you confirm your > choices. as has been pointed out repeatedly - either you have some way to "bin" the receipt and start over, or it is worthless (and merely confirms you made a bad vote without giving you any opportunity to correct it) That given, you could vote once for each party, take your photograph, void the vote (and receipt) for each one, and then vote the way you originally intended to :) --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From astiglic at okiok.com Thu Mar 6 13:00:18 2003 From: astiglic at okiok.com (Anton Stiglic) Date: Thu, 6 Mar 2003 13:00:18 -0500 Subject: Proven Primes References: <3E673549.9040309@algroup.co.uk> <002401c2e3f6$64a0b970$d0966395@p1038mobile> <3E677EF8.7070609@algroup.co.uk> Message-ID: <003e01c2e40a$4162b8f0$ac9c6395@p1038mobile> ----- Original Message ----- From: "Ben Laurie" To: "Anton Stiglic" > [Talking about the ECPP package...] > I'm not convinced any of those binaries are going to run on my system > (which is FreeBSD), and anyway, if I'm going to use a binary to do ECPP > I may as well shove it through Mathematica - much prettier UI :-) > > Is their no free implementation of ECPP? Is there at least a free verifier? It's been a while since I tried it, I don't remember which platform and OS I used (a pentium with some sort of Linux) but I know that I didn't have any problems using it. I think that ECPP comes with a Maple certificate verifier, which might be what you are looking for. I think you can also convert certificates to Mathematica format. So once you have these certificates of primality it's easy to verify them. But I haven't tried any of those features... --Anton --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From fgrieu at micronet.fr Thu Mar 6 12:58:48 2003 From: fgrieu at micronet.fr (Francois Grieu) Date: Thu, 6 Mar 2003 18:58:48 +0100 Subject: Scientists question electronic voting In-Reply-To: References: Message-ID: Peter Trei wrote: > I'd prefer that the printed receipt be retained at the polling > station, after the voter has had an opportunity to examine it. > This serves two purposes: First, it prevents the vote selling > described above, and second, if a recount is required, it allows > the recount to be done on the basis of a trustworthy record, > already certified by the voter as accurate. Then there is the problem that the printed receipt must not be usable to determine who voted for who, even knowing in which order the voters went to the machine. Therefore the printed receipts must be shuffled. Which brings us straight back to papers in a box, that we shake before opening. Every way I look at it, electronic voting has a hard time to match the resilience to abuse of the traditional bulletin-in-an-enveloppe-in-a-box. Francois Grieu --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ptrei at rsasecurity.com Thu Mar 6 13:05:15 2003 From: ptrei at rsasecurity.com (Trei, Peter) Date: Thu, 6 Mar 2003 13:05:15 -0500 Subject: Scientists question electronic voting Message-ID: > Francois Grieu[SMTP:fgrieu at micronet.fr] > > Peter Trei wrote: > > > I'd prefer that the printed receipt be retained at the polling > > station, after the voter has had an opportunity to examine it. > > This serves two purposes: First, it prevents the vote selling > > described above, and second, if a recount is required, it allows > > the recount to be done on the basis of a trustworthy record, > > already certified by the voter as accurate. > > Then there is the problem that the printed receipt must not be usable > to determine who voted for who, even knowing in which order the > voters went to the machine. Therefore the printed receipts must be > shuffled. Which brings us straight back to papers in a box, that we > shake before opening. > > Every way I look at it, electronic voting has a hard time to match > the resilience to abuse of the traditional > bulletin-in-an-enveloppe-in-a-box. > > Francois Grieu > I absolutely agree. Here in the US, where voters often have to make over a dozen choices each time they vote, the value of automating the process is significant. But it *must* be done in a way which increases voter confidence in the result. Ballot boxes are also subject to many forms of fraud. But a dual system (electronic backed up by paper) is more resistant to attack then either alone. Peter --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From reinhold at world.std.com Thu Mar 6 10:26:41 2003 From: reinhold at world.std.com (Arnold G. Reinhold) Date: Thu, 6 Mar 2003 10:26:41 -0500 Subject: Wiretap Act Does Not Cover Message 'in Storage' For Short Period In-Reply-To: <3E6672BD.4000505@monmouth.com> References: <5.2.1.0.2.20030301213625.0aba0ec0@dierks.org> <5.2.1.0.2.20030301213625.0aba0ec0@dierks.org> <5.2.1.0.2.20030302190118.0b1acca0@dierks.org> <3E6672BD.4000505@monmouth.com> Message-ID: At 4:57 PM -0500 3/5/03, John S. Denker wrote: >Tim Dierks wrote: > >> In order to avoid overreaction to a nth-hand story, I've attempted to >> locate some primary sources. >> >> Konop v. Hawaiian Airlines: > > http://laws.lp.findlaw.com/getcase/9th/case/9955106p&exact=1 >[US v Councilman:] >> http://pacer.mad.uscourts.gov/dc/opinions/ponsor/pdf/councilman2.pdf > >Well done. Thanks. > >> I'd be interested in any opinions on how this affects the government's >> need to get specific wiretap warrants; I don't know if the law which >> makes illicit civilian wiretapping illegal is the same code which >> governs the government's ability (or lack thereof) to intercept >> communications. > >0) IANAL. But as to the question of "same code", the >answer is clearly "no". I2ANAL, but I don't think that's clear at all, unless your are talking about specific paragraphs within the Wiretap Act and the Stored Communications Act. > >1) As to government-authorized intercepts, see > >http://www.eff.org/Privacy/Surveillance/Terrorism_militias/20011031_eff_usa_patriot_analysis.html > >which gives a plain-language discussion of at least >eight different standards under which some sort of >authorization could be obtained. > >Also note that neither Konop nor Councilman involved >government intercepts, so you can't learn anything about >authorized intercepts by studying them. Also note that >post-9/11 laws have superseded everything you might >previously have known on the subject. The Konop decision specifically talks about government intercepts. See section B7, for example. They even discuss the post 9/11 situation in B6. > >2) As to intercepts by civilians, it's wrong, and it >may be punishable under many different theories and >standards, including invasion of privacy, copyright >infringement, computer trespass, computer vandalism, >simple theft of things of value, and who-knows-what >else. Add the Railway Labor Act in this case. > > >4) Crypto-related sidelight: I wonder what would >have happened if Konop had encrypted his sensitive >data. (eBook format or the like. :-) Then could he >have used the draconian provisions of the DMCA >against his opponent (Hawaiian Airlines)????? > There are some who would argue that the simple password protection scheme Knopp used would be a "technological protection" covered under DMCA. However, the penalty for access to protected material, as opposed to trafficking in technology, is a $2000 fine, which may not seem draconian to an airline. Arnold Reinhold --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From wrodger at pobox.com Thu Mar 6 13:49:18 2003 From: wrodger at pobox.com (Will Rodger) Date: Thu, 06 Mar 2003 13:49:18 -0500 Subject: Wiretap Act Does Not Cover Message 'in Storage' For Short Period (was Re: BNA's Internet Law News (ILN) - 2/27/03) In-Reply-To: <3E676CC0.1010809@monmouth.com> References: <20030305193054.18B187B4D@berkshire.research.att.com> <20030305193054.18B187B4D@berkshire.research.att.com> <20030305193054.18B187B4D@berkshire.research.att.com> <5.2.0.9.0.20030305221242.00a70e80@mail.comcast.net> Message-ID: <5.1.0.14.0.20030306134703.00ac25c0@mail.comcast.net> John says: >Next time, before disagreeing with someone: > a) Please read what he actually wrote, and > b) Don't quote snippets out of context. > >Three sentences later, at the end of the paragraph that >began as quoted above, I explicitly pointed out that > >>cellphone transmissions are a more-protected special case. Well, I did the first and, I thought, avoided the second. I misunderstood what you meant. Sorry. Will --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From warlord at MIT.EDU Thu Mar 6 13:50:44 2003 From: warlord at MIT.EDU (Derek Atkins) Date: 06 Mar 2003 13:50:44 -0500 Subject: Delta CAPPS-2 watch: decrypt boarding passes! In-Reply-To: <200303060819.h268JYB28653@new.toad.com> References: <200303060819.h268JYB28653@new.toad.com> Message-ID: John, John Gilmore writes: > And, besides identifying what cities they're doing this in, we should > also start examining a collection of these boarding passes, looking > for the encrypted "let me through without searching me" information. > Or the "Don't let me fly" information. Then we can evaluate how easy > it would be to turn one into another. (Don't mistake a system that > claims to provide security for one that actually does.) When I flew on US-Airways out of BAL last year, they had a marking on the boarding pass that signified "search this person". If your boarding pass had the mark, you were searched as you tried to board. If it did not, then you were not searched. I'm flying United out to the IETF next week, so I'll gladly report my findings. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord at MIT.EDU PGP key available --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From egerck at nma.com Thu Mar 6 15:15:03 2003 From: egerck at nma.com (Ed Gerck) Date: Thu, 06 Mar 2003 12:15:03 -0800 Subject: Scientists question electronic voting References: Message-ID: <3E67AC47.3A054C5C@nma.com> bear wrote: > Let's face it, if somebody can *see* their vote, they can record it. Not necessarily. Current paper ballots do not offer you a way to record *your* vote. You may even photograph your ballot but there is no way to prove that *that* was the ballot you did cast. In the past, we had ballots with different collors for each party ;-) so people could see if you were voting Republican or Democrat, but this is no longer the case. > and if someone can record it, then systems for counterfeiting such a > record already exist and are already widely dispersed. It's easier than one may think to have a reliable proof, if you can photograph the ballot that you *did* cast (as in that proposal for printing a paper receipt with your vote choices) -- just wait out of the poll place and demand the film right there, or wait out of the poll place, hear the voter's voice right then and get the image sent by the cell phone before the voter leaves the poll booth. Cheers, Ed Gerck --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From egerck at nma.com Thu Mar 6 15:20:57 2003 From: egerck at nma.com (Ed Gerck) Date: Thu, 06 Mar 2003 12:20:57 -0800 Subject: Scientists question electronic voting References: <003601c2e3f8$736ea1e0$d0966395@p1038mobile> <3E677F38.C4002959@nma.com> <013601c2e408$d36e7ce0$c71121c2@sharpuk.co.uk> Message-ID: <3E67ADA8.5FC171EB@nma.com> David Howe wrote: > at Thursday, March 06, 2003 5:02 PM, Ed Gerck was seen > to say: > > On the other hand, photographing a paper receipt behind a glass, which > > receipt is printed after your vote choices are final, is not readily > > deniable because that receipt is printed only after you confirm your > > choices. > as has been pointed out repeatedly - either you have some way to "bin" > the receipt and start over, or it is worthless (and merely confirms you > made a bad vote without giving you any opportunity to correct it) > That given, you could vote once for each party, take your photograph, > void the vote (and receipt) for each one, and then vote the way you > originally intended to :) No, as I commented before, voiding the vote in that proposal after the paper receipt is printed is a serious matter -- it means that either the machine made an error in recording the e-vote or (as it is oftentimes neglected) the machine made an error in printing the vote. The voter's final choice and legally binding confirmation is made before the printing. And that is where the problems reside (the problems that we were trying to solve in the first place), in that printed ballot. Plus the problem of the voter being able to photograph that final receipt and present it as direct proof of voting, as the voter leaves the poll place (with no chance for image processing) or by an immediate link by cell phone (ditto). Cheers, Ed Gerck --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From peter.kuhm at plus.at Thu Mar 6 15:25:11 2003 From: peter.kuhm at plus.at (Peter Kuhm) Date: Thu, 06 Mar 2003 21:25:11 +0100 Subject: 3-rotor enigma on ebay: $5200 In-Reply-To: References: Message-ID: <5.1.0.14.2.20030306211622.03b21530@mail.plus.at> At 12:17 06.03.03 -0500, Daniel Garcia wrote: >On Thu, 6 Mar 2003, Don Davis wrote: >> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=2162414185 >> i saw this on the boing-boing blog. > >Interesting, when i try to look at this from work (over in brighton, >actually), i get: > > Dear User: > > Unfortunately, access to this particular category or item has > been blocked due to legal restrictions in your home country. > Based on our discussions with concerned government agencies and > eBay community members, we have taken these steps to reduce the > chance of inappropriate items being displayed. Regrettably, in > some cases this policy may prevent users from accessing items > that do not violate the law. At this time, we are working on > less restrictive alternatives. Please accept our apologies for > any inconvenience this may cause you, and we hope you may find > other items of interest on eBay. > >But I can hit it from my dsl line at home (right up the road). > >I guess Verizon T1-land is restricted... it depends solely on the preferred language settings of your browser. When I had German on the first position it was blocked too. When I rearranged it below English I could view the page. cheers, Peter --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From egerck at nma.com Thu Mar 6 15:25:34 2003 From: egerck at nma.com (Ed Gerck) Date: Thu, 06 Mar 2003 12:25:34 -0800 Subject: multiple system - Re: Scientists question electronic voting References: Message-ID: <3E67AEBE.67388B75@nma.com> "Trei, Peter" wrote: > Ballot boxes are also subject to many forms of fraud. But a dual > system (electronic backed up by paper) is more resistant to > attack then either alone. The dual, and multiple, system can be done without paper ballot. There is nothing "magic" about paper as a record medium. I can send a link for a paper on this that was presented at the Tomales Bay conference on voting systems last year, using Shannon's Tenth Theorem as the theoretical background, introducing the idea of multiple "witnesses". If two witnesses are not 100% mutually dependent, the probability that both witnesses may fail at the same time is smaller than that of any single witness to fail. Cheers, Ed Gerck --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ji at research.att.com Thu Mar 6 15:34:41 2003 From: ji at research.att.com (John Ioannidis) Date: Thu, 6 Mar 2003 15:34:41 -0500 Subject: Delta CAPPS-2 watch: decrypt boarding passes! In-Reply-To: References: <200303060819.h268JYB28653@new.toad.com> Message-ID: <20030306203441.GB29411@bual.research.att.com> On Thu, Mar 06, 2003 at 01:50:44PM -0500, Derek Atkins wrote: > [...] > > When I flew on US-Airways out of BAL last year, they had a marking on > the boarding pass that signified "search this person". If your > boarding pass had the mark, you were searched as you tried to board. > If it did not, then you were not searched. > > [...] > > -derek Are you referring to the "SSSS" string on the boarding pass? That indicated that you were going to be searched by the boarding gate TSA people whether they were going to decide to search you or not (they still picked up "random" people without the search string on their boarding passess). Both JFK and SFO have stopped gate searches. Searches at security are still decided by the TSA personnel there (they don't get to see your boarding pass). LHR still has gate searches, and the mix of people they were searching looked fairly random. I don't know if any of them had been flagged by the computers, or if the gate security personnel had picked them out. I wasn't searched, either going through security or at the gate, but when I tried going from the gate area back into the duty-free area they were pretty thorough (but exceedingly polite). /ji - KC2IER -- /\ ASCII ribbon | John "JI" Ioannidis * Secure Systems Research Department \/ campaign | AT&T Labs - Research * Florham Park, NJ 07932 * USA /\ against | "Intellectuals trying to out-intellectual / \ HTML email. | other intellectuals" (Fritz the Cat) --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From warlord at MIT.EDU Thu Mar 6 15:44:17 2003 From: warlord at MIT.EDU (Derek Atkins) Date: 06 Mar 2003 15:44:17 -0500 Subject: Delta CAPPS-2 watch: decrypt boarding passes! In-Reply-To: <20030306203441.GB29411@bual.research.att.com> References: <200303060819.h268JYB28653@new.toad.com> <20030306203441.GB29411@bual.research.att.com> Message-ID: John Ioannidis writes: > Are you referring to the "SSSS" string on the boarding pass? That > indicated that you were going to be searched by the boarding gate TSA > people whether they were going to decide to search you or not (they > still picked up "random" people without the search string on their > boarding passess). Yes, that's what I was referring to. I didn't recall exactly what the mark was, but "SSSS" sounds right. I was just annoyed because they flagged about 30% of the flight. Even though I was seated in like row 15/22 (in the second group to get boarded), by the time I actually made it through the line they had already finished normal boarding and closed the gate doors. > Both JFK and SFO have stopped gate searches. Searches at security are > still decided by the TSA personnel there (they don't get to see your > boarding pass). Hmm. Well, I'll let you know about BOS. And I'll find out about ORD on my return flight. I consider gate checks rather rude, but then again I consider commercial travel in general rather annoying. If it weren't going to take me 3 days (rather than 6 hours) I would have just flown myself out to SF.... -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord at MIT.EDU PGP key available --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From rah at shipwright.com Thu Mar 6 15:22:46 2003 From: rah at shipwright.com (R. A. Hettinga) Date: Thu, 6 Mar 2003 15:22:46 -0500 Subject: Changes may follow Yale hoax e-mail Message-ID: http://www.yaledailynews.com/articlefunctions/Printerfriendly.asp?AID=22111 yaledailynews.com - Changes may follow hoax e-mail Published Wednesday, March 5, 2003 Changes may follow hoax e-mail BY JESSAMYN BLAU Staff Reporter The Feb. 17 hoax e-mail that caused some students to miss classes and angered the administration could now lead to changes in Information Technology Services policy. The e-mail -- allegedly sent by Yale Provost Susan Hockfield -- informed undergraduates that classes had been cancelled because of inclement weather. Approximately one and a half hours later, University Secretary Linda Lorimer sent out an e-mail informing students that the first e-mail was a hoax. In order to prevent a similar situation in the future, ITS Director Philip Long said ITS is considering adding a link in all official e-mails to a protected Yale Web site that would display copies of the original message, creating a back-up security measure. Long said the hoax situation has been investigated, but that he could not comment on any recent developments that could lead to disciplinary action. While ITS is currently contemplating ways to reduce the impact of potential hoaxes, Long said there is no real way to prevent someone from sending such an e-mail. "Anyone can dump an e-mail into a system," Long said. "That doesn't make it an honest e-mail." But Long said because University officials send out so many e-mails, it is not clear whether all of them would have to be logged in a protected Yale Web site. Alexander Clark '04, founder of YaleStation.org, said using a Web site might not be entirely convenient. "That certainly is one option, except that students might not go to the trouble of clicking on the URL," Clark said. Clark also said posting e-mails on the Internet could potentially make the e-mail accessible to unintended recipients. Instead of using a Web site, Clark said the use of digital certificates could be a more useful way of "making official e-mails look more official." "When you receive a certificate -- which is very difficult to forge -- an e-mail client is going to tell you whether it is a valid certificate," Clark said. In the hoax e-mail, the address in the "Reply-to" field was mary.zihal at yale.edu. Long said he has spoken with Zihal, a draper in the School of Drama's costume shop, and determined that she is an innocent victim. Long said the e-mail was a violation of a number of ITS policies because it impersonated Hockfield, victimized Zihal and caused annoyance and inconvenience to members of the Yale community. "I think that most people are not looking for cheap thrills at the expense of the community," Long said. "Bottom line, this is a question of trust. It might have more consequences than the person who casually initiated it had intended." Long said there is a law in Connecticut about the use of electronic communication for deceptive purposes, but said he is not sure whether this particular abuse could be prosecuted. -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From kivinen at iki.fi Thu Mar 6 16:40:05 2003 From: kivinen at iki.fi (Tero Kivinen) Date: Thu, 6 Mar 2003 23:40:05 +0200 Subject: Proven Primes In-Reply-To: <3E673549.9040309@algroup.co.uk> References: <3E673549.9040309@algroup.co.uk> Message-ID: <15975.49205.28259.209816@fireball.acr.fi> Ben Laurie writes: > I'm looking for a list or lists of sensibly sized proven primes - all > the lists I can find are more interested in records, which are _way_ too > big for cryptographic purposes. Directory ftp://ftp.ssh.com/pub/ietf/ecpp-certificates contains ecpp certificates for IKE primes (768, 1024, 1536, 2048, 3072, 4096, 6144, 8192 bit Diffie-Hellman groups), i.e proven Sophie-Germain primes. The ikeprime-xxxx.txt is the prime itself and the ikeprime-xxx{,-primo}-certificate.txt is the certificate for it. I used two different programs to prove those primes primo and ecpp. The primo was faster, thus bigger groups are only proven by that. There is also certificates for (p - 1) / 2, but those are mostly redundant as most certificates starts with N-1 test, which will actually proves the (p - 1) / 2 also. > By "sensibly sized" I mean in the range 512-8192 bits. I'm particularly > after Sophie Germain primes right now, but I guess all primes are of > interest. -- kivinen at ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ck at kuckuk.com Thu Mar 6 17:58:50 2003 From: ck at kuckuk.com (Carsten Kuckuk) Date: Thu, 6 Mar 2003 23:58:50 +0100 Subject: 3-rotor enigma on ebay: $5200 In-Reply-To: References: Message-ID: <1223121658.20030306235850@kuckuk.com> DG> On Thu, 6 Mar 2003, Don Davis wrote: >> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=2162414185 >> i saw this on the boing-boing blog. Blocked for German T-Online customers, too. -- Best regards, Carsten mailto:ck at kuckuk.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From dsr at mail.lns.cornell.edu Thu Mar 6 20:38:42 2003 From: dsr at mail.lns.cornell.edu (Dan Riley) Date: 06 Mar 2003 20:38:42 -0500 Subject: Scientists question electronic voting In-Reply-To: <3E677F38.C4002959@nma.com> References: <003601c2e3f8$736ea1e0$d0966395@p1038mobile> <3E677F38.C4002959@nma.com> Message-ID: Ed Gerck writes: > This is not possible for current paper ballots, for several reasons. For > example, if you take a picture of your punch card as a proof of how you > voted, what is to prevent you -- after the picture is taken -- to punch > another hole for the same race and invalidate your vote? [...] > On the other hand, photographing a paper receipt behind a glass, > which receipt is printed after your vote choices are final, is not > readily deniable because that receipt is printed only after you > confirm your choices. The vote can't be final until the voter confirms the paper receipt. It's inevitable that some voters won't realize they voted the wrong way until seeing the printed receipt, so that has to be allowed for. Elementary human factors. But this whole discussion is terribly last century--still pictures are passe. What's the defense of any of these systems against cell phones that transmit live video? -dan --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From frantz at pwpconsult.com Thu Mar 6 20:58:18 2003 From: frantz at pwpconsult.com (Bill Frantz) Date: Thu, 6 Mar 2003 17:58:18 -0800 Subject: Proven Primes In-Reply-To: <3E673549.9040309@algroup.co.uk> Message-ID: At 3:47 AM -0800 3/6/03, Ben Laurie wrote: >I'm looking for a list or lists of sensibly sized proven primes - all >the lists I can find are more interested in records, which are _way_ too >big for cryptographic purposes. > >By "sensibly sized" I mean in the range 512-8192 bits. I'm particularly >after Sophie Germain primes right now, but I guess all primes are of >interest. Having set a computer to the problem of coming up with a Sophie Germain prime for the E startup protocol (Diffie-Hellman), I offer you: static final BigInteger g = new BigInteger("2"); static final BigInteger modulus = new BigInteger("11973791477546250983817043765044391637751157152328012" + "72278994477192940843207042535379780702841268263028" + "59486033998465467188646855777933154987304015680716" + "74391647223805124273032053960564348124852668624831" + "01273341734490560148744399254916528366159159380290" + "29782321539388697349613396698017627677439533107752" + "978203"); Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | Due process for all | Periwinkle -- Consulting (408)356-8506 | used to be the | 16345 Englewood Ave. frantz at pwpconsult.com | American way. | Los Gatos, CA 95032, USA --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From frantz at pwpconsult.com Thu Mar 6 21:09:53 2003 From: frantz at pwpconsult.com (Bill Frantz) Date: Thu, 6 Mar 2003 18:09:53 -0800 Subject: 3-rotor enigma on ebay: $5200 In-Reply-To: References: Message-ID: At 9:17 AM -0800 3/6/03, Daniel Garcia wrote: >On Thu, 6 Mar 2003, Don Davis wrote: >> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=2162414185 >> i saw this on the boing-boing blog. > >Interesting, when i try to look at this from work (over in brighton, >actually), i get: > > Dear User: > > Unfortunately, access to this particular category or item has > been blocked due to legal restrictions in your home country. > Based on our discussions with concerned government agencies and > eBay community members, we have taken these steps to reduce the > chance of inappropriate items being displayed. Regrettably, in > some cases this policy may prevent users from accessing items > that do not violate the law. At this time, we are working on > less restrictive alternatives. Please accept our apologies for > any inconvenience this may cause you, and we hope you may find > other items of interest on eBay. > >But I can hit it from my dsl line at home (right up the road). > >I guess Verizon T1-land is restricted... I got that on my Safari beta browser. (Safari is Apple's new browser.) On the same machine with the same IP address I got the page using Netscape 4.77. There seems to be some strangeness with eBay. (I looked for a way to report the problem, but lost interest after shuffling through a few of their web pages.) Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | Due process for all | Periwinkle -- Consulting (408)356-8506 | used to be the | 16345 Englewood Ave. frantz at pwpconsult.com | American way. | Los Gatos, CA 95032, USA --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From egerck at nma.com Thu Mar 6 21:17:29 2003 From: egerck at nma.com (Ed Gerck) Date: Thu, 06 Mar 2003 18:17:29 -0800 Subject: Scientists question electronic voting References: <003601c2e3f8$736ea1e0$d0966395@p1038mobile> <3E677F38.C4002959@nma.com> Message-ID: <3E680139.5B438AFC@nma.com> Dan Riley wrote: > The vote can't be final until the voter confirms the paper receipt. > It's inevitable that some voters won't realize they voted the wrong > way until seeing the printed receipt, so that has to be allowed for. > Elementary human factors. This brings in two other factors I have against this idea: - a user should not be called upon to distrust the system that the user is trusting in the first place. - too many users may reject the paper receipt because they changed their minds, making it impossible to say whether the e-vote was wrong or correct based on the number of rejected e-votes. > But this whole discussion is terribly last century--still pictures are > passe. What's the defense of any of these systems against cell phones > that transmit live video? This was in my first message, and some subsequent ones too: "For example, using the proposed system a voter can easily, by using a small concealed camera or a cell phone with a camera, obtain a copy of that receipt and use it to get money for the vote, or keep the job. And no one would know or be able to trace it." Cheers, Ed Gerck --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From barney at pit.databus.com Thu Mar 6 22:35:22 2003 From: barney at pit.databus.com (Barney Wolff) Date: Thu, 6 Mar 2003 22:35:22 -0500 Subject: Scientists question electronic voting In-Reply-To: References: <003601c2e3f8$736ea1e0$d0966395@p1038mobile> <3E677F38.C4002959@nma.com> Message-ID: <20030307033522.GA47904@pit.databus.com> On Thu, Mar 06, 2003 at 08:38:42PM -0500, Dan Riley wrote: > > But this whole discussion is terribly last century--still pictures are > passe. What's the defense of any of these systems against cell phones > that transmit live video? A Faraday cage. Seriously, what current or historic voting system would defend against these risks? We certainly don't want an electronic system that is more vulnerable than existing systems, but sticking with known-to-be-terrible systems is not a sensible choice either. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From njohnsn at njohnsn.com Thu Mar 6 22:38:01 2003 From: njohnsn at njohnsn.com (Neil Johnson) Date: Thu, 6 Mar 2003 21:38:01 -0600 Subject: double shot of snake oil, good conclusion In-Reply-To: <3E678791.A7131CFF@nma.com> References: <0c248779bfc3c36c1d9db576541fbf48@melontraffickers.com> <20030306011515.GB7313@stanford.edu> <3E678791.A7131CFF@nma.com> Message-ID: <200303062138.01369.njohnsn@njohnsn.com> Lotus Notes/Domino already has something similar to what Microsoft is proposing. You can designate an outgoing message as "read-only". The end-user (if they are using a Notes Client) can only view the message, menu choices for printing and cutting/copy text are disabled. Forwarding the message is also disabled. Note you can still use a screen grabber to grab the image off the screen... Leave to Microsoft to claim it's a "new" idea. (Although, after using Notes/Domino for over a year, I heartily agree with Peter Guttman's assessment of it, and would definitely switch back to Outlook/Exchange if given the choice between the two. POP/IMAP would be even better). -- Neil Johnson http://www.njohnsn.com PGP key available on request. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From kelsey.j at ix.netcom.com Thu Mar 6 16:53:24 2003 From: kelsey.j at ix.netcom.com (John Kelsey) Date: Thu, 06 Mar 2003 16:53:24 -0500 Subject: Scientists question electronic voting In-Reply-To: <000001c2e389$ab2b94e0$6601a8c0@happy> References: <3E63FF95.708674AF@nma.com> Message-ID: <5.2.0.9.0.20030306162648.01d3ae40@pop.ix.netcom.com> At 02:39 AM 3/6/03 +0000, Ian Brown wrote: >Ed Gerck wrote: ... > > For example, using the proposed system a voter can easily, by > > using a small concealed camera or a cell phone with a camera, > > obtain a copy of that receipt and use it to get money for the > > vote, or keep the job. And no one would know or be able to trace it. > >As a voter could record what they did with pencil-and-paper or a >mechanical voting machine. The big theoretical question is whether you could tell whether the vote-seller was faking it. A design goal ought to be to make plausible fake proofs of how you voted easy to generate, IMO. Why only sell your vote to one side, when you can sell it to both sides multiple times? In practice, if it's more trouble to generate fakes than to just vote and bring the proof to sell, then the individual vote seller will probably just vote as he's told. After all, most people eligible to vote don't bother most of the time; presumably, they just don't care that much who wins the next election. I assume most people who sell their votes aren't committed ideologues who are selling out their cause, but rather people who didn't much care either way. (But surely someone, somewhere has real data on this.) --John Kelsey, kelsey.j at ix.netcom.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ben at algroup.co.uk Fri Mar 7 00:21:35 2003 From: ben at algroup.co.uk (Ben Laurie) Date: Fri, 07 Mar 2003 05:21:35 +0000 Subject: Proven Primes In-Reply-To: References: Message-ID: <3E682C5F.6030702@algroup.co.uk> Bill Frantz wrote: > At 3:47 AM -0800 3/6/03, Ben Laurie wrote: > >>I'm looking for a list or lists of sensibly sized proven primes - all >>the lists I can find are more interested in records, which are _way_ too >>big for cryptographic purposes. >> >>By "sensibly sized" I mean in the range 512-8192 bits. I'm particularly >>after Sophie Germain primes right now, but I guess all primes are of >>interest. > > > Having set a computer to the problem of coming up with a Sophie Germain > prime for the E startup protocol (Diffie-Hellman), I offer you: > > static final BigInteger g = new BigInteger("2"); > static final BigInteger modulus = > new BigInteger("11973791477546250983817043765044391637751157152328012" > + "72278994477192940843207042535379780702841268263028" > + "59486033998465467188646855777933154987304015680716" > + "74391647223805124273032053960564348124852668624831" > + "01273341734490560148744399254916528366159159380290" > + "29782321539388697349613396698017627677439533107752" > + "978203"); And the proof? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From adam at homeport.org Fri Mar 7 00:28:16 2003 From: adam at homeport.org (Adam Shostack) Date: Fri, 7 Mar 2003 00:28:16 -0500 Subject: Scientists question electronic voting In-Reply-To: <20030307033522.GA47904@pit.databus.com> References: <003601c2e3f8$736ea1e0$d0966395@p1038mobile> <3E677F38.C4002959@nma.com> <20030307033522.GA47904@pit.databus.com> Message-ID: <20030307052815.GA74449@lightship.internal.homeport.org> On Thu, Mar 06, 2003 at 10:35:22PM -0500, Barney Wolff wrote: | On Thu, Mar 06, 2003 at 08:38:42PM -0500, Dan Riley wrote: | > | > But this whole discussion is terribly last century--still pictures are | > passe. What's the defense of any of these systems against cell phones | > that transmit live video? | | A Faraday cage. | | Seriously, what current or historic voting system would defend against | these risks? We certainly don't want an electronic system that is more | vulnerable than existing systems, but sticking with known-to-be-terrible | systems is not a sensible choice either. Break the trust of the vote buyers and sellers by making confirmation hard. Pictures in the booth of party line ballots that you can draw over the screen would be very hard to distinguish from the real thing over a cell-phone quality video picture. Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From kelsey.j at ix.netcom.com Fri Mar 7 00:52:24 2003 From: kelsey.j at ix.netcom.com (John Kelsey) Date: Fri, 07 Mar 2003 00:52:24 -0500 Subject: multiple system - Re: Scientists question electronic voting In-Reply-To: <3E67AEBE.67388B75@nma.com> References: Message-ID: <5.2.0.9.0.20030307004639.01d4f0f0@pop.ix.netcom.com> At 12:25 PM 3/6/03 -0800, Ed Gerck wrote: >"Trei, Peter" wrote: > > Ballot boxes are also subject to many forms of fraud. But a dual > > system (electronic backed up by paper) is more resistant to > > attack then either alone. > >The dual, and multiple, system can be done without paper ballot. >There is nothing "magic" about paper as a record medium. I think one benefit of using paper ballots as the backup is that there are already pretty well-understood ways to deal with paper ballots. I like the idea of the election observers having at least one piece of the technology they really understand. >I >can send a link for a paper on this that was presented at the >Tomales Bay conference on voting systems last year, using Shannon's >Tenth Theorem as the theoretical background, introducing the idea >of multiple "witnesses". If two witnesses are not 100% mutually >dependent, the probability that both witnesses may fail at the same >time is smaller than that of any single witness to fail. Is the relevant question here about probabilistic failures, or about conspiracies? Clearly, the size and cost of the conspiracy gets much bigger if there's a check value on the election results that is handled completely outside the voting machine. >Cheers, >Ed Gerck --John Kelsey, kelsey.j at ix.netcom.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From kelsey.j at ix.netcom.com Fri Mar 7 01:00:25 2003 From: kelsey.j at ix.netcom.com (John Kelsey) Date: Fri, 07 Mar 2003 01:00:25 -0500 Subject: Scientists question electronic voting In-Reply-To: <20030307033522.GA47904@pit.databus.com> References: <003601c2e3f8$736ea1e0$d0966395@p1038mobile> <3E677F38.C4002959@nma.com> Message-ID: <5.2.0.9.0.20030307005338.01d4d5e0@pop.ix.netcom.com> At 10:35 PM 3/6/03 -0500, Barney Wolff wrote: >On Thu, Mar 06, 2003 at 08:38:42PM -0500, Dan Riley wrote: > > > > But this whole discussion is terribly last century--still pictures are > > passe. What's the defense of any of these systems against cell phones > > that transmit live video? > >A Faraday cage. > >Seriously, what current or historic voting system would defend against >these risks? We certainly don't want an electronic system that is more >vulnerable than existing systems, but sticking with known-to-be-terrible >systems is not a sensible choice either. I think the real defense against vote-buying or vote-extortion schemes is external--detecting any such scheme that has much of an impact because it necessarily involves hundreds or thousands of people. This assumes that the authorities and media aren't totally corrupted, but so does any voting technology. With a lot of the more elaborate technological attacks, though, it's hard to see an attacker with current technology being able to afford them. >Barney Wolff http://www.databus.com/bwresume.pdf --John Kelsey, kelsey.j at ix.netcom.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From lrkn at earthlink.net Fri Mar 7 01:50:44 2003 From: lrkn at earthlink.net ((Mr) Lyn R. Kennedy) Date: Fri, 7 Mar 2003 00:50:44 -0600 Subject: Scientists question electronic voting In-Reply-To: <20030307033522.GA47904@pit.databus.com> References: <003601c2e3f8$736ea1e0$d0966395@p1038mobile> <3E677F38.C4002959@nma.com> <20030307033522.GA47904@pit.databus.com> Message-ID: <20030307065044.GD273@workstn.my.domain> On Thu, Mar 06, 2003 at 10:35:22PM -0500, Barney Wolff wrote: > > We certainly don't want an electronic system that is more > vulnerable than existing systems, but sticking with known-to-be-terrible > systems is not a sensible choice either. Paper ballots, folded, and dropped into a large transparent box, is not a broken system. It's voting machines, punch cards, etc that are broken. I don't recall seeing news pictures of an election in any other western democracy where they used machines. And the Florida election was apparently affected more by eligible voters turned away from the polls than by votes sold. Maybe crypto, smart-cards, biometrics, etc would help authenticate voter eligibility and enforce one vote per live voter (zero per dead voter). -- ------------------------------------------------------------------------- | 73, E-mail | lrkn at earthlink.net | | Lyn Kennedy webpage | http://home.earthlink.net/~lrkn | | K5QWB ICBM | 32.5 North 96.9 West | ---Livin' on an information dirt road a few miles off the superhighway--- --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From josh-crypto at untruth.org Fri Mar 7 02:12:23 2003 From: josh-crypto at untruth.org (Joshua Hill) Date: Thu, 6 Mar 2003 23:12:23 -0800 Subject: Comments/summary on unicity discussion In-Reply-To: <3E63C916.31E993CC@nma.com>; from egerck@nma.com on Mon, Mar 03, 2003 at 01:28:54PM -0800 References: <3E63C916.31E993CC@nma.com> Message-ID: <20030306231223.A20908@delusion.private.untruth.org> I'll hop in here, and see if I can give this a swing. IANAC (I am not a cryptographer), but I do have access to one at work, and I did make use of him in gaining an understanding of this area. Some of these points are minutia, but are important, both because they are common errors, and because they really help bring everything together. In general, it appears that you mixed up your labels in the reference list. [Sha49] is, indeed, the reference that you want, but that paper should be listed as "Communication Theory of Secrecy Systems" (published in 1949) On Mon, Mar 03, 2003 at 01:28:54PM -0800, Ed Gerck wrote: > 1. WHAT IS UNICITY? > There are three different contexts to answer to this question! > > 1.a. Unicity Definition: Shannon [Sha49, page 693] defined "unicity > distance" (hereafter, "n") as the least amount of plaintext which can be > uniquely deciphered from the corresponding ciphertext, allowing one to > determine, without doubt, the key that was used for encryption. It doesn't deal with plaintext, just ciphertext. In fact, unicity distance is only valid for a ciphertext only attack. Once you get a known plaintext/ciphertext pair, a high unicity distance works against you (more on this later). In addition, it is isn't certain that after observing the requisite unicity distance number of ciphertext units that you can uniquely determine the key, it is merely very likely. So, the definition should be something more like: 1.a. Unicity Definition: Shannon [Sha49, page 693] defined "unicity distance" (hereafter, "n") as the least amount of ciphertext which would reduce the likely number of spurious keys ("equivocations") in a random cipher to zero. > 1.b. Unicity Model: As first given by Shannon [Sha49] under some restrictive > assumptions, specially the "random cipher" assumption, the mathematical > expression for unicity can be cast in the following unfolded expression > (his original expression was n = H(K)/D, where D is the redundancy): > > n = H(K)/[|M| - H(M)] I don't see this. I do see D_N = log(G) - H(M) Where D_N is the redundancy of the language, G is the total number of messages in the language, and H(M) is the entropy of a message of the language. Shannon uses log base 10, but we like to talk about 'bits' of entropy in crypto, so we tend to talk about log base 2 (often written lg x) D = D_N / N Where D is the redundancy the per unit (character/bit/whatever), D_N is the redundancy of the language, and N is the average number of units per message. And finally, the unicity distance is: n = H(K) / D Where n is the unicity distance (expressed in units), H(K) is the amount of entropy of a key (also in units) for the system, and D is the redundancy per unit. So, pulling it together n = H(K) * N / (lg(G) - H(M)) (so, it would appear that your equation was off by a factor of the average length of the message) But truly, I think that it makes the most sense as just n = H(K) / D As an aside, you define: > H(K) = entropy of keys used in encryption [...] > H(M) = entropy of actual message, the plaintext This seems to imply that a particular message has entropy. This is incorrect. A random variable has entropy ('variable' in mathspeak, not 'variable' in the sense of programming, which has an actual value as the program is executing; this is a "random variable" as in X, where X assumes the following values x_1, x_2, ... x_n with probability p_1, p_2, ...p_n) , based on the statistical properties of the variable. A particular value doesn't really have 'entropy', outside the context of the system that created the value. Now, having said that, strings (values, messages, etc.) do have something called "Kolmogorov Complexity". Kolmogorov Complexity is the size of the smallest program that can produce a particular string. For a string, the highest Kolmogorov Complexity it can have is the size of the string. The lowest would be a very small program that produces a very large string. As you might expect, entropy and Kolmogorov Complexity are related. You would expect a message from a high entropy system to have a high Kolmogorov Complexity (in fact, the Kolmogorov Complexity should be comparable to the entropy of the system). Further, you get some intuitively nice results where the Kolmogorov Complexity of any output of a PRNG is at most the size of the PRNG state, plus a bit for the PRNG algorithm, which agrees nicely with the entropy of the system, which is (at best) size of the PRNG state. > NOTE 1: The model for unicity has no probability error with a tail > to infinity because only entropy values are used in the formula of n > and by *definition* of entropy the entropy is already a limit to > infinity. I don't understand what this note means. > NOTE 2: It does not matter how the attacker may try to decipher > the message. The attacker can of course use brute-force and try > out all keys or he can use short-cuts, it is his choice and he is entirely > free to use any method he desires. The work involved may be small, > quite large or even unbounded -- the amount of work is actually > unspecified. Hmm... This is true, but it seems to miss the point that the entire idea behind unicity distance (and, indeed, all of information theory) is that the attacker has unbounded resources. "Brute force" isn't so much an issue, when you get to assume that your attacker has an infinite amount of computational power at his disposal... > NOTE 3: Shannon's definition of "random cipher" was that "all > decipherments must produce a random flat distribution over all > bits in the plaintext space." Shannon's "Random Cipher" is a simple substitution cipher. > 1.c. Unicity Value: The numerical value of n. It is important not to > confuse a model with a measurement. This is a strange distinction to make, given that one of the assumptions that information theory makes is that both sides of an exchange have infinite computational resources, which isn't something that is ever going to occur in practice. I guess I'm just pointing out that really, unicity distance, information entropy, and all that other great stuff is all just a neat conceptual framework that establishes the "worst case" in cryptography. > First, note that the model works for any ciphertext, any plaintext. > And for any such pairs Hmm... Once again, unicity distance is only directly applicable to a ciphertext only attack. In an information theoretic model there is a trade off between resistance to ciphertext only attacks and resistance to known plaintext attacks. If a system had a high redundancy (i.e., the system's messages were low entropy as compared to the entropy of the key), you would likely have many keys that produced a given ciphertext/plaintext pair, so you would need more plaintext/ciphertext message pairs before you could uniquely specify a key. (You should, on average, be able to uniquely specify the key after you have gathered the entropy of the key in message entropy. So, if you redundancy is low, your system is more secure against ciphertext only attacks (the attacker must gather a great deal of ciphertext before they can uniquely determine the key), but insecure against known plaintext attacks (the attacker doesn't need very much known plaintext before they can uniquely determine the key). Conversely, if the redundancy is high, your system is insecure against known ciphertext attacks, but more secure against known plaintext attacks. > Since all good > ciphers should be a random cipher Well, good ciphers should have many of the same properties as a random cipher, but is isn't one. > NOTE 2: The benefit of compression is to increase unicity even > if the compression algorithm is fully known to the attacker. If the > plaintext is compressed before encipherment, then we rightly > expect its entropy per compressed character to increase -- even > though its entropy per English character does not increase. This > is often confusing and may provide the wrong impressions that > nothing is gained by compression or that we may need to "hide" > the compression algorithm from the attacker. Yes, compression increases unicity distance for a cipher (but makes is more susceptible to known plaintext attack). From a security perspective, it also makes the system more complex, which is a security problem in of itself. Further, as pointed out by John Kelsey in a 'crypto rump session (2001, perhaps?) the compression state is, itself, a critical security parameter, and can be used by an attacker to divine quite a lot of information about the previously sent plaintext... > 2. READING THE FINE PRINT > Of further importance and often ignored or even contradicted by > some statements in the literature such as "any cipher can be attacked by > exhaustively trying all possible keys", I usually like to call attention to > the fact that any cipher (including 56-bit-key DES) can be theoretically > secure against any attacker -- even an attacker with unbounded > resources -- when the cipher is used within its unicity. Not only the > One-Time Pad is theoretically secure, but any cipher can be theoretically > secure if used within the unicity distance. Thus, indeed there is a > theoretically secure defense even against brute-force attacks, which is to > work within the unicity limit of the cipher. And, it works for any cipher > that is a good random cipher -- irrespective of key-length or encryption > method used. This ignores the idea that you have to assume that the attacker has only ciphertext, which is an abysmally non-paranoid way of modeling the security of the system. > It is also important to note, as the literature has also not been very neat > in this regard, that unicity is always referred to the plaintext. I believe that this is incorrect. Comments and discussions are, of course, welcome... Josh --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From barney at pit.databus.com Fri Mar 7 02:22:23 2003 From: barney at pit.databus.com (Barney Wolff) Date: Fri, 7 Mar 2003 02:22:23 -0500 Subject: Scientists question electronic voting In-Reply-To: <20030307065044.GD273@workstn.my.domain> References: <003601c2e3f8$736ea1e0$d0966395@p1038mobile> <3E677F38.C4002959@nma.com> <20030307033522.GA47904@pit.databus.com> <20030307065044.GD273@workstn.my.domain> Message-ID: <20030307072223.GA49740@pit.databus.com> On Fri, Mar 07, 2003 at 12:50:44AM -0600, (Mr) Lyn R. Kennedy wrote: > > Paper ballots, folded, and dropped into a large transparent box, is not a > broken system. It's voting machines, punch cards, etc that are broken. > I don't recall seeing news pictures of an election in any other western > democracy where they used machines. Surely you jest - where else did the term ballot-stuffing come from? The key, imho, is >=2 independent means of counting the votes. Online, as each vote is cast, and a paper trail, for later reconciliation. It's hard for both to be skewed by the same amount, and differences will both raise suspicion and give an order of magnitude of the fraud. That seems to be the direction the experts are heading. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From frantz at pwpconsult.com Fri Mar 7 02:57:35 2003 From: frantz at pwpconsult.com (Bill Frantz) Date: Thu, 6 Mar 2003 23:57:35 -0800 Subject: Proven Primes In-Reply-To: <3E682C5F.6030702@algroup.co.uk> References: Message-ID: At 9:21 PM -0800 3/6/03, Ben Laurie wrote: >Bill Frantz wrote: >> At 3:47 AM -0800 3/6/03, Ben Laurie wrote: >> >>>I'm looking for a list or lists of sensibly sized proven primes - all >>>the lists I can find are more interested in records, which are _way_ too >>>big for cryptographic purposes. >>> >>>By "sensibly sized" I mean in the range 512-8192 bits. I'm particularly >>>after Sophie Germain primes right now, but I guess all primes are of >>>interest. >> >> >> Having set a computer to the problem of coming up with a Sophie Germain >> prime for the E startup protocol (Diffie-Hellman), I offer you: >> >> static final BigInteger g = new BigInteger("2"); >> static final BigInteger modulus = >> new >>BigInteger("11973791477546250983817043765044391637751157152328012" >> + >>"72278994477192940843207042535379780702841268263028" >> + >>"59486033998465467188646855777933154987304015680716" >> + >>"74391647223805124273032053960564348124852668624831" >> + >>"01273341734490560148744399254916528366159159380290" >> + >>"29782321539388697349613396698017627677439533107752" >> + "978203"); > >And the proof? Sorry, an exercise for the student. :-) I thought that finding them was the hard part, and verifying one once found was relatively easy. I used the probable prime test in the Java BigInteger package. It sounds like, from some of the list traffic, that there are better tests. I guess I'm dumb, but how to you verify a proof of Sophie Germain primeness with less effort than to run the tests yourself? Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | Due process for all | Periwinkle -- Consulting (408)356-8506 | used to be the | 16345 Englewood Ave. frantz at pwpconsult.com | American way. | Los Gatos, CA 95032, USA --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ben at algroup.co.uk Fri Mar 7 05:04:00 2003 From: ben at algroup.co.uk (Ben Laurie) Date: Fri, 07 Mar 2003 10:04:00 +0000 Subject: Proven Primes In-Reply-To: References: Message-ID: <3E686E90.1000500@algroup.co.uk> Bill Frantz wrote: > At 9:21 PM -0800 3/6/03, Ben Laurie wrote: > >>Bill Frantz wrote: >> >>>At 3:47 AM -0800 3/6/03, Ben Laurie wrote: >>> >>> >>>>I'm looking for a list or lists of sensibly sized proven primes - all >>>>the lists I can find are more interested in records, which are _way_ too >>>>big for cryptographic purposes. >>>> >>>>By "sensibly sized" I mean in the range 512-8192 bits. I'm particularly >>>>after Sophie Germain primes right now, but I guess all primes are of >>>>interest. >>> >>> >>>Having set a computer to the problem of coming up with a Sophie Germain >>>prime for the E startup protocol (Diffie-Hellman), I offer you: >>> >>> static final BigInteger g = new BigInteger("2"); >>> static final BigInteger modulus = >>> new >>>BigInteger("11973791477546250983817043765044391637751157152328012" >>> + >>>"72278994477192940843207042535379780702841268263028" >>> + >>>"59486033998465467188646855777933154987304015680716" >>> + >>>"74391647223805124273032053960564348124852668624831" >>> + >>>"01273341734490560148744399254916528366159159380290" >>> + >>>"29782321539388697349613396698017627677439533107752" >>> + "978203"); >> >>And the proof? > > > Sorry, an exercise for the student. :-) > > I thought that finding them was the hard part, and verifying one once found > was relatively easy. I used the probable prime test in the Java BigInteger > package. It sounds like, from some of the list traffic, that there are > better tests. Indeed. The commonly used one is ECPP which uses elliptic curves cunningly to not only prove primality, but to produce a certificate which can be quickly verified. Probabilistic prime tests are just that - probable. ECPP actually proves it. > I guess I'm dumb, but how to you verify a proof of Sophie Germain primeness > with less effort than to run the tests yourself? Running the probabalistic tests can only prove that it's composite - they can never prove primality. BTW, a terminology nit - a Sophie Germain prime is one such that p and 2p+1 are prime - I'll be that what you've given me is one such that p and (p-1)/2 are prime, right? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From roy at scytale.com Thu Mar 6 19:02:09 2003 From: roy at scytale.com (Roy M. Silvernail) Date: Thu, 6 Mar 2003 18:02:09 -0600 Subject: Delta CAPPS-2 watch: decrypt boarding passes! In-Reply-To: <20030306203441.GB29411@bual.research.att.com> References: <200303060819.h268JYB28653@new.toad.com> <20030306203441.GB29411@bual.research.att.com> Message-ID: <200303071153.h27BrDK30875@bunkhouse.propagation.net> On Thursday 06 March 2003 02:34 pm, John Ioannidis wrote: > Both JFK and SFO have stopped gate searches. Searches at security are > still decided by the TSA personnel there (they don't get to see your > boarding pass). FWIW, MSP initial security screening wants to see your boarding pass. I didn't see anyone try to avoid showing it. The last time I was through SFO, this new jihad hadn't started, but I got yet another lesson in the lack of sense of humor among the staff. Asked to take my creaky old ThinkPad 760XL out of its case to be x-rayed, I said "Be nice to it; it's old." Whereupon I was invited out of line so the explosives residue screener could give it a wipedown. Even so, it was better than the beginning of that trip, when I'd forgotten to take my Victorinox Signature off of my keychain. (that's a 1.6" Swiss Army Knife with a pen, an LED flashlight and a 1.25" blade) At least I was given the opportunity to FedEx it back to the office. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From astiglic at okiok.com Fri Mar 7 10:00:28 2003 From: astiglic at okiok.com (Anton Stiglic) Date: Fri, 7 Mar 2003 10:00:28 -0500 Subject: Scientists question electronic voting References: <003601c2e3f8$736ea1e0$d0966395@p1038mobile> <3E677F38.C4002959@nma.com> <3E680139.5B438AFC@nma.com> Message-ID: <001c01c2e4ba$4d41c0c0$46976395@p1038mobile> ----- Original Message ----- From: "Ed Gerck" [...] > "For example, using the proposed system a voter can easily, by using a > small concealed camera or a cell phone with a camera, obtain a copy of > that receipt and use it to get money for the vote, or keep the job. And > no one would know or be able to trace it." But that brings up my point once again: These problems already exist with current paper-ballot voting schemes, what exactly are you trying to achieve with an electronic voting scheme? To you simply want to make the counting of the votes more reliable, and maintain the security of all other aspects, or improve absolutely everything? --Anton --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From rah at shipwright.com Fri Mar 7 09:53:44 2003 From: rah at shipwright.com (R. A. Hettinga) Date: Fri, 7 Mar 2003 09:53:44 -0500 Subject: Harnessing Atoms to Create Superfast Computers Message-ID: http://www.nytimes.com/2003/03/07/books/07BOOK.html?th=&pagewanted=print&position=top March 7, 2003 Harnessing Atoms to Create Superfast Computers By IAN FOSTER A SHORTCUT THROUGH TIME The Path to the Quantum Computer By George Johnson. Illustrated. 204 pages. Knopf. $24. George Johnson's "Shortcut Through Time" addresses one of the most excruciatingly complex, mysterious and deeply fascinating topics in modern science, namely quantum computing: the manipulation of quantum states to perform computations far faster than is possible on any conventional computer. The book's remarkable achievement is that it makes this deeply arcane topic accessible and understandable - even, I think, for the reader unsophisticated in physics or computing. It opens a door to broader understanding of this important field and sets a new standard for science writing. I was originally reluctant to review this book. I am a computer scientist with a guilty secret: I've never really understood quantum computing. How could I write a review without revealing my ignorance? However, as I began the preface, I became intrigued and then excited. Mr. Johnson, a contributing science writer for The New York Times, says he wrote the book not to profile the personalities in the field, but to lead the reader toward a tentative understanding of quantum computing. To take the reader along as he, the writer, strains "to grasp an idea with an imprecise metaphor, only to discard it for another with a tighter fit, closing in on an airy notion from several directions, triangulating on approximate truth." And: "I want the reader to feel that we are both on the same side - outsiders seeking a foothold on the slippery granite face of a new idea." I was hooked. So much of what passes for science writing nowadays is really human-interest journalism, focused on the quirks and conflicts of science's eccentric personalities, and is only incidentally concerned with science itself. Yet here was someone who proposed to take a problem at the forefront of science and address it on its own terms. Perhaps my ignorance was a virtue: I could serve as an experimental subject, reading the book and reporting on whether I arrived at the promised land. Approached from this perspective, the book took on the allure of a good mystery. Mr. Johnson, like a seasoned crime writer, sets the scene and then introduces a series of increasingly intriguing metaphors, each of which unveils another aspect of Q.C., as I'll call it. As the story unfolds, it becomes clear that Q.C.'s secret could be revealed at the turn of any page. For me, the initial forays covered familiar ground. But Mr. Johnson soon entered unfamiliar territory, exploring the mysteries of superposition and entanglement. Along the way, we discover that we are dealing not with an obscure and eccentric academic curiosity, but with a dangerous character. (In addition to mystery, we have drama!) Q.C., it has been shown in the last few years, could defeat some of the fundamental codes that secure many electronic communications. The security of these public key cryptography mechanisms relies on the fact that on even the fastest computers, performing a particular computation - factoring, or breaking into their constituent pieces, large numbers - takes an unimaginably long time. Yet in 1994 Peter Shor, a mathematician, showed how Q.C. could do this same operation much faster - in a few minutes. Q.C. could provide a shortcut through time. Just why this is possible is at the heart of this concise but dense book. The particulars depend on the clever manipulations of two fundamental properties of the quantum world - superposition and entanglement. Superposition lets a single quantum switch be on and off at the same time; entanglement allows the state of one quantum switch to be linked with that of another. Set up just right, a collection of such quantum switches can, in principle, be used to build a computer that manipulates many numbers at once - transforming millions of numbers in one step, or, via mind-numbingly complex manipulations, factoring the numbers that support our financial and national security. Fortunately for those who use codes to maintain secrets, we also learn that Q.C. does not exist yet, at least not in a useful form. As Mr. Johnson notes, the world record for building a quantum computer involves just seven qubits (quantum switches, pronounced like the word cubits) operating for less than a second. A quantum computer with several thousand qubits and able to run for hours is not expected anytime soon. The problems involved in scaling up are complex and hard to resolve. They relate to the tendency of superposed quantum states to collapse to a single value - either on or off - when the real world impinges. "A Shortcut Through Time" is not all metaphor. It also touches on the history of this young field, noting a prescient paper by the physicist Richard P. Feynman, who postulated in 1982 that quantum computing might be possible. (Also mentioned is the independent work by a less famous but just as visionary physicist, Paul Benioff, formerly of the Argonne National Laboratory.) But what makes this book a delight and a rare gem of science writing is the science itself, and Mr. Johnson's engagement with that science. He promises that he is not going to cheat by implying omniscience with his subject), and he does not. The result is fascinating and tremendously engaging. After all this, you may be wondering whether I now understand quantum computing. Well, there are some who argue that quantum physics is so foreign to human experience that no one can truly understand it, only manipulate its mathematical rules. Mr. Johnson does not use mathematics and he skips many details. ("We are operating here on a need-to-know basis," he states.) But I found that with him at my side, I could reach that delicate mental state that feels like understanding. Now this state, like a quantum superposition, may collapse to ignorance when I try to explain it to someone, but in the meantime, I feel less guilty. Ian Foster is a senior scientist at Argonne National Laboratory and a professor of computer science at the University of Chicago. -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From DaveHowe at gmx.co.uk Fri Mar 7 11:12:42 2003 From: DaveHowe at gmx.co.uk (David Howe) Date: Fri, 7 Mar 2003 16:12:42 -0000 Subject: Scientists question electronic voting References: Message-ID: <001901c2e4d1$b0065ce0$c71121c2@sharpuk.co.uk> "Francois Grieu" wrote: > Then there is the problem that the printed receipt must not be usable > to determine who voted for who, even knowing in which order the > voters went to the machine. Therefore the printed receipts must be > shuffled. Which brings us straight back to papers in a box, that we > shake before opening. This may be the case in france - but in england, every vote slip has a unique number which is recorded against the voter id number on the original voter card. any given vote *can* be traced back to the voter that used it. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From frantz at pwpconsult.com Fri Mar 7 12:43:41 2003 From: frantz at pwpconsult.com (Bill Frantz) Date: Fri, 7 Mar 2003 09:43:41 -0800 Subject: Proven Primes In-Reply-To: <3E686E90.1000500@algroup.co.uk> References: Message-ID: At 2:04 AM -0800 3/7/03, Ben Laurie wrote: >BTW, a terminology nit - a Sophie Germain prime is one such that p and >2p+1 are prime - I'll be that what you've given me is one such that p >and (p-1)/2 are prime, right? Yes. And I do know that the Sophie Germain prime is the smaller of the two related primes. Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | Due process for all | Periwinkle -- Consulting (408)356-8506 | used to be the | 16345 Englewood Ave. frantz at pwpconsult.com | American way. | Los Gatos, CA 95032, USA --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From mads at opencs.com.br Fri Mar 7 13:14:04 2003 From: mads at opencs.com.br (Mads Rasmussen) Date: Fri, 7 Mar 2003 15:14:04 -0300 Subject: REQ: Review of Nigel Smart's "Introduction to Cryptography" Message-ID: <23F980CFF4C45B4792FFF3CE015C541A02602E@olimpia.opencs.com.br> Has anyone read Nigel Smart's book from late 2002, "introduction to Cryptography" The latest IACR newsletter brought an overview and TOC of the book, which I found interesting. It seems to me the first time provable security is mentioned in a textbook (see part IV, 17 and 18) As the newsletter said, more info is available at http://www.mcgraw-hill.co.uk/html/0077099877.html I would be very interested in hearing from someone that read the book on how this material is presented. I find Bellare and Rogaway's lecture notes magnificent but it isn't a textbook. I quoted the excerpt from the IACR newsletter below for those who might be interested Regards, Mads Rasmussen -- Cryptography, An Introduction by Nigel Smart, McGraw-Hill, 2002. ISBN 0 077 09987 7 (PB). Nigel Smart's Cryptography provides the rigorous detail required for advanced cryptographic studies, yet approaches the subject matter in an accessible style in order to gently guide new students through difficult mathematical topics. Covering the latest developments in cryptography, including the Rijndael algorithm chosen for the new Advanced Encryption Standard, the OAEP padding system for RSA, elliptic curve based systems and provable security this book is a complete introduction to cryptography. Part I Mathematical Background 1 Modular Arithmetic, Groups, Finite Fields and Probability 2 Elliptic Curves Part II Symmetric Encryption 3 Historical Ciphers 4 Information Theoretic Security 5 Symmetric Ciphers 6 Symmetric Key Distribution Part III Public Key Encryption and Signatures 7 Basic Public Key Encryption Algorithms 8 Primality Testing and Factoring 9 Discrete Logarithms 10 Key Exchange, Signature Schemes and Hash Functions 11 Implementation Issues 12 Obtaining Authentic Public Keys 13 Protocols Part IV Security Issues 14 Attacks on Public Key Schemes 15 Definitions of Security 16 Complexity Theoretic Approaches 17 Provable Security: With Random Oracles 18 Provable Security: Without Random Oracles Appendices Appendix A Basic Mathematical Terminology Appendix B Java Examples Index --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From tim at dierks.org Fri Mar 7 13:40:56 2003 From: tim at dierks.org (Tim Dierks) Date: Fri, 07 Mar 2003 13:40:56 -0500 Subject: Proven Primes In-Reply-To: <3E686E90.1000500@algroup.co.uk> References: Message-ID: <5.2.1.0.2.20030307132719.0b783fc8@dierks.org> At 10:04 AM 3/7/2003 +0000, Ben Laurie wrote: >Indeed. The commonly used one is ECPP which uses elliptic curves cunningly >to not only prove primality, but to produce a certificate which can be >quickly verified. > >Probabilistic prime tests are just that - probable. ECPP actually proves it. Does anyone, in practice, care about the distinction, if the probability that the prime test has failed can be proved to be far less than the chance that a hardware failure has caused a false positive ECPP test? To restate the question: all calculation methods have a certain possibility of failure, whether due to human or mechanical error, however minute that possibility may be. If I can use a probabalistic primality test to reduce the possibility of error due to algorithm failure to a point that it's well below the possibility of error due to hardware failure, what's the practical difference? Thanks, - Tim --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From lrkn at earthlink.net Fri Mar 7 13:45:41 2003 From: lrkn at earthlink.net ((Mr) Lyn R. Kennedy) Date: Fri, 7 Mar 2003 12:45:41 -0600 Subject: Scientists question electronic voting In-Reply-To: <20030307072223.GA49740@pit.databus.com> References: <003601c2e3f8$736ea1e0$d0966395@p1038mobile> <3E677F38.C4002959@nma.com> <20030307033522.GA47904@pit.databus.com> <20030307065044.GD273@workstn.my.domain> <20030307072223.GA49740@pit.databus.com> Message-ID: <20030307184541.GB252@workstn.my.domain> On Fri, Mar 07, 2003 at 02:22:23AM -0500, Barney Wolff wrote: > On Fri, Mar 07, 2003 at 12:50:44AM -0600, (Mr) Lyn R. Kennedy wrote: > > > > Paper ballots, folded, and dropped into a large transparent box, is not a > > broken system. It's voting machines, punch cards, etc that are broken. > > I don't recall seeing news pictures of an election in any other western > > democracy where they used machines. > > Surely you jest - where else did the term ballot-stuffing come from? Perhaps you can elaborate on how ballot-stuffing is done without the co-operation of most of the people overseeing a polling place. > The key, imho, is >=2 independent means of counting the votes. Online, > as each vote is cast, and a paper trail, for later reconciliation. > It's hard for both to be skewed by the same amount, and differences > will both raise suspicion and give an order of magnitude of the fraud. > That seems to be the direction the experts are heading. What is to prevent the people overseeing a polling place from casting the votes for the dead? They would be recorded properly both ways. Or they could void and re-vote for ordinary voters. Seems there is still a problem unless each eligible voter brings a smart- card, warm finger, eyeball, etc. -- ------------------------------------------------------------------------- | 73, E-mail | lrkn at earthlink.net | | Lyn Kennedy webpage | http://home.earthlink.net/~lrkn | | K5QWB ICBM | 32.5 North 96.9 West | ---Livin' on an information dirt road a few miles off the superhighway--- --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From bill.stewart at pobox.com Fri Mar 7 13:40:37 2003 From: bill.stewart at pobox.com (Bill Stewart) Date: Fri, 07 Mar 2003 10:40:37 -0800 Subject: Proven Primes In-Reply-To: <3E686E90.1000500@algroup.co.uk> References: Message-ID: <5.1.1.6.2.20030307103029.02d87fe8@idiom.com> >>>And the proof? >> >>Sorry, an exercise for the student. :-) >>I thought that finding them was the hard part, and verifying one once found >>was relatively easy. I used the probable prime test in the Java BigInteger >>package. It sounds like, from some of the list traffic, that there are >>better tests. Well, it's harder in that to find a prime or SG prime, you need to try the probable prime test on bunch of candidates until one passes. With the Java BigInteger probable prime package, can you specify what probability it uses for primality (i.e. the probability is 2**-N or 4**-N, what's N?) --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From derek at ihtfp.com Fri Mar 7 13:42:46 2003 From: derek at ihtfp.com (Derek Atkins) Date: 07 Mar 2003 13:42:46 -0500 Subject: Delta CAPPS-2 watch: decrypt boarding passes! In-Reply-To: <200303071153.h27BrDK30875@bunkhouse.propagation.net> References: <200303060819.h268JYB28653@new.toad.com> <20030306203441.GB29411@bual.research.att.com> <200303071153.h27BrDK30875@bunkhouse.propagation.net> Message-ID: "Roy M. Silvernail" writes: > On Thursday 06 March 2003 02:34 pm, John Ioannidis wrote: > > > Both JFK and SFO have stopped gate searches. Searches at security are > > still decided by the TSA personnel there (they don't get to see your > > boarding pass). > > FWIW, MSP initial security screening wants to see your boarding pass. I > didn't see anyone try to avoid showing it. I've not seen ANY airport that didn't have this initial check, although generally it is "boarding pass, printed ticket, or printed itinerary". This is actually one of the "written rules" (as opposed to some of those lovely unwritten rules that TSA seems to like imposing). -derek -- Derek Atkins Computer and Internet Security Consultant derek at ihtfp.com www.ihtfp.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From daw at mozart.cs.berkeley.edu Fri Mar 7 13:30:37 2003 From: daw at mozart.cs.berkeley.edu (David Wagner) Date: 7 Mar 2003 18:30:37 GMT Subject: Proven Primes References: Message-ID: Bill Frantz wrote: >I guess I'm dumb, but how to you verify a proof of Sophie Germain primeness >with less effort than to run the tests yourself? There are ways to prove that p is prime so that the receiver can verify the proof more easily than it would be to construct a proof. The verification process is deterministic (there is no chance of error), unlike probabilistic primality tests. Here's a simple method, due to Pratt. It turns out that p is prime if and only if the multiplicative group (Z/pZ)^* of integers modulo p is cyclic. To show that the group is cyclic, we can give a generator g. To show that g is a generator, we can factor p-1 and show that g^{(p-1)/q} != 1 (mod p) for all prime q that divide p-1. Thus, the proof of primality for p will be proof(p) = (g, q_1, proof(q_1), q_2, proof(q_2), ...) where q_1, q_2, ... is the list of prime factors of p and where proof(q_i) is a recursive proof of primality for q_i. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From astiglic at okiok.com Fri Mar 7 14:08:04 2003 From: astiglic at okiok.com (Anton Stiglic) Date: Fri, 7 Mar 2003 14:08:04 -0500 Subject: Proven Primes References: Message-ID: <006301c2e4dc$e3cee3c0$46976395@p1038mobile> > I thought that finding them was the hard part, and verifying one once found > was relatively easy. I used the probable prime test in the Java BigInteger > package. It sounds like, from some of the list traffic, that there are > better tests. Chapter 4 of the HAC gives a good introduction to all of this. http://www.cacr.math.uwaterloo.ca/hac/about/chap4.pdf There are probabilistic primality tests (e.g. Miller-Rabin), there are primality proving algorithms (e.g. Jacoby Sum Test, ECPP), some of which give a certificate of primality that can be verified using a different algorithm. Some of the tests work on integers of special forms (e.g. Mersenne numbers), others work on all integers. There are also algorithms that generate integers that are guaranteed to be prime (e.g. Maurer's algorithm), these are not tests... --Anton --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From jhh at cs.kun.nl Fri Mar 7 14:16:55 2003 From: jhh at cs.kun.nl (Jaap-Henk Hoepman) Date: 07 Mar 2003 20:16:55 +0100 Subject: REQ: Review of Nigel Smart's "Introduction to Cryptography" In-Reply-To: <23F980CFF4C45B4792FFF3CE015C541A02602E@olimpia.opencs.com.br> References: <23F980CFF4C45B4792FFF3CE015C541A02602E@olimpia.opencs.com.br> Message-ID: <87wujb2di0.fsf@smtp.xs4all.nl> Actually, there's the textbook "Introduction to Cryptography" by Delfs and Knebl that covers provably secure encryption and digital signatures as well. Published by Springer. Jaap-Henk On Fri, 7 Mar 2003 15:14:04 -0300 "Mads Rasmussen" writes: > Has anyone read Nigel Smart's book from late 2002, "introduction to > Cryptography" > > The latest IACR newsletter brought an overview and TOC of the book, > which I found interesting. It seems to me the first time provable > security is mentioned in a textbook (see part IV, 17 and 18) > > As the newsletter said, more info is available at > > http://www.mcgraw-hill.co.uk/html/0077099877.html > > -- Jaap-Henk Hoepman | I've got sunshine in my pockets Dept. of Computer Science | Brought it back to spray the day University of Nijmegen | Gry "Rocket" (w) www.cs.kun.nl/~jhh | (m) jhh at cs.kun.nl (t) +31 24 36 52710/531532 | (f) +31 24 3653137 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From barney at pit.databus.com Fri Mar 7 14:55:19 2003 From: barney at pit.databus.com (Barney Wolff) Date: Fri, 7 Mar 2003 14:55:19 -0500 Subject: Scientists question electronic voting In-Reply-To: <20030307184541.GB252@workstn.my.domain> References: <003601c2e3f8$736ea1e0$d0966395@p1038mobile> <3E677F38.C4002959@nma.com> <20030307033522.GA47904@pit.databus.com> <20030307065044.GD273@workstn.my.domain> <20030307072223.GA49740@pit.databus.com> <20030307184541.GB252@workstn.my.domain> Message-ID: <20030307195519.GA54288@pit.databus.com> On Fri, Mar 07, 2003 at 12:45:41PM -0600, (Mr) Lyn R. Kennedy wrote: > > > > Paper ballots ... > > > Surely you jest - where else did the term ballot-stuffing come from? > > Perhaps you can elaborate on how ballot-stuffing is done without the > co-operation of most of the people overseeing a polling place. > > > > The key, imho, is >=2 independent means of counting the votes. Online, > > as each vote is cast, and a paper trail, for later reconciliation. > > It's hard for both to be skewed by the same amount, and differences > > will both raise suspicion and give an order of magnitude of the fraud. > > That seems to be the direction the experts are heading. > > What is to prevent the people overseeing a polling place from casting the > votes for the dead? They would be recorded properly both ways. > > Or they could void and re-vote for ordinary voters. > > Seems there is still a problem unless each eligible voter brings a smart- > card, warm finger, eyeball, etc. This is a perfect example of what I'm complaining about: You're holding electronic voting to a much higher standard than you are paper ballots. Perfect is the enemy of better. We do have to take care that electronic voting does not introduce new and catastrophic vulnerabilities. Other than that, it merely has to be better (and no more expensive) than the best existing systems. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From nelson at crynwr.com Fri Mar 7 15:26:30 2003 From: nelson at crynwr.com (Russell Nelson) Date: Fri, 7 Mar 2003 15:26:30 -0500 Subject: Delta CAPPS-2 watch: decrypt boarding passes! In-Reply-To: <200303060819.h268JYB28653@new.toad.com> References: <200303060819.h268JYB28653@new.toad.com> Message-ID: <15977.118.505919.753432@desk.crynwr.com> John Gilmore writes: > And, besides identifying what cities they're doing this in, we should > also start examining a collection of these boarding passes, looking > for the encrypted "let me through without searching me" information. > Or the "Don't let me fly" information. Then we can evaluate how easy > it would be to turn one into another. (Don't mistake a system that > claims to provide security for one that actually does.) May I suggest as a non-violent civil disobedience measure, that if anyone gains the ability to change the insecurity level, that they should be careful to change it from green to yellow, or yellow to red. In that manner, you cannot be accused to trying to escape scrutiny. You make your point[1] more effectively by demonstrating that you are willing to suffer for your cause. Like the guy who wouldn't take off the T-shirt that he *bought* in the mall. [1] that the only thing worse than taking away our freedom is by doing it using insecure cryptography. -- -russ nelson http://russnelson.com | "What Problem Are You Trying Crynwr sells support for free software | PGPok | To Solve?" is a service mark 521 Pleasant Valley Rd. | +1 315 268 1925 voice | of Crynwr Software. Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From talg at cs.stanford.edu Fri Mar 7 15:26:29 2003 From: talg at cs.stanford.edu (Tal Garfinkel) Date: Fri, 7 Mar 2003 12:26:29 -0800 Subject: double shot of snake oil, good conclusion In-Reply-To: <3E678791.A7131CFF@nma.com> References: <0c248779bfc3c36c1d9db576541fbf48@melontraffickers.com> <3E63C3D9.4AE3E21D@nma.com> <20030306011515.GB7313@stanford.edu> <3E678791.A7131CFF@nma.com> Message-ID: <20030307202629.GB12263@stanford.edu> On Thu, Mar 06, 2003 at 09:38:25AM -0800, Ed Gerck wrote: > > > Tal Garfinkel wrote: > > > The value of these type of controls that they help users you basically > > trust who might be careless, stupid, lazy or confused to do the right > > thing (however the right thing is defined, according to your company > > security policy). > > It beats me that "users you basically trust" might also be "careless, stupid, > lazy or confused" ;-) That's security in the real world. You screen employee's based on their character and competence at the task you hired them to do, you typically don't rigorously drill them on security procedures, and even if you do most folks get lazy, careless or confused at some point. Example: If an executive is told by the security bozo down the hall that they should not print out sensitive documents, they might take it seriously, but then again they can make excuses for their laziness, "he's just being paranoid", "I want to read this report in bed, it won't hurt this one time", etc. On the other hand, if they have to do something like break out the digital camera, it should be pretty obvious to them that what they are doing is in pretty severe violation of company policy, will likely get them severely reprimanded if caught, and will likely obviate any convenience benefits they might have hoped to gain by having a hard copy of that document. I think experience with password security is a perfect example of a the principle at work here, if you make it convenient to do the wrong thing, people almost certainly will. > Your point might be better expressed as "the company security policy would > be followed even if you do NOT trust the users to do the right thing." > But, > as we know, this only works if the users are not malicious, if social > engineering cannot be used, if there are no disgruntled employees, and > other equally improbable factors. Ok, so there are only two issues here. One is problems with intention (are they mallicous or not, this includes disgruntled employee's etc.) and the other is problems with competence (can they be relied upon to always follow procedure). In the former case, document control will probably only serve as a mild deterrent, but raising the bar doesn't hurts. At least you might have the chance to catch some employee trying to photo many pages of your sensitive data off their screen. In the latter case, document control can help quite a bit, and can serve as a deterrent against things like social engineering. Also, it seems you are assuming that all internal attackers have equal access to information, this is not the case. If employee's can make print outs and accidentally leave them lying around, throw them away, etc. it lowers the bar for an unprivileged internal attacker. At least if everything stays in electronic form a mallicous employee may have to attempt to tackle you computer systems access controls head on instead of simply rooting around in your desk. Clearly, document controls are not a silver bullet, but if used properly I believe they do provide a practical means of helping to restrict the propagation of sensitive information. --Tal --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From nelson at crynwr.com Fri Mar 7 15:35:40 2003 From: nelson at crynwr.com (Russell Nelson) Date: Fri, 7 Mar 2003 15:35:40 -0500 Subject: Delta CAPPS-2 watch: decrypt boarding passes! In-Reply-To: <20030306203441.GB29411@bual.research.att.com> References: <200303060819.h268JYB28653@new.toad.com> <20030306203441.GB29411@bual.research.att.com> Message-ID: <15977.668.695519.434003@desk.crynwr.com> John Ioannidis writes: > (they [TSA] still picked up "random" people without the search > string on their boarding passess). AAAARRRRGGGGHHHHHHH! If this list was to have a subtitle it would be "Practical uses of randomness". Surely they're rolling dice, or cutting a well-shuffled deck, or consulting a book of random numbers, or using some other secure source of randomness. Somebody please tell me that they're not just picking people "at random". I am reminded of a six-year-old's idea of randomness: eenie, meenie, miney, moe. -- -russ nelson http://russnelson.com | "What Problem Are You Trying Crynwr sells support for free software | PGPok | To Solve?" is a service mark 521 Pleasant Valley Rd. | +1 315 268 1925 voice | of Crynwr Software. Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From egerck at nma.com Fri Mar 7 16:21:23 2003 From: egerck at nma.com (Ed Gerck) Date: Fri, 07 Mar 2003 13:21:23 -0800 Subject: Scientists question electronic voting References: <003601c2e3f8$736ea1e0$d0966395@p1038mobile> <3E677F38.C4002959@nma.com> <3E680139.5B438AFC@nma.com> <001c01c2e4ba$4d41c0c0$46976395@p1038mobile> Message-ID: <3E690D53.E128F5D8@nma.com> Anton Stiglic wrote: > ----- Original Message ----- > From: "Ed Gerck" > > [...] > > "For example, using the proposed system a voter can easily, by using a > > small concealed camera or a cell phone with a camera, obtain a copy of > > that receipt and use it to get money for the vote, or keep the job. And > > no one would know or be able to trace it." > > But that brings up my point once again: These problems already exist > with current paper-ballot voting schemes, Maybe you missed some of my comments before, but these problems do not exist in current paper-ballot voting schemes. Why should e-voting make it worse? > what exactly are you trying to > achieve with an electronic voting scheme? My target is the same level of voter privacy and election integrity that a paper-ballot system has when ALL election clerks are honest and do not commit errors. Please see Proc. Financial Cryptography 2001, p. 257 and 258 of my article on "Voting System Requirements", Springer Verlag. > To you simply want to make > the counting of the votes more reliable, and maintain the security of all > other aspects, or improve absolutely everything? Of all aspects that need to be improved when moving to an electronic system, the most important is the suspicion or fear that thousands or even millions of electronic records could be altered with a keystroke, from a remote laptop or some untraceable source. This goes hand-in-hand with questions about the current "honor system" in voting systems, where vendors make the machines and also operate them during an election. It's the overall black box approach that needs to improved. The "trust me!" approach has had several documented problems in paper ballot systems and would present even more opportunities for fraud or even plain simple errors in an electronic system. The solution is to add multiple channels with at least some independence. The paper channel is actually hard to secure and expensive to store and process. Paper would also be a step backwards in terms of efficiency and there is nothing magical about a paper copy that would make it invulnerable to fraud/errors. Cheers, Ed Gerck --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From egerck at nma.com Fri Mar 7 16:33:40 2003 From: egerck at nma.com (Ed Gerck) Date: Fri, 07 Mar 2003 13:33:40 -0800 Subject: Scientists question electronic voting References: <001901c2e4d1$b0065ce0$c71121c2@sharpuk.co.uk> Message-ID: <3E691034.8994C69F@nma.com> David Howe wrote: > "Francois Grieu" wrote: > > Then there is the problem that the printed receipt must not be usable > > to determine who voted for who, even knowing in which order the > > voters went to the machine. Therefore the printed receipts must be > > shuffled. Which brings us straight back to papers in a box, that we > > shake before opening. > This may be the case in france - but in england, every vote slip has a > unique number which is recorded against the voter id number on the > original voter card. any given vote *can* be traced back to the voter > that used it. This is true in the UK, but legal authorization is required to do so. In the US, OTOH, the paper voting systems today are done in such a way that the privacy of the vote is immune even to a court order to disclose it. Voters are not anonymous, as they must be identified and listed in the voter list at each poll place, but it is impossible (or, should be) to link a voter to a vote. This imposes, for example, limits on the time-stamp accuracy and other factors suhc as storage ordering that could help in linking a voter to a vote. Cheers, Ed Gerck --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From egerck at nma.com Fri Mar 7 16:38:11 2003 From: egerck at nma.com (Ed Gerck) Date: Fri, 07 Mar 2003 13:38:11 -0800 Subject: Scientists question electronic voting References: <003601c2e3f8$736ea1e0$d0966395@p1038mobile> <3E677F38.C4002959@nma.com> <20030307033522.GA47904@pit.databus.com> <20030307065044.GD273@workstn.my.domain> Message-ID: <3E691143.AE75BDC0@nma.com> "(Mr) Lyn R. Kennedy" wrote: > On Thu, Mar 06, 2003 at 10:35:22PM -0500, Barney Wolff wrote: > > > > We certainly don't want an electronic system that is more > > vulnerable than existing systems, but sticking with known-to-be-terrible > > systems is not a sensible choice either. > > Paper ballots, folded, and dropped into a large transparent box, is not a > broken system. The broken system is the *entire* system -- from voter registration, to ballot presentation (butterfly?), ballot casting, ballot storage, tallying, auditing, and reporting. > It's voting machines, punch cards, etc that are broken. > I don't recall seeing news pictures of an election in any other western > democracy where they used machines. Brazil, 120 million voters, 100% electronic in 2002, close to 100% since the 90's, no paper copy (and it failed when tried). BTW, the 3 nations with largest number of voters are, respectively: - India - Brazil - US Cheers, Ed Gerck --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From rcs at CS.Arizona.EDU Fri Mar 7 17:06:22 2003 From: rcs at CS.Arizona.EDU (Richard Schroeppel) Date: Fri, 7 Mar 2003 15:06:22 -0700 (MST) Subject: prime proofs Message-ID: <200303072206.h27M6Mg22389@baskerville.CS.Arizona.EDU> Dave Wagner writes > ... Here's a simple method, due to Pratt. ... People were doing this fourty years before Pratt's paper. See, for example, Dick Lehmer's 1933 paper "Hunting Big Game in the Theory of Numbers", where he describes proving primality for a 19 digit divisor of 2^95+1. It's on my web page at http://www.cs.arizona.edu/~rcs/biggame4 Or see Math. Comp. in the early 1970s for examples with more depth in the recursions. Rich Schroeppel rcs at cs.arizona.edu --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From egerck at nma.com Fri Mar 7 17:08:16 2003 From: egerck at nma.com (Ed Gerck) Date: Fri, 07 Mar 2003 14:08:16 -0800 Subject: double shot of snake oil, good conclusion References: <0c248779bfc3c36c1d9db576541fbf48@melontraffickers.com> <3E63C3D9.4AE3E21D@nma.com> <20030306011515.GB7313@stanford.edu> <3E678791.A7131CFF@nma.com> <20030307202629.GB12263@stanford.edu> Message-ID: <3E691850.B61F6C16@nma.com> Tal Garfinkel wrote: > ... > Clearly, document controls are not a silver bullet, but if used properly > I believe they do provide a practical means of helping to restrict the > propagation of sensitive information. I believe we are in agreement in many points. Microsoft's mistake was to claim that "For example, it might be possible to view a document but not to forward or print it." As I commented, of course it is possible to copy of forward it. Thus, claiming that it isn't possible is snake oil and I think we need to point it out. I'd hope that the emphasis on trustworthy computing will help Microsoft weed out these declarations and, thus, help set a higher standard. Cheers, Ed Gerck --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From bill.stewart at pobox.com Fri Mar 7 18:16:41 2003 From: bill.stewart at pobox.com (Bill Stewart) Date: Fri, 07 Mar 2003 15:16:41 -0800 Subject: Scientists question electronic voting In-Reply-To: <3E691034.8994C69F@nma.com> References: <001901c2e4d1$b0065ce0$c71121c2@sharpuk.co.uk> Message-ID: <5.1.1.6.2.20030307145625.02ed0aa8@idiom.com> At 01:33 PM 03/07/2003 -0800, Ed Gerck wrote: >David Howe wrote: > > This may be the case in france - but in england, every vote slip has a > > unique number which is recorded against the voter id number on the > > original voter card. any given vote *can* be traced back to the voter > > that used it. > >This is true in the UK, but legal authorization is required to do so. No, legal authorization is only required to do so _legally_. We're talking about different threat models here, since we're talking about stuffing ballot-boxes and bribing people - what does it take to get the information without getting caught? Can it be traced in real time, or after the fact, or both, and how much is the voter's cooperation required? How long is the data stored after the election? (For instance, if the election isn't close enough to be contested within N days, do they burn all the ballots?) The two usual scenarios are - Real-time: "Thank you for your receipt, here's your bottle of whiskey, and the Democratic Party invites you to vote again this afternoon!" - Later: "Mr. Smith, we've been auditing the ballots and we see that you voted for Emmanuel Goldstein. We're taking you in for therapy." --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From mab at research.att.com Fri Mar 7 20:11:14 2003 From: mab at research.att.com (Matt Blaze) Date: Fri, 07 Mar 2003 20:11:14 -0500 Subject: Delta CAPPS-2 watch: decrypt boarding passes! In-Reply-To: Message from Russell Nelson of "Fri, 07 Mar 2003 15:35:40 EST." <15977.668.695519.434003@desk.crynwr.com> Message-ID: <200303080111.h281BEg51472@fbi.crypto.com> At most airports, they've moved most of the screening to the security checkpoint, where they do the dump search of the people with the SSSS on the boarding pass and the lucky random selectees. For flights with SSSS people on them, they also have TSA people to screen them at the gate. I've not noticed the specific mechanism they've used to select the additional random selectees. It's possible that it's wrapped in to the program that decides who gets the SSSS printed on the boarding pass in the first place. If so, that seems like a weakness, since you would be able to predict whether you'll get the additional scrutiny before you reach the checkpoint. I'm not sure one way or the other about what the actual practice is: has anyone here (who's gone through the airports following the new procedure) been informed at the checkpoint they they've been randomly selected for additional screening but not had the SSSS printed on the boarding pass? The main way to tell if you're at one of these airports is that you DON'T have to show your ID when boarding. For checked baggage screening, however, I have seen how they do the randomness: it involves a pre-printed randomness table consulted for each bag. (Some airports do the baggage screening in front of the passenger before it is turned over to the airline.). Every bag gets a basic scan through the sniffer, and bags that test positive or that the randomness table selects are opened and searched by hand. By the way, at these airports, you can no longer get past the checkpoint with just a pre-printed receipt; you need either a boarding pass, a "gate pass" printed by the airline (like a boarding pass, but for people without a specific flight), or an airport ID. -matt Russ Nelson writes: > John Ioannidis writes: > > (they [TSA] still picked up "random" people without the search > > string on their boarding passess). > > AAAARRRRGGGGHHHHHHH! If this list was to have a subtitle it would be > "Practical uses of randomness". Surely they're rolling dice, or > cutting a well-shuffled deck, or consulting a book of random numbers, > or using some other secure source of randomness. Somebody please tell > me that they're not just picking people "at random". I am reminded of > a six-year-old's idea of randomness: eenie, meenie, miney, moe. > > -- > -russ nelson http://russnelson.com | "What Problem Are You Trying > Crynwr sells support for free software | PGPok | To Solve?" is a service mark > 521 Pleasant Valley Rd. | +1 315 268 1925 voice | of Crynwr Software. > Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | > > --------------------------------------------------------------------- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From frantz at pwpconsult.com Sat Mar 8 01:46:06 2003 From: frantz at pwpconsult.com (Bill Frantz) Date: Fri, 7 Mar 2003 22:46:06 -0800 Subject: Active Countermeasures Against Tempest Attacks In-Reply-To: References: Message-ID: It has occurred to me that the cheapest form of protection from tempest attacks might be an active transmitter that swamps the signal from the computer. Such a transmitter would still be legal if its power output is kept within the FCC part 15 rules. Take, for example, the signal from a CRT monitor. The monitor signal consists of large signals which are the vertical and horizontal sync pulses, and smaller signals which are the levels of each of the phosphor guns. The simplest countermeasure would be random RF noise which is many orders of magnitude stronger than the signal from the monitor. However, with this system, the attacker can average many fields from the monitor and perhaps still recover the signal because any give pixel is the same, while the noise is random. (Or at least the pixels change slowly compared with the fields, giving lots of data to average.) The next more complex version sends the same random screen over and over in sync with the monitor. Even more complex versions change the random screen every-so-often to try to frustrate recovering the differences between screens of data on the monitor. Can such a device be built and still stay within the Part 15 rules? Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | Due process for all | Periwinkle -- Consulting (408)356-8506 | used to be the | 16345 Englewood Ave. frantz at pwpconsult.com | American way. | Los Gatos, CA 95032, USA --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From lrkn at earthlink.net Sat Mar 8 11:35:46 2003 From: lrkn at earthlink.net ((Mr) Lyn R. Kennedy) Date: Sat, 8 Mar 2003 10:35:46 -0600 Subject: Scientists question electronic voting In-Reply-To: <20030307195519.GA54288@pit.databus.com> References: <003601c2e3f8$736ea1e0$d0966395@p1038mobile> <3E677F38.C4002959@nma.com> <20030307033522.GA47904@pit.databus.com> <20030307065044.GD273@workstn.my.domain> <20030307072223.GA49740@pit.databus.com> <20030307184541.GB252@workstn.my.domain> <20030307195519.GA54288@pit.databus.com> Message-ID: <20030308163546.GB276@workstn.my.domain> On Fri, Mar 07, 2003 at 02:55:19PM -0500, Barney Wolff wrote: > On Fri, Mar 07, 2003 at 12:45:41PM -0600, (Mr) Lyn R. Kennedy wrote: > > > > Seems there is still a problem unless each eligible voter brings a smart- > > card, warm finger, eyeball, etc. > > This is a perfect example of what I'm complaining about: You're holding > electronic voting to a much higher standard than you are paper ballots. If it's not a higher standard then it violates the "If it aint broke, don't fixit" rule. But I'm concerned about "KISS" and "the right tool for the job" more than anything. > Perfect is the enemy of better. We do have to take care that electronic > voting does not introduce new and catastrophic vulnerabilities. Other > than that, it merely has to be better (and no more expensive) than the > best existing systems. Unfortunately, there is a trend toward more complex systems as a solution to everything. Families of firefighters who died in the WTC collapse would probably have been happier if they had the old low-tech radios from 20 years ago rather than whiz-bang gadgetry that failed. There was no plan to fall back on since politicians believed the salesman who told them it wouldn't fail. And the proposed fix is more complexity rather than the right tools for the job. This is what happened in the Florida elections as well. "Upgrading" the voting systems was the problem, not the solution. More complex machines add to the number of failure modes. I'm in favor of using modern technology. But I don't want to move to electronic systems just to make some salesman happy. Modern technology and public-key cryptography seems to offer some real advantages to verifying eligibility, one-person-one-vote, and vote- whever-you-are but many such issues are not even addressed. Passed over in favor of making money for voting machine companies. -- ------------------------------------------------------------------------- | 73, E-mail | lrkn at earthlink.net | | Lyn Kennedy webpage | http://home.earthlink.net/~lrkn | | K5QWB ICBM | 32.5 North 96.9 West | ---Livin' on an information dirt road a few miles off the superhighway--- --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ben at algroup.co.uk Sat Mar 8 13:45:56 2003 From: ben at algroup.co.uk (Ben Laurie) Date: Sat, 08 Mar 2003 18:45:56 +0000 Subject: Proven Primes In-Reply-To: References: Message-ID: <3E6A3A64.4070609@algroup.co.uk> Jack Lloyd wrote: > I believe the IPSec primes had been proven. All are SG primes with a g=2 > > Check RFC 2412, draft-ietf-ipsec-ikev2-05.txt, and > draft-ietf-ipsec-ike-modp-groups-05.txt > > However, I don't seen any primality proof certificates included in the > texts. RFC 2412 looks good, however, as you say, no certificates are included, nor is it made clear that (p-1)/2 has been proven. I-Ds are less useful to me, since I can't give a long-term reference for them :-( Thanks! Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From bill.stewart at pobox.com Sat Mar 8 16:24:41 2003 From: bill.stewart at pobox.com (Bill Stewart) Date: Sat, 08 Mar 2003 13:24:41 -0800 Subject: Scientists question electronic voting In-Reply-To: <3E6A550F.76B74482@nma.com> References: <001901c2e4d1$b0065ce0$c71121c2@sharpuk.co.uk> <5.1.1.6.2.20030307145625.02ed0aa8@idiom.com> Message-ID: <5.1.1.6.2.20030308125729.02ea4ee8@idiom.com> Barney Wolff wrote: > This is a perfect example of what I'm complaining about: You're holding > electronic voting to a much higher standard than you are paper ballots. If it's going to replace paper ballots, it needs to offer advantages that make up for its disadvantages, and if it gives us the opportunity to make a significantly better system, might as well try to do that too. The two main disadvantages of paper systems are slow speed and cost of counting. Problems with speed are really problems with lack of patience :-) But electronic systems have the major disadvantage that unless you have some kind of independently auditable record created at the time of voting, there's no way to tell that the system hasn't been set to cheat, whereas most of the easy ways to cheat paper and lever-machine systems are obvious, and can either be prevented by watching the materials at the right times, or audited by counting the holes and hanging chads and unused supplies afterwards. The primary complaint everybody had with Florida's paper ballot system was that the layout was confusing, making it hard to tell if you were voting for Gore or Buchanan, and any of you who've never seen a confusing layout on a computer interface can let me know.... At 12:39 PM 03/08/2003 -0800, Ed Gerck wrote: >Bill Stewart wrote: > > No, legal authorization is only required to do so _legally_. > > We're talking about different threat models here, > > since we're talking about stuffing ballot-boxes and bribing people - > > what does it take to get the information without getting caught? > > Can it be traced in real time, or after the fact, or both, > > and how much is the voter's cooperation required? > > How long is the data stored after the election? > > (For instance, if the election isn't close enough to be contested > > within N days, do they burn all the ballots?) > >The UK is still a sovereign nation and, thus, they can choose to have >an election system where the ability to verify eligibility to vote >after the election trumps the voter's right to privacy, fraud >possibilities notwithstanding. The US and other countries have >a different model for public elections, where voter privacy is absolute. Well, of course they can, if they want; they can also go back to strange women lying in ponds distributing swords for all I care... But the context of the discussion isn't whether the system will do the things it's supposed to when nobody's trying to cheat, and if they've got different rules, they've got different ways to cheat. > > The two usual scenarios are > > - Real-time: "Thank you for your receipt, here's your bottle of whiskey, > > and the Democratic Party invites you to vote again this > afternoon!" > >Not in the UK -- there is no Democratic party there ;-) What's the traditional bribe for a vote in the UK? --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From perry at piermont.com Sat Mar 8 18:17:14 2003 From: perry at piermont.com (Perry E. Metzger) Date: 08 Mar 2003 18:17:14 -0500 Subject: ADMIN: voting, etc... Message-ID: <87bs0lla85.fsf@snark.piermont.com> I'm going to be ending the voting discussion now, at least for the moment, unless anyone has anything really interesting/new to say. -- Perry E. Metzger perry at piermont.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From notable at mindspring.com Sat Mar 8 09:53:06 2003 From: notable at mindspring.com (Rebecca Mercuri) Date: Sat, 8 Mar 2003 09:53:06 -0500 Subject: Scientists question electronic voting References: <3E63FF95.708674AF@nma.com> <5.2.0.9.0.20030306162648.01d3ae40@pop.ix.netcom.com> Message-ID: <007401c2e5d1$4f4f7c50$4401b041@youru2wocurx4t> In the US it is a felony (in most, perhaps all, states) to sell one's vote. One of the reason Internet voting is not having much appeal here is because it will make it much easier to do this (even simply by passing one's ID along). People here also don't like the idea of having biometric ID for election purposes because the folks who generally have been denied the right to vote in the past are the ones who are also the most wary about the government having their biometric information. Internet voting for sociological reasons alone (security and auditibility issues aside) is a really bad idea. (Yes, Ed, I know you disagree but your proposals do not solve the overwhelming sociological problems.) The question is really: how many more people will be disillusioned by the new technologies and will voter turnout decrease after it is no longer a novelty? There's something to be said for the community aspect of going to the polls. R. Mercuri. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From mads at opencs.com.br Sat Mar 8 20:01:23 2003 From: mads at opencs.com.br (Mads Rasmussen) Date: Sat, 8 Mar 2003 22:01:23 -0300 Subject: SV: REQ: Review of Nigel Smart's "Introduction to Cryptography" Message-ID: <23F980CFF4C45B4792FFF3CE015C541A026031@olimpia.opencs.com.br> Thanks, I wasn't aware of that More info at http://cryptography.informatik.fh-nuernberg.de/ It seems like chapters 9 and 10 are what you were referring to Regards, Mads > -----Oprindelig meddelelse----- > Fra: Jaap-Henk Hoepman [mailto:jhh at cs.kun.nl] > Actually, there's the textbook "Introduction to Cryptography" > by Delfs and > Knebl that covers provably secure encryption and digital > signatures as well. > Published by Springer. > > Jaap-Henk > > On Fri, 7 Mar 2003 15:14:04 -0300 "Mads Rasmussen" > writes: > > Has anyone read Nigel Smart's book from late 2002, "introduction to > > Cryptography" > > > > The latest IACR newsletter brought an overview and TOC of the book, > > which I found interesting. It seems to me the first time provable > > security is mentioned in a textbook (see part IV, 17 and 18) > > > > As the newsletter said, more info is available at > > > > http://www.mcgraw-hill.co.uk/html/0077099877.html > > > > > --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ggr at qualcomm.com Sat Mar 8 20:33:27 2003 From: ggr at qualcomm.com (Greg Rose) Date: Sun, 09 Mar 2003 12:33:27 +1100 Subject: Proven Primes In-Reply-To: <3E6A3A64.4070609@algroup.co.uk> References: Message-ID: <5.1.0.14.2.20030309123042.03100ce0@203.30.171.11> Tom St Denis has a program that constructs provable primes, by bootstrapping them from smaller proven primes. The trouble is that his stuff is off the air at the moment. You might write to him, though. It's pretty quick, IIRC. Greg. At 06:45 PM 3/8/2003 +0000, Ben Laurie wrote: >Jack Lloyd wrote: >>I believe the IPSec primes had been proven. All are SG primes with a g=2 >>Check RFC 2412, draft-ietf-ipsec-ikev2-05.txt, and >>draft-ietf-ipsec-ike-modp-groups-05.txt >>However, I don't seen any primality proof certificates included in the >>texts. > >RFC 2412 looks good, however, as you say, no certificates are included, >nor is it made clear that (p-1)/2 has been proven. > >I-Ds are less useful to me, since I can't give a long-term reference for >them :-( > >Thanks! > >Ben. > >-- >http://www.apache-ssl.org/ben.html http://www.thebunker.net/ > >"There is no limit to what a man can do or how far he can go if he >doesn't mind who gets the credit." - Robert Woodruff > > >--------------------------------------------------------------------- >The Cryptography Mailing List >Unsubscribe by sending "unsubscribe cryptography" to >majordomo at wasabisystems.com > Greg Rose INTERNET: ggr at qualcomm.com Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199 Level 3, 230 Victoria Road, http://people.qualcomm.com/ggr/ Gladesville NSW 2111 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From die at die.com Sat Mar 8 21:35:37 2003 From: die at die.com (Dave Emery) Date: Sat, 8 Mar 2003 21:35:37 -0500 Subject: Active Countermeasures Against Tempest Attacks In-Reply-To: References: Message-ID: <20030309023537.GA11868@pig.die.com> On Fri, Mar 07, 2003 at 10:46:06PM -0800, Bill Frantz wrote: > > The next more complex version sends the same random screen over and over in > sync with the monitor. Even more complex versions change the random screen > every-so-often to try to frustrate recovering the differences between > screens of data on the monitor. > Five or six years ago I floated the suggestion that one could do worse than phase lock all the video dot clock oscillators in a computer room or office to the same master timing source. This would make it significantly harder to recover one specific monitor's image by averaging techniques as the interference from nearby monitors would have exactly the same timing and would not average out as it does in the more typical case where each monitor is driven from a video board with a slightly different frequency dot clock (due to aging and manufacturing tolerances). Modifying existing video boards to support such master timing references is possible, but not completely trivial - but would cost manufacturers very little if it was designed in in the first place. And of course one could "improve" the shielding on the monitor with the dummy unimportant data so it radiated 10 or 20 db more energy than the sensitive information monitor next to it. In many cases this might involve little more than scraping off some conductive paint or removing the ground on a cable shield. I am sure that it would take little effort with a spectrum analyzer and some hand tools to defeat most of the EMI suppression in many monitors and whilst this would not be entirely legal under FCC rules (at least for a manufacturer or dealer) it probably would be closer to legal than deliberately creating rf interference with an intentionally radiating jammer. I imagine, however, that the usefulness of the RF radiated by a modern TFT flat panel display fed with DVI digital video is already much less as there is no serial stream of analog pixel by pixel video energy at any point in such an environment. Most TFTs do one entire row or column of the display at a time in parallel which does not yield an easily separated stream of individual pixel energy. Thus extracting anything resembling an image would seem very difficult. So perhaps the era of the simplest to exploit TEMPEST threats is ending as both optical and rf TEMPEST is much easier with raster scan pixel at a time CRT displays than it is with modern more parallel flat panel display designs. -- Dave Emery N1PRE, die at die.com DIE Consulting, Weston, Mass. PGP fingerprint = 2047/4D7B08D1 DE 6E E1 CC 1F 1D 96 E2 5D 27 BD B0 24 88 C3 18 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ghicks at cadence.com Sat Mar 8 21:49:28 2003 From: ghicks at cadence.com (Gregory Hicks) Date: Sat, 8 Mar 2003 18:49:28 -0800 (PST) Subject: voting, etc... Message-ID: <200303090249.h292nS1d026949@pony-express.cAdence.COM> > To: cryptography at wasabisystems.com > Subject: ADMIN: voting, etc... > From: "Perry E. Metzger" > Date: 08 Mar 2003 18:17:14 -0500 > > > I'm going to be ending the voting discussion now, at least for the > moment, unless anyone has anything really interesting/new to say. I don't have anything to say, but the discussion has been very interesting - since I'm going to be one of the guinea pigs here in Santa Clara... I've learned a *bunch* of things to look out for - AND to see if the county supervisors have even discussed any of these items. I've enjoyed reading the discussion. Regards, Gregory Hicks --------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 6B1 | Fax: 408.894.3479 San Jose, CA 95134 | Internet: ghicks at cadence.com Never attribute to malice that which is adequately explained by ignorance or stupidity. Asking the wrong questions is the leading cause of wrong answers "The best we can hope for concerning the people at large is that they be properly armed." --Alexander Hamilton --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From reinhold at world.std.com Sun Mar 9 00:14:45 2003 From: reinhold at world.std.com (Arnold G. Reinhold) Date: Sun, 9 Mar 2003 00:14:45 -0500 Subject: Active Countermeasures Against Tempest Attacks In-Reply-To: References: Message-ID: At 10:46 PM -0800 3/7/03, Bill Frantz wrote: >It has occurred to me that the cheapest form of protection from tempest >attacks might be an active transmitter that swamps the signal from the >computer. Such a transmitter would still be legal if its power output is >kept within the FCC part 15 rules. > >Take, for example, the signal from a CRT monitor. The monitor signal >consists of large signals which are the vertical and horizontal sync >pulses, and smaller signals which are the levels of each of the phosphor >guns. > >The simplest countermeasure would be random RF noise which is many orders >of magnitude stronger than the signal from the monitor. However, with this >system, the attacker can average many fields from the monitor and perhaps >still recover the signal because any give pixel is the same, while the >noise is random. (Or at least the pixels change slowly compared with the >fields, giving lots of data to average.) > >The next more complex version sends the same random screen over and over in >sync with the monitor. Even more complex versions change the random screen >every-so-often to try to frustrate recovering the differences between >screens of data on the monitor. > >Can such a device be built and still stay within the Part 15 rules? > >Cheers - Bill > Part 15 is pretty complex, but reading a summary at http://www.arrl.org/tis/info/part15.html suggests a number of problems. First there are dozens of bands where intentional radiators are not permitted to operate (15.205). Designing a noise source that avoided all these band might be difficult. Second, the permitted signal levels associated with intentional radiators (15.209) are very similar to those permitted for unintentional radiators (15.109), including most consumer grade CRT monitors (Class B). Commercial monitors (Class A) are permitted higher levels of radiation, but I suspect most monitors made today are Class B. Now the radiation from a monitor is mostly sweep signals and the like, which carry no information. The signals that drive the CRT guns are much weaker. But I suspect you will need the noise to be much more powerful to obliterate the signal carrying data. The situation is even worse if the attacker suspects what the data may contain. He can then use correlation techniques to find the data well below the noise level. I'd also point out that the noise source has be be co-located with the data signal. Otherwise, the attacker can use a directional antenna to capture the noise signal without the data signal, allowing it to be subtracted from the data+noise signal. Similarly, it will be vital to change the noise pattern whenever the content of the CRT changes, otherwise the attacker who had reason to suspect when the screen changed can subtract data1+noise from data2+noise to get data2-data1, which is likely to leak a lot of information. I suspect it would be cheaper to shield the CRT or operate in a Faraday cage. Arnold Reinhold --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ashwood at msn.com Sun Mar 9 00:06:56 2003 From: ashwood at msn.com (Joseph Ashwood) Date: Sat, 8 Mar 2003 21:06:56 -0800 Subject: Comments/summary on unicity discussion References: <3E63C916.31E993CC@nma.com> <20030306231223.A20908@delusion.private.untruth.org> Message-ID: <012501c2e5fd$31bc3620$6401a8c0@josephas> ----- Original Message ----- From: "Joshua Hill" Subject: Re: Comments/summary on unicity discussion > It doesn't deal with plaintext, just ciphertext. In fact, unicity > distance is only valid for a ciphertext only attack. Once you get a > known plaintext/ciphertext pair, a high unicity distance works against > you (more on this later). In addition, it is isn't certain that after > observing the requisite unicity distance number of ciphertext units that > you can uniquely determine the key, it is merely very likely. There appears to be an error in there. The Unicity Distance has a very strong correlation with the uncertainty of the plaintext (entropy per message). By having access to the plaintext/ciphertext pair (often it takes multiple pairs), this removes all uncertainty as to the plaintext, this changes the unicity distance calculation by making the unicity distance as short as possible, which would make "Once you get a known plaintext/ciphertext pair, a high unicity distance works against you" Seem more than a little odd as a statement. On K complexity, while K complexity offers a convenient, if somewhat inaccurate, upperbound of the entropy, that is basically where the relationship ends. Permit me to give the basic example. Which of these strings has higher entropy: kevsnblawtrlnbatkb kevsnblawtrlnbatkb One was created by slapping my hands on the keyboard, and so contains some entropy, the other was created through copy and paste, and so contains none. However the K complexity of the two is identical. The portion of the equation you are forgetting is that the key to the pRNG may itself be compressible. This leads to somewhat of a logic loop, but at the end of it is the absolute smallest representation, as a compression of a given language (the only sense in which this makes sense). Joseph Ashwood Trust Laboratories http://www.trustlaboratories.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From perry at piermont.com Sun Mar 9 15:46:58 2003 From: perry at piermont.com (Perry E. Metzger) Date: 09 Mar 2003 15:46:58 -0500 Subject: ADMIN: acm.org subscribers in danger Message-ID: <87adg4jmil.fsf@snark.piermont.com> Hi there. A large fraction of the messages being sent to acm.org are being tagged as spam, by some sort of highly over-aggressive anti-spam filter acm.org has put in. I've attempted to contact the postmaster there, but so far I've failed as my attempt to get in touch get tagged as spam, too. If I keep getting torrents of bounces, all the folks using acm.org mail redirectors (and there are dozens of you) will get removed from the list in a few days. Very sorry, but I just don't know what else to do. -- Perry E. Metzger perry at piermont.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From jim at cryptogram.org Sun Mar 9 17:51:12 2003 From: jim at cryptogram.org (Jim Gillogly) Date: Sun, 09 Mar 2003 12:51:12 -1000 Subject: ADMIN: acm.org subscribers in danger In-Reply-To: <87adg4jmil.fsf@snark.piermont.com> References: <87adg4jmil.fsf@snark.piermont.com> Message-ID: <3E6BC560.3050803@cryptogram.org> Perry E. Metzger wrote: > A large fraction of the messages being sent to acm.org are being > tagged as spam, by some sort of highly over-aggressive anti-spam > filter acm.org has put in. I've switched my subscription from acm.org to cryptogram.org. However, ACM members, now that they're alerted to the problem, can go to http://www.acm.org and select "Manage your acm.org account" from the right-hand column, log in, then click on "Review/update your spam filtering options". Once you get there, you can explicitly exempt domains (like wasabisystems.com) from spam filtering, and you can also click a radio button that sends you summaries of things that have been blocked. Additionally, you can look at "quarantined" messages they've sent and have the ones you want to read forwarded to you. You can also select senders to add to your "OK" list with a radio button on this page. Although the initial settings are pretty procrustean, as you suggest, the flexibility available actually looks pretty good. Questions may be addressed to anti-spam at acm.org . -- Jim Gillogly Sterday, 17 Rethe S.R. 2003, 22:47 12.19.10.1.3, 2 Akbal 16 Kayab, Fifth Lord of Night --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From reinhold at world.std.com Mon Mar 10 09:14:59 2003 From: reinhold at world.std.com (Arnold G. Reinhold) Date: Mon, 10 Mar 2003 09:14:59 -0500 Subject: Active Countermeasures Against Tempest Attacks In-Reply-To: <20030309023537.GA11868@pig.die.com> References: <20030309023537.GA11868@pig.die.com> Message-ID: At 9:35 PM -0500 3/8/03, Dave Emery wrote: >On Fri, Mar 07, 2003 at 10:46:06PM -0800, Bill Frantz wrote: >> >> The next more complex version sends the same random screen over and over in >> sync with the monitor. Even more complex versions change the random screen >> every-so-often to try to frustrate recovering the differences between >> screens of data on the monitor. >> > > Five or six years ago I floated the suggestion that one could do >worse than phase lock all the video dot clock oscillators in a computer >room or office to the same master timing source. This would make it >significantly harder to recover one specific monitor's image by >averaging techniques as the interference from nearby monitors would have >exactly the same timing and would not average out as it does in the more >typical case where each monitor is driven from a video board with a >slightly different frequency dot clock (due to aging and manufacturing >tolerances). The dot clock on a megapixel display is around 70 MHz, or 14 nanoseconds per pixel. Syncing that over some distance is not trivial. Remember the speed of light is 1 nanosecond/foot. On the other hand, I think syncing the sweep signals would be enough to implement your idea and that should not be hard to do, possibly even in software since they are created on the video card. Effectiveness is another matter. The attacker could use a directional antenna to separate out monitors. Even if his equipment was outside the building, the windows would act like an antenna whose radiation pattern would be different for the different monitors in the room. The attacker might be able to discriminate between different monitors just by driving his van around outside. Even if he can't distinguish between different monitors, he still gets a signal that is the sum of the content on each monitor. That is analogous to a book code and likely just as secure, i.e. not very. > Modifying existing video boards to support such master timing >references is possible, but not completely trivial - but would cost >manufacturers very little if it was designed in in the first place. Modifying existing monitors to shield the video signal wouldn't cost that much either. As I understand it the big expense in Tempest rated equipment is the testing and the tight manufacturing control needed to insure that the monitors produced are the same as the ones tested. > And of course one could "improve" the shielding on the monitor >with the dummy unimportant data so it radiated 10 or 20 db more energy >than the sensitive information monitor next to it. In many cases this >might involve little more than scraping off some conductive paint or >removing the ground on a cable shield. Simply buying some class A monitors for the dummy data might do what you want, but I'm not sure 10-20 db of reduced signal to background buys you much. I've heard numbers of 100 db or more required for effective Tempest shielding, with Class B shielding (the higher grade FCC requirement) buying you 40-50 db. See for example http://www.cabrac.com/RFI_EMI_Tempest.html > > I am sure that it would take little effort with a spectrum >analyzer and some hand tools to defeat most of the EMI suppression >in many monitors and whilst this would not be entirely legal under >FCC rules (at least for a manufacturer or dealer) it probably would >be closer to legal than deliberately creating rf interference >with an intentionally radiating jammer. > > I imagine, however, that the usefulness of the RF radiated by a >modern TFT flat panel display fed with DVI digital video is already much >less as there is no serial stream of analog pixel by pixel video energy >at any point in such an environment. Most TFTs do one entire row or >column of the display at a time in parallel which does not yield an >easily separated stream of individual pixel energy. Thus extracting >anything resembling an image would seem very difficult. The signal is still serialized in digital form at some point on a pixel by pixel basis. Because flat panels do not have the high-power sweep signals of CRT monitors, the overall shielding needed to meet Class B may be less. That might make life easier for attackers. This does suggest one simple approach that might be useful for flat panels displaying sensitive text: chose foreground and back ground colors that have the same number of on and off bits in each color byte pair, e.g. foreground red and background red each have three bits on, both blues have four bits on, both greens have five bits on. That might make background and foreground more difficult to distinguish via RF radiation in an all digital system. > > So perhaps the era of the simplest to exploit TEMPEST threats >is ending as both optical and rf TEMPEST is much easier with raster >scan pixel at a time CRT displays than it is with modern more parallel >flat panel display designs. > On the other hand, remember that the earliest Tempest systems were built using vacuum tubes. An attacker today can carry vast amounts of signal processing power in a briefcase. All in all I would not put much faith in ad hoc Tempest protection. Without access to the secret specifications and test procedures, I would prefer to see highly critical operations done using battery powered laptops operating in a Faraday cage, with no wires crossing the boundary (no power, no phone, no Ethernet, nada). In that situation, one can calculate shielding effectiveness from first principles. http://www.cs.nps.navy.mil/curricula/tracks/security/AISGuide/navch16.txt suggests US government requirements for a shielded enclosure are 60 db minimum. Arnold Reinhold --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From astiglic at okiok.com Mon Mar 10 09:23:19 2003 From: astiglic at okiok.com (Anton Stiglic) Date: Mon, 10 Mar 2003 09:23:19 -0500 Subject: prime proofs References: <200303072206.h27M6Mg22389@baskerville.CS.Arizona.EDU> Message-ID: <001101c2e710$9c560010$b4ab6395@p1038mobile> The contribution of Pratt was to be the first to publish a proof that the certificate can be verified in polynomial time (thus proving that PRIMES is in NP). --Anton ----- Original Message ----- From: "Richard Schroeppel" To: Cc: "David Wagner" Sent: Friday, March 07, 2003 5:06 PM Subject: prime proofs > Dave Wagner writes > > ... Here's a simple method, due to Pratt. ... > > People were doing this fourty years before Pratt's paper. > See, for example, Dick Lehmer's 1933 paper "Hunting Big Game > in the Theory of Numbers", where he describes proving primality > for a 19 digit divisor of 2^95+1. It's on my web page at > > http://www.cs.arizona.edu/~rcs/biggame4 > > Or see Math. Comp. in the early 1970s for examples with more > depth in the recursions. > > Rich Schroeppel rcs at cs.arizona.edu > > > --------------------------------------------------------------------- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com > --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From kivinen at iki.fi Mon Mar 10 09:50:20 2003 From: kivinen at iki.fi (Tero Kivinen) Date: Mon, 10 Mar 2003 16:50:20 +0200 Subject: Proven Primes In-Reply-To: <3E6A3A64.4070609@algroup.co.uk> References: <3E6A3A64.4070609@algroup.co.uk> Message-ID: <15980.42540.83824.229768@fireball.acr.fi> Ben Laurie writes: > Jack Lloyd wrote: > > Check RFC 2412, draft-ietf-ipsec-ikev2-05.txt, and > > draft-ietf-ipsec-ike-modp-groups-05.txt > > However, I don't seen any primality proof certificates included in the > > texts. I considered adding the ecpp certificates to draft-ietf-ipsec-ike-modp-groups document, but as the certificates are several magabytes in total, there is no point of adding them to this kind of document (the document would be several hundred pages long consisting only numbers...). > RFC 2412 looks good, however, as you say, no certificates are included, > nor is it made clear that (p-1)/2 has been proven. > I-Ds are less useful to me, since I can't give a long-term reference for > them :-( The draft-ietf-ipsec-ike-modp-groups used to have pointer to the ftp site having the certificates (ftp://ftp.ssh.fi/pub/ietf/ecpp-certificates), but that was removed during the IESG review, because url references are not stable enough in general (the ftp://ftp.ssh.fi/pub/ietf/ecpp-certificates site is supposed to be there forever). That site also includes certificates of modp groups from the RFC 2412 (and (p-1)/2 also). I actually just finished finding the 16384 bit Diffie-Helman group with same kind of parameters. It took about 9.5 months to generate. The 12288 bit group took only about 15 days to generate. Proving them will propably take even longer than generating them... -- kivinen at ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ben at algroup.co.uk Mon Mar 10 10:47:56 2003 From: ben at algroup.co.uk (Ben Laurie) Date: Mon, 10 Mar 2003 15:47:56 +0000 Subject: Lucre paper updated Message-ID: <3E6CB3AC.9040907@algroup.co.uk> I have updated the Lucre paper with a new section on choosing parameters, in response to question from the lucrative project. It can be found in the usual place: http://anoncvs.aldigital.co.uk/lucre/. If I find (or write) free software that does primality proofs, then I guess I'll update it again! Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ben at algroup.co.uk Mon Mar 10 10:48:25 2003 From: ben at algroup.co.uk (Ben Laurie) Date: Mon, 10 Mar 2003 15:48:25 +0000 Subject: Proven Primes In-Reply-To: <15980.42540.83824.229768@fireball.acr.fi> References: <3E6A3A64.4070609@algroup.co.uk> <15980.42540.83824.229768@fireball.acr.fi> Message-ID: <3E6CB3C9.3080504@algroup.co.uk> Tero Kivinen wrote: > Ben Laurie writes: > >>Jack Lloyd wrote: >> >>>Check RFC 2412, draft-ietf-ipsec-ikev2-05.txt, and >>>draft-ietf-ipsec-ike-modp-groups-05.txt >>>However, I don't seen any primality proof certificates included in the >>>texts. > > > I considered adding the ecpp certificates to > draft-ietf-ipsec-ike-modp-groups document, but as the certificates are > several magabytes in total, there is no point of adding them to this > kind of document (the document would be several hundred pages long > consisting only numbers...). > > >>RFC 2412 looks good, however, as you say, no certificates are included, >>nor is it made clear that (p-1)/2 has been proven. >>I-Ds are less useful to me, since I can't give a long-term reference for >>them :-( > > > The draft-ietf-ipsec-ike-modp-groups used to have pointer to the ftp > site having the certificates > (ftp://ftp.ssh.fi/pub/ietf/ecpp-certificates), but that was removed > during the IESG review, because url references are not stable enough > in general (the ftp://ftp.ssh.fi/pub/ietf/ecpp-certificates site is > supposed to be there forever). > > That site also includes certificates of modp groups from the RFC 2412 > (and (p-1)/2 also). Thanks. > I actually just finished finding the 16384 bit Diffie-Helman group > with same kind of parameters. It took about 9.5 months to generate. > The 12288 bit group took only about 15 days to generate. I have to admit to surprise at the time involved - what s/w are you using to do the generating? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From schear at attbi.com Mon Mar 10 21:02:20 2003 From: schear at attbi.com (Steve Schear) Date: Mon, 10 Mar 2003 18:02:20 -0800 Subject: New release of Invisible IRC available Message-ID: <5.1.0.14.2.20030310180001.0480e5f8@mail.attbi.com> IIP 1.1.0 (stable) is released. (2003-03-10) Invisible IRC Project is a three-tier, peer distributed network designed to be a secure and private transport medium for high speed, low volume, dynamic content. Features: * Perfect Forward Security using Diffie-Hellman Key Exchange Protocol * Constant session key rotation * 128 bit Blowfish node-to-node encryption * 160 bit Blowfish end-to-end encryption * Chaffed traffic to thwart traffic analysis * Secure dynamic routing using cryptographically signed namespaces for node identification * Node level flood control * Seamless use of standard IRC clients * Gui interface * Peer distributed topology for protecting the identity of users * Completely modular in design, all protocols are plug-in capable The IIP software is released under the GPL license and is available for Windows 98/ME/NT/2000/XP, *nix/BSD and Mac OSX. http://invisiblenet.net/ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From raghu at atc.tcs.co.in Tue Mar 11 00:09:17 2003 From: raghu at atc.tcs.co.in (N. Raghavendra) Date: Tue, 11 Mar 2003 10:39:17 +0530 Subject: Encryption of data in smart cards Message-ID: <20030311050917.GA7031@atc.tcs.co.in> Hello, Can anyone point me to sources about encryption of data in smart cards. What I am looking for is protocols for encrypting sensitive data (e.g., medical information about the card-holder), so that even if the card falls into malicious hands, it won't be easy to read that data. Thank you, Raghavendra. -- N. Raghavendra | OpenPGP public key available Tata Consultancy Services | at http://www.keyserver.net/ Hyderabad | Key ID: 0x03618806 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From bill.stewart at pobox.com Tue Mar 11 02:43:28 2003 From: bill.stewart at pobox.com (Bill Stewart) Date: Mon, 10 Mar 2003 23:43:28 -0800 Subject: Active Countermeasures Against Tempest Attacks In-Reply-To: References: <20030309023537.GA11868@pig.die.com> <20030309023537.GA11868@pig.die.com> Message-ID: <5.1.1.6.2.20030310232926.02ef4a10@idiom.com> At 09:14 AM 03/10/2003 -0500, Arnold G. Reinhold wrote: >On the other hand, remember that the earliest Tempest systems >were built using vacuum tubes. An attacker today can carry vast amounts >of signal processing power in a briefcase. And while some of the signal processing jobs need to scale with the target systems, as computer clock speeds get faster, the leakage gets higher and therefore shielding becomes harder and leakage gets higher. Most of the older shielding systems can do fine with the 70 MHz monitor speeds, but the 3 GHz CPU clock speed is more leaky. Millimeter wavelengths are _much_ more annoying. >All in all I would not put much faith in ad hoc Tempest protection. >Without access to the secret specifications and test procedures, I would >prefer to see highly critical operations done using battery powered >laptops operating in a Faraday cage, with no wires crossing the boundary >(no power, no phone, no Ethernet, nada). In that situation, one can >calculate shielding effectiveness from first principles. >http://www.cs.nps.navy.mil/curricula/tracks/security/AISGuide/navch16.txt >suggests US government requirements for a shielded enclosure are 60 db minimum. Back when most of the energy lived at a few MHz, it was easy to make enclosures that had air vents that didn't leak useful amounts of signal. It's harder today. So take your scuba gear into your Faraday cage with you :-) Basically, if you've got a serious threat of TEMPEST attacks, you've got serious problems anyway... --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From info at hbarel.com Tue Mar 11 03:55:14 2003 From: info at hbarel.com (Hagai Bar-El) Date: Tue, 11 Mar 2003 10:55:14 +0200 Subject: double shot of snake oil, good conclusion In-Reply-To: <20030310230616.GA20100@stanford.edu> References: <5.2.0.9.2.20030310211947.00bbf1c0@mail.hbarel.com> <5.2.0.9.2.20030310211947.00bbf1c0@mail.hbarel.com> Message-ID: <5.2.0.9.2.20030311084819.01ed5120@mail.hbarel.com> Tal, I am in full agreement with your opinion. I do not think security is an "all or nothing" property, and I do think that mechanisms can be considered effective even if they do not protect against attackers with some level of skill or motivation. After all, there is no complete security and security is, and has always been, considered as "perceived assurance". I do not think that a fact that a mechanism can be somehow circumvented makes it useless. "Keepng the honest people honest" is a good enough legitimation for a mechanism to exist as well as "moving the bar higher". However, the only problem I can see in this case is the opening of a possibility of a false sense of security. Security mechanisms do not have to be perfect, but their perceived strength by their users shall be set right. For this I personally think that the mechanism is great and useful, but should be presented by Microsoft accordingly, hence: as a useful security-related feature, not as a complete bullet-proof protection tool. Hagai. Hagai Bar-El - Information Security Analyst Tel.: 972-8-9354152 Fax.: 972-8-9354152 E-mail: info at hbarel.com Web: www.hbarel.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From kivinen at iki.fi Tue Mar 11 07:50:37 2003 From: kivinen at iki.fi (Tero Kivinen) Date: Tue, 11 Mar 2003 14:50:37 +0200 Subject: Proven Primes In-Reply-To: <3E6CB3C9.3080504@algroup.co.uk> References: <3E6A3A64.4070609@algroup.co.uk> <15980.42540.83824.229768@fireball.acr.fi> <3E6CB3C9.3080504@algroup.co.uk> Message-ID: <15981.56221.302956.977240@fireball.acr.fi> Ben Laurie writes: > > I actually just finished finding the 16384 bit Diffie-Helman group > > with same kind of parameters. It took about 9.5 months to generate. > > The 12288 bit group took only about 15 days to generate. > I have to admit to surprise at the time involved - what s/w are you > using to do the generating? We have our own software and crypto library to generate those primes. To create ~500 bit group it takes about 10 seconds. To create ~1000 bit group it takes about minute. Here are ike style primes between 512-1024 where the bits is incremented by 32 every time. These are not proven, but running primo or similar on them shouldn't take that long, so you can do it yourself if you need a proven prime: SOPHIE GERMAIN PRIME SEARCH FIXED 64 bits. INDEX 0: PRIME (bits 512), index = 131, 0.989151 seconds: 0xffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a439dffffffffffffffff PRIME (bits 544), index = 11486, 2.32198 seconds: 0xffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b374affffffffffffffff PRIME (bits 576), index = 145480, 17.2525 seconds: 0xffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df2614c7effffffffffffffff PRIME (bits 608), index = 37293, 5.66688 seconds: 0xffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1c719ffffffffffffffff PRIME (bits 640), index = 335775, 42.4739 seconds: 0xffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d56e1e3ffffffffffffffff PRIME (bits 672), index = 5214, 2.83781 seconds: 0xffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485c9d3ffffffffffffffff PRIME (bits 704), index = 65808, 10.8744 seconds: 0xffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625f7fd5ffffffffffffffff PRIME (bits 736), index = 229946, 34.0901 seconds: 0xffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44fc522ffffffffffffffff PRIME (bits 768), index = 149686, 24.5593 seconds: 0xffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a63a3620ffffffffffffffff PRIME (bits 800), index = 168625, 28.5964 seconds: 0xffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0c01ef66ffffffffffffffff PRIME (bits 832), index = 13056, 5.62474 seconds: 0xffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406eaecffffffffffffffff PRIME (bits 864), index = 173063, 32.9709 seconds: 0xffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee3b1001ffffffffffffffff PRIME (bits 896), index = 26718, 9.01863 seconds: 0xffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a8a0802ffffffffffffffff PRIME (bits 928), index = 636907, 119.4 seconds: 0xffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899fa5aea8dbfbffffffffffffffff PRIME (bits 960), index = 139761, 31.0893 seconds: 0xffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899fa5ae9f24117c4d41d6ffffffffffffffff PRIME (bits 992), index = 15349, 8.29022 seconds: 0xffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899fa5ae9f24117c4b1fe64928a245ffffffffffffffff FINISHED (0 primes found in the interval 512 to 1024). -- kivinen at ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From perry at piermont.com Tue Mar 11 09:44:05 2003 From: perry at piermont.com (Perry E. Metzger) Date: 11 Mar 2003 09:44:05 -0500 Subject: Khalid Sheikh Mohammed caught partially by Echelon? Message-ID: <87fzpuynd6.fsf@snark.piermont.com> The guardian reports (unsurprisingly) that Echelon was used in tracking Khalid Sheikh Mohammed's mobile phones: http://www.guardian.co.uk/alqaida/story/0,12469,911860,00.html -- Perry E. Metzger perry at piermont.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From reinhold at world.std.com Tue Mar 11 11:04:17 2003 From: reinhold at world.std.com (Arnold G. Reinhold) Date: Tue, 11 Mar 2003 11:04:17 -0500 Subject: Active Countermeasures Against Tempest Attacks In-Reply-To: <5.1.1.6.2.20030310232926.02ef4a10@idiom.com> References: <20030309023537.GA11868@pig.die.com> <20030309023537.GA11868@pig.die.com> <5.1.1.6.2.20030310232926.02ef4a10@idiom.com> Message-ID: At 11:43 PM -0800 3/10/03, Bill Stewart wrote: >At 09:14 AM 03/10/2003 -0500, Arnold G. Reinhold wrote: >>On the other hand, remember that the earliest Tempest systems >>were built using vacuum tubes. An attacker today can carry vast amounts >>of signal processing power in a briefcase. > >And while some of the signal processing jobs need to scale with the >target systems, >as computer clock speeds get faster, the leakage gets higher and >therefore shielding becomes harder and leakage gets higher. >Most of the older shielding systems can do fine with the 70 MHz >monitor speeds, >but the 3 GHz CPU clock speed is more leaky. Millimeter wavelengths are >_much_ more annoying. >> >>All in all I would not put much faith in ad hoc Tempest protection. >>Without access to the secret specifications and test procedures, I >>would prefer to see highly critical operations done using battery >>powered laptops operating in a Faraday cage, with no wires crossing >>the boundary (no power, no phone, no Ethernet, nada). In that >>situation, one can calculate shielding effectiveness from first >>principles. >>http://www.cs.nps.navy.mil/curricula/tracks/security/AISGuide/navch16.txt >>suggests US government requirements for a shielded enclosure are 60 >>db minimum. > >Back when most of the energy lived at a few MHz, it was easy to make >enclosures >that had air vents that didn't leak useful amounts of signal. It's >harder today. >So take your scuba gear into your Faraday cage with you :-) One of my pet ideas is to used older, 1990's vintage, laptops for secure processing, e.g. reading PGP mail, generating key pairs, signing submaster keys, etc. They are cheap enough to dedicate to the task, they'd be off most of the time thereby reducing vulnerability, older operating systems and firmware have fewer opportunities for mischief and most viruses won't run on the old software. Easier shielding due to lower clock rate is an advantage I hadn't thought of before. > >Basically, if you've got a serious threat of TEMPEST attacks, >you've got serious problems anyway... You could say that about strong crypto in general. Anyone with valuable information stored on a computer has lots to worry about. Arnold Reinhold --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From tomstdenis at yahoo.com Tue Mar 11 11:28:32 2003 From: tomstdenis at yahoo.com (tom st denis) Date: Tue, 11 Mar 2003 08:28:32 -0800 (PST) Subject: Proven Primes In-Reply-To: <15981.56221.302956.977240@fireball.acr.fi> Message-ID: <20030311162832.57953.qmail@web41111.mail.yahoo.com> --- Tero Kivinen wrote: > SOPHIE GERMAIN PRIME SEARCH > FIXED 64 bits. > INDEX 0: > PRIME (bits 512), index = 131, 0.989151 seconds: > 0xffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a439dffffffffffffffff What is the benefit of having leading/trailing bits fixed? As far as I know it doesn't make any form of index calculus attack any harder to apply. Tom __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From astiglic at okiok.com Tue Mar 11 11:56:53 2003 From: astiglic at okiok.com (Anton Stiglic) Date: Tue, 11 Mar 2003 11:56:53 -0500 Subject: Proven Primes References: <20030311162832.57953.qmail@web41111.mail.yahoo.com> Message-ID: <005e01c2e7ef$39a21a00$79ab6395@p1038mobile> ----- Original Message ----- From: "tom st denis" To: "Cryptography" Sent: Tuesday, March 11, 2003 11:28 AM Subject: Re: Proven Primes > > --- Tero Kivinen wrote: > > SOPHIE GERMAIN PRIME SEARCH > > FIXED 64 bits. > > INDEX 0: > > PRIME (bits 512), index = 131, 0.989151 seconds: > > > 0xffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b 139b22514a08798e3404ddef9519b3cd3a439dffffffffffffffff > > What is the benefit of having leading/trailing bits fixed? As far as I > know it doesn't make any form of index calculus attack any harder to > apply. No, but you can speed up modulo multiplication. The OAKLEY RFC says: The high order 64 bits are forced to 1. This helps the classical remainder algorithm, because the trial quotient digit can always be taken as the high order word of the dividend, possibly +1. The low order 64 bits are forced to 1. This helps the Montgomery- style remainder algorithms, because the multiplier digit can always be taken to be the low order word of the dividend. At one point in time some of my colleagues got the optimization with the high order bits set to 1 in C code going on very well, I don`t remember if we implemented the optimization with the low order bits set to 1. --Anton --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From jeroen at vangelderen.org Tue Mar 11 11:53:26 2003 From: jeroen at vangelderen.org (Jeroen C. van Gelderen) Date: Tue, 11 Mar 2003 11:53:26 -0500 Subject: Proven Primes In-Reply-To: <20030311162832.57953.qmail@web41111.mail.yahoo.com> Message-ID: On Tuesday, Mar 11, 2003, at 11:28 US/Eastern, tom st denis wrote: > > --- Tero Kivinen wrote: >> SOPHIE GERMAIN PRIME SEARCH >> FIXED 64 bits. >> INDEX 0: >> PRIME (bits 512), index = 131, 0.989151 seconds: >> > 0xffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bb > ea63b139b22514a08798e3404ddef9519b3cd3a439dffffffffffffffff > > What is the benefit of having leading/trailing bits fixed? As far as I > know it doesn't make any form of index calculus attack any harder to > apply. Performance. See RFC 2412, Appendix E. http://www.ietf.org/rfc/rfc2412.txt -J --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ghicks at cadence.com Tue Mar 11 12:02:32 2003 From: ghicks at cadence.com (Gregory Hicks) Date: Tue, 11 Mar 2003 09:02:32 -0800 (PST) Subject: Active Countermeasures Against Tempest Attacks Message-ID: <200303111702.h2BH2WQf028733@metis.cAdence.COM> > Date: Mon, 10 Mar 2003 23:43:28 -0800 > From: Bill Stewart > > At 09:14 AM 03/10/2003 -0500, Arnold G. Reinhold wrote: > >On the other hand, remember that the earliest Tempest systems > >were built using vacuum tubes. An attacker today can carry vast amounts [...snip...] > > Basically, if you've got a serious threat of TEMPEST attacks, > you've got serious problems anyway... Actually, quite a bit of the TEMPEST framework is not stopping an adversary from reading what you have on your CRT (or display), but denying the adversary the wherewithal for figuring out that you ARE there. It would really be the pits to have someone standing off over the horizion and saying... "Hm-m-m... 70Mhz over THERE? Why is a monitor over THERE? There shouldn't be ANYTHING over THERE... Hm-m-m.. Who do we know that uses..." Well, you get the idea. TEMPEST equipment is specially shielded so that it does not leak ANY RF energy that can be picked up on RF direction finding equipment. ------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 6B1 | Fax: 408.894.3400 San Jose, CA 95134 | Internet: ghicks at cadence.com "The trouble with doing anything right the first time is that nobody appreciates how difficult it was." When a team of dedicated individuals makes a commitment to act as one... the sky's the limit. Just because "We've always done it that way" is not necessarily a good reason to continue to do so... Grace Hopper, Rear Admiral, United States Navy --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From kivinen at iki.fi Tue Mar 11 12:40:34 2003 From: kivinen at iki.fi (Tero Kivinen) Date: Tue, 11 Mar 2003 19:40:34 +0200 Subject: Proven Primes In-Reply-To: <20030311162832.57953.qmail@web41111.mail.yahoo.com> References: <15981.56221.302956.977240@fireball.acr.fi> <20030311162832.57953.qmail@web41111.mail.yahoo.com> Message-ID: <15982.8082.227348.644535@fireball.acr.fi> tom st denis writes: > 0xffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a439dffffffffffffffff > What is the benefit of having leading/trailing bits fixed? Those primes are generated using the rules defined in the RFC 2412. > As far as I know it doesn't make any form of index calculus attack > any harder to apply. High order bits makes classical remainder algorithms faster, and low order bits helps the Mongomery-style algoritms. >From the RFC 2412: ---------------------------------------------------------------------- Classical Diffie-Hellman Modular Exponentiation Groups The primes for groups 1 and 2 were selected to have certain properties. The high order 64 bits are forced to 1. This helps the classical remainder algorithm, because the trial quotient digit can always be taken as the high order word of the dividend, possibly +1. The low order 64 bits are forced to 1. This helps the Montgomery- style remainder algorithms, because the multiplier digit can always be taken to be the low order word of the dividend. The middle bits are taken from the binary expansion of pi. This guarantees that they are effectively random, while avoiding any suspicion that the primes have secretly been selected to be weak. Because both primes are based on pi, there is a large section of overlap in the hexadecimal representations of the two primes. The primes are chosen to be Sophie Germain primes (i.e., (P-1)/2 is also prime), to have the maximum strength against the square-root attack on the discrete logarithm problem. The starting trial numbers were repeatedly incremented by 2^64 until suitable primes were located. Because these two primes are congruent to 7 (mod 8), 2 is a quadratic residue of each prime. All powers of 2 will also be quadratic residues. This prevents an opponent from learning the low order bit of the Diffie-Hellman exponent (AKA the subgroup confinement problem). Using 2 as a generator is efficient for some modular exponentiation algorithms. [Note that 2 is technically not a generator in the number theory sense, because it omits half of the possible residues mod P. From a cryptographic viewpoint, this is a virtue.] -- kivinen at ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From nobody at dizum.com Tue Mar 11 14:20:02 2003 From: nobody at dizum.com (Nomen Nescio) Date: Tue, 11 Mar 2003 20:20:02 +0100 (CET) Subject: Proven Primes Message-ID: <4047e8c93de322a336a7b214eccd1143@dizum.com> Tom St Denis writes: > What is the benefit of having leading/trailing bits fixed? As far as I > know it doesn't make any form of index calculus attack any harder to > apply. The Handbook of Applied Cryptography, http://www.cacr.math.uwaterloo.ca/hac/, has a chapter on efficient implementations which might provide some insight. You can take advantage of the left FFF's by using the modular reduction algorithm described in section 14.3.4 of the HAC. This is good for the case where the modulus is slightly less than a power of 2. Or you can take advantage of the right FFF's by using Montgomery exponentiation, described in section 14.3.2 of the HAC and also in algorithm 14.94. Montgomery multiplication uses a value m' = - m^(-1) mod b, where m is the modulus and b is the bignum base, typically 2^32 or 2^64. With these moduli m' becomes 1, simplifying the calculations. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From schear at attbi.com Tue Mar 11 16:17:57 2003 From: schear at attbi.com (Steve Schear) Date: Tue, 11 Mar 2003 13:17:57 -0800 Subject: Groove shills for the DoD: Kapor quits board Message-ID: <5.1.0.14.2.20030311131602.047d0eb0@mail.attbi.com> Software Pioneer Quits Board of Groove By JOHN MARKOFF SAN FRANCISCO, March 10 ? Mitchell D. Kapor, a personal computer industry software pioneer and a civil liberties activist, has resigned from the board of Groove Networks after learning that the company's software was being used by the Pentagon as part of its development of a domestic surveillance system. http://www.nytimes.com/2003/03/11/business/11PRIV.html --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From wk at gnupg.org Tue Mar 11 16:27:07 2003 From: wk at gnupg.org (Werner Koch) Date: Tue, 11 Mar 2003 22:27:07 +0100 Subject: Encryption of data in smart cards In-Reply-To: <20030311050917.GA7031@atc.tcs.co.in> ("N. Raghavendra"'s message of "Tue, 11 Mar 2003 10:39:17 +0530") References: <20030311050917.GA7031@atc.tcs.co.in> Message-ID: <8765qpk310.fsf@alberti.g10code.de> On Tue, 11 Mar 2003 10:39:17 +0530, N Raghavendra said: > Can anyone point me to sources about encryption of data in smart > cards. What I am looking for is protocols for encrypting sensitive > data (e.g., medical information about the card-holder), so that Usually you don't need to encrypt data stored on a card. The files on the card (where you store the data) are protected by ACLs or whatever the card application provides for this. If you want to encrypt the data on the card, you also need to store the key on it. And well, if you are able to read out the data, you are also able to read out the key (more or less trivial for most mass market cards). If you fear an eavesdropper between the box generating the data and the actual smartcard, one uses secure messaging to protect against this. See your card's OS manual (or ISO 7816-8) on how to do it. If your are talking about memory cards, you can use whatever protocol you would use for encrypting files. Salam-Shalom, Werner --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From rah at shipwright.com Tue Mar 11 16:26:29 2003 From: rah at shipwright.com (R. A. Hettinga) Date: Tue, 11 Mar 2003 16:26:29 -0500 Subject: [IP] Inter-University Competition in Information Assurance Message-ID: --- begin forwarded text Status: RO User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 11 Mar 2003 02:27:40 -0500 Subject: [IP] Inter-University Competition in Information Assurance From: Dave Farber To: ip Sender: owner-ip at v2.listbox.com Reply-To: dave at farber.net From: tim finin Subject: Inter-University Competition in Information Assurance To: dave at farber.net Date: Mon, 10 Mar 2003 21:30:44 -0500 Organization: UMBC http://umbc.edu/ Dave -- IPers in the Baltimore-Washington area might be interested in this talk. Tim -- 2003 CAPITAL-AREA SEMINAR ON INFORMATION ASSURANCE UMBC Center for Information Security and Assurance University of Maryland, Baltimore County An Inter-University Competition in Information Assurance: The Cyber Defense Exercises Lt. Colonel Dan Ragsdale U.S. Military Academy, West Point, NY Friday 14 March 2003 Lunch 11:30, Skylight Lounge, UMBC Commons Talk 1:00pm, Lecture Hall V, Engineering and Computer Science During the spring of 2001 and 2002, student teams at the five United States Service Academies participated in a Cyber Defense Exercise (CDX). Prior to each exercise an identical network of servers and workstations was set up at each school. During the first phase, teams of cadets and midshipmen at each site installed and configured an assortment of required services. The goal for each team during this phase was to configure the required service and the underlying operating systems in the most secure manner possible. In the second phase, an NSA-led penetration team attacked each site. This team "Red Team," conducted detailed reconnaissance and voluminous attacks over a five-day period. They maintained accurate records of any and all successful penetrations. A "White Team" from CERT at Carnegie Mellon University refereed the exercise; they served as observers and controllers and, using an agreed upon scoring system, determined which school won. Personal observation and interviews with students and faculty show that the CDX is an extraordinary educational experience. This talk will address in detail some of the benefits and challenges of conducting such an exercise. Lt. Colonel Dan Ragsdale is director of the Information Technology and Operations Center (ITOC) at the US Military Academy (USMA) at West Point, NY. He has over twenty-one years of military and information technology experience, including seven years in the area of Information Assurance (IA). This past summer, Lt. Colonel Ragsdale participated in Operation Enduring Freedom in Afghanistan, where he served as the Chief of Assessment for the Combine and Joint Task Force (CJTF-80). In addition, he has been a frequent speaker and panelist at national IA conferences, and he has published numerous articles on IA topics. He earned a PhD from Texas A&M. His current research interests include information assurance, network security, intrusion detection, and artificial intelligence Host: Dr. Alan T. Sherman, sherman at umbc.edu, Director, UMBC CISA. http://cisa.umbc.edu/. Directions: Take Exit 47B off I-95, and follow signs to UMBC. Park in visitor's lot. ---------- ------------------------------------- You are subscribed as rah at shipwright.com To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ --- end forwarded text -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From dknobold at nym.alias.net Tue Mar 11 21:14:49 2003 From: dknobold at nym.alias.net (Dylan Knobold) Date: 12 Mar 2003 02:14:49 -0000 Subject: Tools for anonymous blogging Message-ID: <20030312021449.23198.qmail@nym.alias.net> Greetings cryptographers, I would like to ask your assistance in setting up a weblog that cannot easily be traced to my real identity. I have surveyed the existing tools and do not find one that fits my needs well. For my proposed blog, I would graciously accept volunteer hosting, but I think it's also worth thinking improving tools so anonymous blogging can be accessible to many. Of the many forms of Internet communication, blogs have many desirable properties which interact well with anonymity. Perhaps most important, the basic blog form is essentially invulnerable to spam. Any idiot can put their blog up on the Web (and many do), but nobody is forced to read it. Email, by contrast, is fertile ground for spam and other similar forms of abuse. Indeed, the anonymous remailer network had to deal with spam as a serious problem long before it became the everyday bane it is today. Similarly, while running a remailer "exit node" can lead to significant negative consequences from recipients of abuse, openly running a proxy to make anonymous blogs accessible to the public Internet is above reproach, at least among those who believe that speech should be free. Publishing a blog can be relatively high in latency, and very low in bandwidth, at least by today's standards. I believe these properties should make it relatively easy to design a blog publishing protocol which is highly resistant to surveillance. Real-time Pipenet-style systems, such as ZKS Freedom and Onion Routing, are susceptible to a listener simply correlating bursts of activity between the publicly visible blog and the user's bandwidth to the Internet. Finally, while remailers contend against the deeply entrenched email infrastructure, blog publishing tools are still in their infancy, and most people do not find it particularly convenient to publish a blog. In addition, good hosting costs money; the free hosting services are ad-ridden, in many cases badly. Given these goals, what tools are available today? The most obvious is to use an anonymizing Web proxy such as anonymizer.com in conjunction with a public blog hosting service such as LiveJournal. However, this approach doesn't give me a warm and fuzzy feeling. In particular, anonymizer.com is a single point of vulnerability, a one-stop shop if you will for spy agencies, conveniently pre-filtered to include only those who feel that leaking identity information is worth thirty bucks a year to protect (the free version is little more than a teaser for the pay service). Another possibility is to leverage the existing email infrastructure, for example Yahoo Groups. However, while posting to such a group should be reasonably straightforward using an anonymous remailer, it's not clear that admin functions are similarly accessible. Also, such an approach is vulnerable to many attacks deriving from email's lack of authentication. Finally, I don't consider an email list to be a particularly high-quality blog format. I'm not asking for all the frills, but reverse chronological display, permalinks, and an RSS feed are all essential today. Am I missing something? Is there perhaps another good approach to anonymous blog publishing? If so, I'd appreciate your insight. In the meantime, here is how my ideal hosting would work. I'd arrange (via email) with a volunteer to host my blog. She'd get my GPG public key, and I would assign me an email address for sending my updates. That address would route to a script which would decrypt incoming messages, verify that the signature matches my PK, and immediately drop any non-conforming emails at that point. The contents of a signed email message are then passed to some kind of "untar" script, which simply replaces files in a public Web directory. I'm a little unsure about the use of tar itself - it _should_ be secure, but is fairly crufty by now, and is not usually considered a security-critical utility (in fact, it's disturbing that the obvious .. path attack wasn't fixed until GNU tar 1.13.19, see CAN-2001-1267). Perhaps there is another archive unpacking tool in which the volunteer has more confidence, or perhaps a very simple, and thus easily auditable, script, could serve. I'd be more than happy to write such a script. On the posting side, any tool that produces "baked" pages, such as Blosxom, should serve. It should be relatively easy to integrate the blog-posting tool with GPG and premail, so that the updates are automatically signed, anonymized, and sent. This is a "quick and dirty" approach which should get blogs online reasonably easily. If it works well, others should be able to use it. If enough good anonymous blogs go online, that should help motivate the design of much more sophisticated tools, possibly using techniques such as IBM's YouServ to replicate content and thus reduce the dependence on particular proxy nodes. My own blog will probably serve as an example both for those who feel that anonymous speech is important to protect, and those who feel that it's too dangerous in our society. It will be intelligently written, thoughtful, fair, and hugely controversial. If past experience with anonymous Internet forums (mostly mailing lists) are any guide, I expect a steady stream of death threats and the like. Thus, hosting it is not for someone faint of heart. I'd be happy to discuss the plans privately, but they're somewhat off-topic for this list. If anyone can help me get my blog online, I'd be very grateful. In addition, I think the design of better protocols and systems for anonymous blogging is worth more attention from free speech-minded cryptographers. Peace, Dyl --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From rah at shipwright.com Wed Mar 12 06:16:19 2003 From: rah at shipwright.com (R. A. Hettinga) Date: Wed, 12 Mar 2003 06:16:19 -0500 Subject: 2nd announcement for ECC 2003 Message-ID: --- begin forwarded text Status: RO To: rah at ibuc.com From: ECC 2003 Date: Tue, 11 Mar 2003 16:35:24 -0500 (EST) Subject: 2nd announcement for ECC 2003 ------------------------------------------------------------------ THE 7TH WORKSHOP ON ELLIPTIC CURVE CRYPTOGRAPHY (ECC 2003) University of Waterloo, Waterloo, Ontario, Canada August 11, 12 & 13 2003 SECOND ANNOUNCEMENT March 11, 2003 ECC 2003 is the seventh in a series of annual workshops dedicated to the study of elliptic curve cryptography and related areas. The main themes of ECC 2003 will be: - The discrete logarithm problem. - Efficient parameter generation and point counting. - Provably secure cryptographic protocols. - Efficient software and hardware implementation. - Side-channel attacks. - Deployment of elliptic curve cryptography. It is hoped that the meeting will continue to encourage and stimulate further research on the security and implementation of elliptic curve cryptosystems and related areas, and encourage collaboration between mathematicians, computer scientists and engineers in the academic, industry and government sectors. Attendees of ECC 2003 might also wish to attend SAC 2003 (Ottawa, Aug 14-15) and CRYPTO 2003 (Santa Barbara, Aug 17-21). SPONSORS: Certicom Corp. MITACS Motorola University of Essen University of Waterloo ORGANIZERS: Gerhard Frey (University of Essen) Darrel Hankerson (Auburn University) Alfred Menezes (University of Waterloo) Christof Paar (Ruhr-Universitat Bochum) Edlyn Teske (University of Waterloo) Scott Vanstone (University of Waterloo) CONFIRMED SPEAKERS: Hans Dobbertin (Ruhr-Universitat Bochum, Germany) Florian Hess (University of Bristol, UK) Hugo Krawczyk (Technion, Israel, and IBM Research, USA) Tanja Lange (Ruhr-Universitat Bochum, Germany) Reynald Lercier (Centre d'Electronique de L'Armement, France) Ben Lynn (Stanford University, USA) William Martin (National Security Agency, USA) Christof Paar (Ruhr-Universitat Bochum, Germany) John Proos (University of Waterloo, Canada) Jean-Jacques Quisquater (Universite Catholique de Louvain, Belgium) Pankaj Rohatgi (IBM Research, USA) Victor Shoup (New York University, USA) Jerome Solinas (National Security Agency, USA) Edlyn Teske (University of Waterloo, Canada) CONFERENCE PROGRAMME: There will be approximately 15 invited lectures (and no contributed talks), with the remaining time used for informal discussions. There will be both survey lectures as well as lectures on latest research developments. All lectures will be held on the campus of the University of Waterloo. Further details of the programme and lecture rooms will be provided in the third announcement. REGISTRATION: There will be a registration fee this year of $250 Cdn or $170 US or Euros 160 ($150 Cdn or $100 US or Euros 90 for full-time graduate students). PLEASE REGISTER AS SOON AS POSSIBLE AS SPACE IS LIMITED FOR THIS WORKSHOP; REGISTRATION IS ON A FIRST-COME FIRST-SERVE BASIS. We cannot process a registration until all fees are paid in full. The deadline for all fees to be paid and registration completed has been set for the 1st of August, 2003. To register, complete, in full, the attached REGISTRATION FORM and return it along with your payment to: Mrs. Adrienne Richter, C&O Dept., University of Waterloo, Waterloo, Ontario, Canada N2L 3G1. You can also send your registration form by fax (519-725-5441) or by email (ecc2003 at math.uwaterloo.ca). Confirmation of your registration will be sent by email when payment is received in full. ------------------------cut from here--------------------------------- ECC 2003 CONFERENCE REGISTRATION FORM Fullname: _________________________________________________________ Affiliation: _________________________________________________________ Address: _________________________________________________________ _________________________________________________________ _________________________________________________________ _________________________________________________________ _________________________________________________________ E-Mail Address: _________________________________________________________ Telephone #: _________________________________________________________ Registration Fee: Please check the appropriate box: [ ] Registration .......$250.00 CAD ..............$________ [ ] Registration .......$170.00 USD ..............$________ [ ] Registration .......Euro 160.00 ..............$________ [ ] Full-time Student ..$150.00 CAD ..............$________ [ ] Full-time Student ..$100.00 USD ..............$________ [ ] Full-time Student ..Euro 90.00 ..............$________ Registration Fee includes Banquet: Attending [ ] Yes [ ] No Vegetarian [ ] Yes [ ] No TOTAL AMOUNT PAYABLE: ............................$________ **Make Cheque/Money Order Payable to: ECC 2003 Credit Card Payments: [ ] Visa [ ] MasterCard Cardholder's Name: ________________________________________________ Card Number: ______________________________________________________ Expiration Date: __________________________________________________ Signature: ________________________________________________________ Additional Information: ___________________________________________ -------------------------cut from here------------------------------- TRAVEL: Kitchener-Waterloo is approximately 100km/60miles from Pearson International Airport in Toronto. Ground transportation to Kitchener-Waterloo can be pre-arranged with Airways Transit. TRANSPORTATION TO AND FROM TORONTO AIRPORT PROVIDED BY AIRWAYS TRANSIT It is advisable to book your transportation between the Pearson Airport, Toronto, and Waterloo in advance to receive the advance booking rate of $38 CAD per person, one way, with Airways Transit (open 24 hours a day). Please quote "ECC2003" when making your reservation. Airways is a door-to-door service; they accept cash (Cdn or US funds), MasterCard, Visa and American Express. Upon arrival: Terminal 1: proceed to Ground Transportation Booth, Arrivals Level. Terminal 2: proceed to Airways Transit desk, Arrivals Level, Area E. Terminal 3: proceed to Ground Transportation Booth, Arrivals Level, between Doors B and C. You can make a reservation through their web site: www.airwaystransit.com Or, you can complete the form below and send by mail or fax (519-886-2141) well in advance of your arrival to Airways Transit. They will not fax confirmations: your fax transmission record is confirmation of your reservation. -------------------------cut from here--------------------------------- AIRWAYS TRANSIT ADVANCE BOOKING FORM - ECC 2003 ARRIVAL INFORMATION: ____________________________________________________________ Surname First name ____________________________________________________________ Toronto Arrival Date Airline Flight # ____________________________________________________________ Arrival Time Arriving From ____________________________________________________________ Destination in Kitchener/Waterloo No. in party DEPARTURE INFORMATION: ____________________________________________________________ Surname First name ____________________________________________________________ Toronto Departure Date Airline Flight # ____________________________________________________________ Departure Time Flight # Destination ____________________________________________________________ Pickup From No. in party ____________________________________________________________ Signature Date Send or Fax to: Airways Transit 99A Northland Road Waterloo, Ontario Canada, N2V 1Y8 Fax: (519) 886-2141 Telephone: (519) 886-2121 -----------------------------cut form here-------------------------------- ACCOMMODATIONS: There is a limited block of rooms set aside on a first-come first-serve basis at the Waterloo Inn for the evenings of August 10, 11, 12 and 13, and at the Comfort Inn for the evenings of August 9, 10, 11, 12 and 13. Please note that the Waterloo Inn is sold out for the evening of August 9. COMFORT INN Address: 190 Weber Street North, Waterloo, Ontario, Canada N2J 3H4 Phone: (519) 747-9400 Rate: $80 Cdn plus taxes/night for a single or double room Please quote "ECC 2003" when making your reservation Availability: Evenings of August 9, 10, 11, 12, 13 Cut-off date: July 7, 2003 WATERLOO INN Address: 475 King Street North, Waterloo, Ontario, Canada N2J 2Z5 Phone: (519) 884-0222 Fax: (519) 884-0321 Toll Free: 1-800-361-4708 Website: www.waterlooinn.com Rate: $118 Cdn plus taxes/night for a single or double room Please quote "ECC 2003" when making your reservation Availability: Evenings of August 10, 11, 12, 13 Cut-off date: June 29, 2003 Other hotels close to the University of Waterloo are: UNIVERSITY OF WATERLOO CONFERENCE CENTRE (on-campus accommodation; no air conditioning) Ron Eydt Village, Box 16610, Waterloo, Ontario, Canada N3J 4C1 Phone: 519-884-5400, 519-746-7599 Website: www.conferences.uwaterloo.ca (see "Room Registration") Approx rate: $52 Cdn plus taxes/night DESTINATION INN 547 King Street North, Waterloo, Ontario, Canada N2L 5Z7 Phone: (519) 884-0100 Website: www.destinationinn.com Approx rate: $73 Cdn plus taxes/night BEST WESTERN INN St. Jacobs Country Inn 50 Benjamin Road East, Waterloo, Ontario, Canada N2V 2J9 Phone: (519) 884-9295 Website: www.stjacobscountryinn.com Approx rate: $129 Cdn plus taxes/night THE WATERLOO HOTEL 2 King Street North, Waterloo, Ontario, Canada N2J 2W7 Phone: (519) 885-2626 Website: www.countryinns.org/inn_waterloo.html Approx rate: $120-160 Cdn plus taxes/night HOTEL TO CONFERENCE TRANSPORTATION: A shuttle to/from the campus will be available each day of the conference from the Waterloo Inn and Comfort Inn only. Place and times for pickup and drop-off will be provided in the final announcement. FURTHER INFORMATION: For further information or to return your Registration, please contact: Mrs. Adrienne Richter Department of Combinatorics & Optimization University of Waterloo Waterloo, Ontario, Canada N2L 3G1 e-mail: ecc2003 at math.uwaterloo.ca Fax: (519) 725-5441 Phone: (519) 888-4027 If you did not receive this announcement by email and would like to be added to the mailing list for the third announcement, please send email to ecc2003 at math.uwaterloo.ca. The announcements are also available from the web site www.cacr.math.uwaterloo.ca ------------------------------------------------------------------ --- end forwarded text -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From schear at attbi.com Wed Mar 12 11:42:45 2003 From: schear at attbi.com (Steve Schear) Date: Wed, 12 Mar 2003 08:42:45 -0800 Subject: Tools for anonymous blogging In-Reply-To: <20030312021449.23198.qmail@nym.alias.net> Message-ID: <5.1.0.14.2.20030311231600.042ca110@mail.attbi.com> At 02:14 AM 3/12/2003 +0000, Dylan Knobold wrote: >Greetings cryptographers, > > I would like to ask your assistance in setting up a weblog that >cannot easily be traced to my real identity. I have surveyed the >existing tools and do not find one that fits my needs well. For my >proposed blog, I would graciously accept volunteer hosting, but I >think it's also worth thinking improving tools so anonymous blogging >can be accessible to many. > > Finally, while remailers contend against the deeply entrenched >email infrastructure, blog publishing tools are still in their >infancy, and most people do not find it particularly convenient to >publish a blog. In addition, good hosting costs money; the free >hosting services are ad-ridden, in many cases badly. Retain the services of virtual hosting firm which accepts e-gold for payment. Prevailing costs about US$10.00/month. E-gold accounts can be opened without providing accurate meatspace identity info. If you create the account using a viable web proxy then no trail back to your originating IP should be generated. If you are especially paranoid, you can fund one e-gold account (at http://www.e-gold.com) using a relatively anonymous payment method (e.g., a money order), open an anonymous ALTA/DMT account (also using a web proxy) at http://dmt.orlingrabbe.com, transfer e-gold funds into the ALTA/DMT account and then back out to another e-gold account (also opened via a web proxy) which you use to open and pay for the virtual hosting account. Sort of Chaumian money mix. :) > Given these goals, what tools are available today? The most obvious >is to use an anonymizing Web proxy such as anonymizer.com in >conjunction with a public blog hosting service such as LiveJournal. >However, this approach doesn't give me a warm and fuzzy feeling. In >particular, anonymizer.com is a single point of vulnerability, a >one-stop shop if you will for spy agencies, conveniently pre-filtered >to include only those who feel that leaking identity information is >worth thirty bucks a year to protect (the free version is little more >than a teaser for the pay service). I suggest using JAP (Java Anonymizing Proxy), a open source P2P proxy cloud, operated out of the University of Technology Dresden http://anon.inf.tu-dresden.de/index_en.html Its free, relatively reliable and moderately good performance (I routinely get >6KB/sec bandwidth). For relatively secure IRC communication I suggest you check out IIP, the Invisible Internet Proxy. Its easy to use with most IRC clients. See my separate posting to the list announcing the availability of IIP 1.1.0. steve "Liberty cannot be preserved without a general knowledge among the people... Be not intimidated, therefore, by any terrors, from publishing with the utmost freedom...nor suffer yourselves to be wheedled out of your liberty by any pretenses of politeness, delicacy, or decency. These, as they are often used, are but three different names for hypocrisy, chicanery, and cowardice." -- John Adams --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From schear at attbi.com Wed Mar 12 13:25:43 2003 From: schear at attbi.com (Steve Schear) Date: Wed, 12 Mar 2003 10:25:43 -0800 Subject: IIP 1.1.0 released (reformatted as plain text) Message-ID: <5.1.0.14.2.20030312102455.047f38c8@mail.attbi.com> Changes: In this version the installation for Unix is enhanced, entropy generation is improved and a few bugs are fixed. Background The Invisible IRC Project (IIP) was originally created so that people interested in facilitating privacy and free speech could work to these ends in an equally secure and anonymous environment. It has now become a haven for anyone seeking anonymous, encrypted Internet Relay Chat. The project's inspiration arose primarily from a shared interest in the Freenet Project and a desire to provide the real-time communications capabilities that Freenet could not. IIP features: ? Perfect Forward Security using Diffie-Hellman Key Exchange Protocol ? Constant session key rotation ? 128 bit Blowfish node-to-node encryption ? 160 bit Blowfish end-to-end encryption ? Chaffed traffic to thwart traffic analysis ? Secure dynamic routing using cryptographically signed namespaces for node identification ? Node level flood control ? Seamless use of standard IRC clients ? Gui interface ? Peer distributed topology for protecting the identity of users ? Completely modular in design, all protocols are plug-in capable http://www.invisiblenet.net/iip/aboutMain.php "The whole aim of practical politics is to keep the populace alarmed -- and thus clamorous to be led to safety -- by menacing it with an endless series of hobgoblins, all of them imaginary." -- H.L. Mencken --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From lynn at garlic.com Wed Mar 12 13:50:06 2003 From: lynn at garlic.com (Anne & Lynn Wheeler) Date: Wed, 12 Mar 2003 11:50:06 -0700 Subject: Encryption of data in smart cards In-Reply-To: <20030311050917.GA7031@atc.tcs.co.in> Message-ID: <4.2.2.20030312113655.00a84cd0@mail.earthlink.net> At 10:39 AM 3/11/2003 +0530, N. Raghavendra wrote: >Can anyone point me to sources about encryption of data in smart >cards. What I am looking for is protocols for encrypting sensitive >data (e.g., medical information about the card-holder), so that >even if the card falls into malicious hands, it won't be easy to >read that data. a lot of cards use derived (symmetric) keys ... similar to the derived key per transaction X9 standards. they are used to protect data from outside examination and in multi-function cards to provide protection domains between the different applications on a card. typically there is a system wide key that you would find in a secure terminal (like transit systems) that read data, decrypt it, update it, re-encrypt it and write it back to the card. this handles situations involving attacks with fraudulent readers that load fraudulent value on the card. given the possibility of a brute force attack on the infrastructure (aka getting the data out of one card, and finding the master system key) ... many systems go to some form of derived keys. They typically amount to one-way function that combines the system-wide key with something like an account number from the card that results in the derived key. A brute force attack on the card data .... will only result in obtaining the card-specific, derived key .... and not the system-wide master key. All secured readers, knowing the system wide key and some card identification can always calculate the derived key for a card. misc. derived key stuff ... http://www.garlic.com/~lynn/aadsm3.htm#cstech8 cardtech/securetech & CA PKI http://www.garlic.com/~lynn/aepay10.htm#33 pk-init draft (not yet a RFC) http://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security requested http://www.garlic.com/~lynn/2002f.html#22 Biometric Encryption: the solution for network intruders? -- Anne & Lynn Wheeler http://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From cox-work at djehuti.com Wed Mar 12 14:10:48 2003 From: cox-work at djehuti.com (Ben Cox) Date: 12 Mar 2003 14:10:48 -0500 Subject: Tools for anonymous blogging In-Reply-To: <5.1.0.14.2.20030311231600.042ca110@mail.attbi.com> References: <5.1.0.14.2.20030311231600.042ca110@mail.attbi.com> Message-ID: <1047496248.1486.9.camel@cox-pc.spinnakernet.com> On Wed, 2003-03-12 at 11:42, Steve Schear wrote: > Retain the services of virtual hosting firm which accepts e-gold for > payment. Prevailing costs about US$10.00/month. E-gold spammed me the other day, with a bogus HTML "about your account" type message. Why exactly should I consider doing business with them? -- Ben --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From schear at attbi.com Wed Mar 12 14:49:56 2003 From: schear at attbi.com (Steve Schear) Date: Wed, 12 Mar 2003 11:49:56 -0800 Subject: Tools for anonymous blogging In-Reply-To: <1047496248.1486.9.camel@cox-pc.spinnakernet.com> References: <5.1.0.14.2.20030311231600.042ca110@mail.attbi.com> <5.1.0.14.2.20030311231600.042ca110@mail.attbi.com> Message-ID: <5.1.0.14.2.20030312113931.048946b8@mail.attbi.com> At 02:10 PM 3/12/2003 -0500, you wrote: >On Wed, 2003-03-12 at 11:42, Steve Schear wrote: > > Retain the services of virtual hosting firm which accepts e-gold for > > payment. Prevailing costs about US$10.00/month. > >E-gold spammed me the other day, with a bogus HTML "about your account" >type message. > >Why exactly should I consider doing business with them? Are you certain that the email originated with E-gold? Their policy is not to email ads nor contact their clients via email. Check the links and headers. Unlike credit cards and banking institutions E-gold transactions are non-repudiatable. As a result, they have been a target of many fraudsters who attempt to impersonate E-gold in email ads and bogus web sites in order to trick E-gold customers into disclosing their account numbers and passwords. Once armed with this info they can proceed to quickly loot the person's account with little chance of discovery. This is a downside of pseudo-anonymity. Many people are unprepared to protect their authentication data. The have come to depend on regulators to protect them from themselves. In the case of E-gold their pleas almost always fall on deaf ears, and law enforcement has also been of little help. steve --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From cato at df.lth.se Wed Mar 12 17:08:26 2003 From: cato at df.lth.se (Krister Walfridsson) Date: Wed, 12 Mar 2003 23:08:26 +0100 (MET) Subject: Encryption of data in smart cards In-Reply-To: <8765qpk310.fsf@alberti.g10code.de> Message-ID: On Tue, 11 Mar 2003, Werner Koch wrote: > If you want to encrypt the > data on the card, you also need to store the key on it. And well, if > you are able to read out the data, you are also able to read out the > key (more or less trivial for most mass market cards). This is not completely true -- I have seen some high-end cards that use the PIN code entered by the user as the encryption key. And it is quite easy to do similar things on Java cards... /Krister --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ray at unipay.nl Wed Mar 12 19:55:25 2003 From: ray at unipay.nl (R. Hirschfeld) Date: Thu, 13 Mar 2003 01:55:25 +0100 Subject: Tools for anonymous blogging In-Reply-To: <5.1.0.14.2.20030312113931.048946b8@mail.attbi.com> (message from Steve Schear on Wed, 12 Mar 2003 11:49:56 -0800) References: <5.1.0.14.2.20030311231600.042ca110@mail.attbi.com> <5.1.0.14.2.20030311231600.042ca110@mail.attbi.com> <5.1.0.14.2.20030312113931.048946b8@mail.attbi.com> Message-ID: <200303130055.BAA06474@home.unipay.nl> > Date: Wed, 12 Mar 2003 11:49:56 -0800 > From: Steve Schear > > Are you certain that the email originated with E-gold? Their policy is not > to email ads nor contact their clients via email. Check the links and headers. And check the form tag's action attribute. These fraud attempts are getting sneaky--the last one I received used genuine www.e-gold.com links throughout but had:
If you decode the URL-encoded gubbish you see that it doesn't really go to e-gold at all (but rather ronald112.hypermart.net in this case). Ray --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From raghu at atc.tcs.co.in Thu Mar 13 00:46:27 2003 From: raghu at atc.tcs.co.in (N. Raghavendra) Date: Thu, 13 Mar 2003 11:16:27 +0530 Subject: Encryption of data in smart cards In-Reply-To: <20030311050917.GA7031@atc.tcs.co.in> References: <20030311050917.GA7031@atc.tcs.co.in> Message-ID: <20030313054627.GA13664@atc.tcs.co.in> On Tue, Mar 11, 2003 at 10:39:17AM +0530, N. Raghavendra wrote: > Can anyone point me to sources about encryption of data in smart > cards. What I am looking for is protocols for encrypting sensitive > data (e.g., medical information about the card-holder), so that > even if the card falls into malicious hands, it won't be easy to > read that data. Hello, My thanks to everyone who has replied to my query above. The consensus seems to be that it is not usually necessary to encrypt data stored in the card, and if one wants to do it, one should use a symmetric key which is not entirely stored in the card. Best regards, Raghu. -- N. Raghavendra | OpenPGP public key available Tata Consultancy Services | at http://www.keyserver.net/ Hyderabad | Key ID: 0x03618806 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From wk at gnupg.org Thu Mar 13 02:32:39 2003 From: wk at gnupg.org (Werner Koch) Date: Thu, 13 Mar 2003 08:32:39 +0100 Subject: Encryption of data in smart cards In-Reply-To: (Krister Walfridsson's message of "Wed, 12 Mar 2003 23:08:26 +0100 (MET)") References: Message-ID: <87isunhgbs.fsf@alberti.g10code.de> On Wed, 12 Mar 2003 23:08:26 +0100 (MET), Krister Walfridsson said: > This is not completely true -- I have seen some high-end cards that use > the PIN code entered by the user as the encryption key. And it is quite Sorry my fault, by "read out the data" I meant to do this using a side channel or with a hardware probe. 4 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From rah at shipwright.com Thu Mar 13 09:57:43 2003 From: rah at shipwright.com (R. A. Hettinga) Date: Thu, 13 Mar 2003 09:57:43 -0500 Subject: Recognizing the Dance on the Dotted Line Message-ID: March 13, 2003 Recognizing the Dance on the Dotted Line By IAN AUSTEN IN the movies, biometrics can give a high-tech sheen to an ordinary task like establishing that someone is who he says he is. Lasers scan retinas or glass plates read fingerprints before hidden machinery will open doors, which invariably slide rather than swing. But a system to verify the identity of credit-card shoppers could soon be based on an old-fashioned, even ancient, piece of biometric information: the handwritten signature. "Signatures are a biometric," said Thomas G. Zimmerman, a computer scientist at the I.B.M. Almaden Research Center in San Jose, Calif. "The dance of your hand on the paper is unique to you." Biometric handwriting recognition could eventually free shoppers from carrying credit or debit cards. At the very least, proponents say, a signature system could make stolen cards useless and could reduce fraud in several other ways. Biometric handwriting systems have little in common with current methods, in which the signature a shopper scribbles on a paper receipt or a digital tablet is compared with the signature on the back of the card. It doesn't take a master forger to produce a signature that can pass muster with a harried cashier. Criminals who forge cards simply put their own signatures on the back. By contrast, in biometric systems the appearance of the signature matters little. Instead, it is the act of signing that counts. Decades of research at I.B.M. Almaden, Mr. Zimmerman said, have shown that signing is done almost unconsciously. "When you sign your name, you are moving your hand two times faster than you can control it," Mr. Zimmerman said. "But a forger is signing in a very controlled motion. They can't reproduce the cadence of the dance that your hand does." Shai Waisel, chief executive officer of WonderNet, a company in Israel, said development of its handwriting authentication system, now known as Penflow, began in part from a simple observation. "You can sign your name without looking," Mr. Waisel said. "People are signing their names without knowing what they're doing." The idea of using handwriting dynamics to authenticate signatures is not new. For several years, I.B.M. has sold a system based on the principle to banks and other financial institutions to authorize computer transfers of large amounts of money. But such systems use costly, specially made pens and require the transfer of relatively large amounts of data, making them impractical for retailers with thousands of cash registers. Two related factors, however, have prompted recent interest in developing dynamic signature systems for stores. Legislation passed in the fall of 2000 that gave electronic signatures the same legal validity as ones made with pen and paper prompted many retailers to install digital signature pads. Currently the electronic pads' main function is to provide a substitute for paper records of credit card sales. But I.B.M., WonderNet and the Communication Intelligence Corporation (the company behind Jot handwriting software for digital assistants) all say the pads can also be used to provide signature verification. While the three companies' systems vary in some details, they all take the same basic approach. Before using any of them, customers will have to create three to six sample autographs using a digital pad. Software will carefully time every movement and change of direction of the pen. When a customer signs a digital pad while making a purchase, the timing and pen direction will be matched against the stored record. (More sophisticated pads can add pen pressure and other factors into the comparison.) If such systems were widely adopted, Mr. Zimmerman said, it would be possible for people to abandon plastic credit cards. When making a purchase, a shopper would identify himself by typing a number (a telephone number, say) on a keypad at the cash register, then sign a digital pad. At the very least, Mr. Waisel of WonderNet said, credit card companies could eliminate the signatures and other personal details from cards, making them less attractive to thieves. Guido DiGregorio, chief executive of Communication Intelligence, said that online sales would be one of the first areas to realize security improvements from signature verification systems. A shopper could place a hand-held computer in a cradle connected to a PC and verify purchases by autographing its handwriting recognition area. Those with wireless Internet connections could bypass desk-bound computers altogether. Right now, the technology companies seem to be well ahead of retailers, at least in the United States. Richard Mader, executive director of the National Retail Federation's technical standards branch, said he had not heard the idea discussed within his industry. But at least in theory, he said, dynamic handwriting analysis might appeal more to merchants than systems that use iris scans or fingerprints because it requires no additional hardware at cash registers in stores that already digitally capture signatures. Mr. Mader said retailers would have to be convinced that the systems would not mistakenly reject legitimate cardholders. Whether related to credit or identity, such mistakes could mean lost sales and damaged customer relations. Unlike fingerprints, signatures and how they are written can vary. A shopper holding a cranky child will not sign the same way he or she might while at a desk. Similarly, people's signature patterns gradually change over time. Communication Intelligence tries to limit a customer's ability to vary his signature as much as possible, Mr. DiGregorio said. False rejections, he suggested, could be avoided simply by having clerks ask for another piece of identification. At WonderNet, variations are welcomed as a way to increase security by building a more nuanced profile of a customer's handwriting dynamics, Mr. Waisel said. Revelers, however, might be advised to carry plenty of cash if handwriting verification becomes the norm. All three companies agree that there is a situation that no system will be able to handle. "If you're really drunk and having trouble signing," Mr. Zimmerman said, "I've got to reject that." -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From lynn at garlic.com Thu Mar 13 10:22:47 2003 From: lynn at garlic.com (Anne & Lynn Wheeler) Date: Thu, 13 Mar 2003 08:22:47 -0700 Subject: Encryption of data in smart cards In-Reply-To: <20030313054627.GA13664@atc.tcs.co.in> References: <20030311050917.GA7031@atc.tcs.co.in> <20030311050917.GA7031@atc.tcs.co.in> Message-ID: <4.2.2.20030313081605.00b02100@mail.earthlink.net> there are a large number of different kinds of cards .... however the most prevalent smartcards (in terms of numbers deployed) are the institutional smartcards that tend to include stored-value of various kinds that are supported at various kinds of merchant &/or transient terminals (i.e. subway turnstyles). the transient tend to be proximity/contactless (aka iso14443) rather than contact (aka iso7816). these infrastructures use secret keys .... especially derived secret keys ... that are designed to protect the infrastructure from various kinds of attacks by others (including the people that posses the card) ... typically fraudulent value substitution on the card. -- Anne & Lynn Wheeler http://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From notable at mindspring.com Thu Mar 13 10:15:56 2003 From: notable at mindspring.com (Notable Software) Date: Thu, 13 Mar 2003 10:15:56 -0500 Subject: Scientists question electronic voting References: <3E63FF95.708674AF@nma.com> <5.2.0.9.0.20030306162648.01d3ae40@pop.ix.netcom.com> <007401c2e5d1$4f4f7c50$4401b041@youru2wocurx4t> <3E6A9CE0.65302BE4@nma.com> <016001c2e72d$92dbfb30$4401b041@youru2wocurx4t> <3E6E249F.51CA062F@nma.com> Message-ID: <00db01c2e976$c150b5a0$cae1b93f@youru2wocurx4t> Ed, The whole idea of photographing paper ballots is a straw man. It is akin to saying that people will just run through red lights anyway so we shouldn't place them at intersections. I agree that we need to improve voting systems, but the current trend toward self-auditing devices is going backward rather than forward in this regard. In 2002 it was electronic ballots (on cartridges) that were misplaced (to the tune of over 100,000 votes) in Florida. Apparently you neglected to read the newspapers last fall. I didn't see any improvement in what was purchased over what they had before, unless you want to call tens of millions of extra dollars in expenditures an improvement. The salient requirement of Democratic elections is that the voters must be assured that their ballots are recorded and tabulated as cast. If the process is such that it can only be understood by a team of scientists with Ph.D.'s, the average citizen can have no confidence that their voice is being heard. I have never said that the paper balloting solution is a perfect one, but it provides assurances in a human- accessible format that is a considerable improvement over both the black-box systems and the chad-based ones. If you can devise a system that is equally user- friendly and has the same ability for independent auditing, then please do so. Rebecca Mercuri. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From kelsey.j at ix.netcom.com Thu Mar 13 13:13:23 2003 From: kelsey.j at ix.netcom.com (John Kelsey) Date: Thu, 13 Mar 2003 13:13:23 -0500 Subject: Encryption of data in smart cards In-Reply-To: References: <8765qpk310.fsf@alberti.g10code.de> Message-ID: <5.2.0.9.0.20030313131055.0442a600@pop.ix.netcom.com> At 11:08 PM 3/12/03 +0100, Krister Walfridsson wrote: ... >This is not completely true -- I have seen some high-end cards that use >the PIN code entered by the user as the encryption key. And it is quite >easy to do similar things on Java cards... With any kind of reasonable PIN length, though, this isn't all that helpful, because of the small set of possible PINs. And smartcards don't generally have a lot of processing power, so making the PIN->key mapping expensive doesn't help much, either. > /Krister --John Kelsey, kelsey.j at ix.netcom.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ptrei at rsasecurity.com Thu Mar 13 13:23:34 2003 From: ptrei at rsasecurity.com (Trei, Peter) Date: Thu, 13 Mar 2003 13:23:34 -0500 Subject: Encryption of data in smart cards Message-ID: > John Kelsey[SMTP:kelsey.j at ix.netcom.com] > > > At 11:08 PM 3/12/03 +0100, Krister Walfridsson wrote: > > ... > >This is not completely true -- I have seen some high-end cards that use > >the PIN code entered by the user as the encryption key. And it is quite > >easy to do similar things on Java cards... > > With any kind of reasonable PIN length, though, this isn't all that > helpful, because of the small set of possible PINs. And smartcards don't > generally have a lot of processing power, so making the PIN->key mapping > expensive doesn't help much, either. > > > /Krister > > --John Kelsey, kelsey.j at ix.netcom.com > Every PINned SC I've seen has a very limited (typically 3) number of failed attempts before it locks itself up. Once it's locked up, it can only be reactivated by an administrator PIN, which is held at much higher security by the issuer, and not available to the card user. Peter --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From nop at trapped-under-ice.com Thu Mar 13 16:48:48 2003 From: nop at trapped-under-ice.com (NOP) Date: Thu, 13 Mar 2003 13:48:48 -0800 Subject: Diffie-Hellman 128 bit Message-ID: <006201c2e9aa$54768200$6f42420a@lanwan> I am looking at attacks on Diffie-Hellman. The protocol implementation I'm looking at designed their diffie-hellman using 128 bit primes (generated each time, yet P-1/2 will be a prime, so no go on pohlig-hellman attack), so what attacks are there that I can look at to come up with either the logarithm x from (a=g^x mod p) or the session key that is calculated. A brute force wouldn't work, unless I know the starting range. Are there any realistic attacks on DH parameters of this size, or is theoretically based on financial computation attacks? Thanks for your time. Lance James --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From lynn at garlic.com Thu Mar 13 16:08:04 2003 From: lynn at garlic.com (Anne & Lynn Wheeler) Date: Thu, 13 Mar 2003 14:08:04 -0700 Subject: Encryption of data in smart cards In-Reply-To: <5.2.0.9.0.20030313131055.0442a600@pop.ix.netcom.com> References: <8765qpk310.fsf@alberti.g10code.de> Message-ID: <4.2.2.20030313115954.00a89e80@mail.earthlink.net> At 01:13 PM 3/13/2003 -0500, John Kelsey wrote: >At 11:08 PM 3/12/03 +0100, Krister Walfridsson wrote: > >... >>This is not completely true -- I have seen some high-end cards that use >>the PIN code entered by the user as the encryption key. And it is quite >>easy to do similar things on Java cards... > >With any kind of reasonable PIN length, though, this isn't all that >helpful, because of the small set of possible PINs. And smartcards don't >generally have a lot of processing power, so making the PIN->key mapping >expensive doesn't help much, either. > >> /Krister > >--John Kelsey, kelsey.j at ix.netcom.com note however, that PIN could be possibly in infrastructure with real secret key and encryption done with derived key. the derived key one-way function is attempting to protect the infrastructure-wide secret key from brute force key search on specific piece of data. The issue is how many bits in a PIN is required to protect the secret key in a one-way function (involving the secret key and the PIN). A simple derived key is sufficient using the secret key and public account number. Adding a (privately known, card specific) PIN to such a derived key function: 1) doesn't increase the ease of attack on the secret key 2) doesn't affect brute force attack on the derived key 3) makes it harder to use a lost/stolen card -- Anne & Lynn Wheeler http://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From remailer at eocto.net Thu Mar 13 17:25:46 2003 From: remailer at eocto.net (Hermes Remailer) Date: Thu, 13 Mar 2003 16:25:46 -0600 Subject: Microsoft: Palladium will not limit what you can run Message-ID: <0365df8f385989030d23bbd42da18282@eocto.net> The following comes from Microsoft's recent mailing of their awkwardly named "Windows Trusted Platform Technologies Information Newsletter March 2003". Since they've abandoned the Palladium name they are forced to use this cumbersome title. Hopefully this will shed light on the frequent claims that Palladium will limit what programs people can run, or "take over root" on your computer, and similar statements by people who ought to know better. It is too much to expect these "experts" to publicly revise their opinions, but perhaps going forward they can begin gradually to bring their claims into line with reality. ======================================================================= An Open and Interoperable Foundation for Secure Computing By John Manferdelli, General Manager, Windows Trusted Platform Technologies Microsoft Corporation The Next-Generation Secure Computing Base (NGSCB) is part of Microsoft?s long-term effort to deliver on our vision of Trustworthy Computing. We are pleased that independent observers and many journalists continue to show interest in NGSCB and what it will enable. While much of the response has been positive, especially among analysts, security experts and people concerned with privacy, we recognize that there are still questions about NGSCB, and still a great deal of misunderstanding and speculation around our intentions. In this newsletter I?d like to set the record straight on one of the more common and persistent concerns, specifically that the NGSCB architecture will limit the things that people can do with computers by forcing them to run only ?approved? software, or software that is digitally signed. In fact, NGSCB intends to do no such thing. It is important to understand that NGSCB is operating system technology. Just as anyone can build a program to run on Windows today using widely-published APIs, they will be able to build new programs tomorrow that take advantage of the NGSCB architecture when it is included in a future version of Windows. How these new programs are built ? and what they will require of the user ? are questions for the application developer to answer. But NGSCB inherently has no requirements forcing approval of code, digital signatures, or any other such qualifying mechanism. NGSCB will run any software that is built to take advantage of its capabilities, and it will only run with the user?s approval. Moreover, even when NGSCB is running, programs that are not using NGSCB features will operate just as they do today. It is true that NGSCB functionality can be used by an application (written by anyone) to enforce a policy that is agreed to by a user and a provider, including policies related to other software that the application can ?load.? Such a policy could, for example: - Govern how private information is used by software - Prevent malicious code from snooping private information, stealing keys, or corrupting important information (i.e., banking transaction data) - Govern how intellectual property running inside the application can be used Policies like these could be set by the user at his or her sole discretion, or they could be set in a manner mutually agreed to by a user and one or more parties. However, NGSCB does no screening of application components or content, and if any ?screening? took place, it would be within the isolated bounds of an application running under NGSCB. Moreover, no NGSCB application can ?censor? content played by another NGSCB application. Policy in the Hands of the User The extent to which the NGSCB will be beneficial will largely depend on the wisdom of the policies that people choose to embrace. We are designing NGSCB to give individuals visibility to the policies available to them in the programs they run, as well as control over how they proceed. By offering new features to enhance privacy, security and system integrity, we can foresee NGSCB enabling a wide range of beneficial scenarios, including the following: - Helping to protect personal medical information - Preventing a bad application from interfering with a banking transaction - Preventing viruses from harming programs or data - Preventing unauthorized people or applications from accessing a computer remotely and carrying out unauthorized actions My colleagues and I appreciate your interest in the work we are doing. We know we still have a lot of work to do, and value the beneficial influence that discussion and debate provide as we strive to deliver trustworthy computing technologies. - John Manferdelli --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From jays at panix.com Thu Mar 13 21:45:43 2003 From: jays at panix.com (Jay Sulzberger) Date: Thu, 13 Mar 2003 21:45:43 -0500 (EST) Subject: Microsoft: Palladium will not limit what you can run In-Reply-To: <0365df8f385989030d23bbd42da18282@eocto.net> References: <0365df8f385989030d23bbd42da18282@eocto.net> Message-ID: On Thu, 13 Mar 2003, Hermes Remailer wrote: > The following comes from Microsoft's recent mailing of their awkwardly > named "Windows Trusted Platform Technologies Information Newsletter > March 2003". Since they've abandoned the Palladium name they are forced > to use this cumbersome title. > > Hopefully this will shed light on the frequent claims that Palladium will > limit what programs people can run, or "take over root" on your computer, > and similar statements by people who ought to know better. It is too > much to expect these "experts" to publicly revise their opinions, but > perhaps going forward they can begin gradually to bring their claims > into line with reality. The Xbox will not boot any free kernel without hardware modification. The Xbox is an IBM style peecee with some feeble hardware and software DRM. A Palladiated box is an IBM style peecee with serious hardware and software DRM. So, a fortiori, your claim is false. oo--JS. > > An Open and Interoperable Foundation for Secure Computing > > By John Manferdelli, General Manager, Windows Trusted Platform Technologies > Microsoft Corporation > > The Next-Generation Secure Computing Base (NGSCB) is part of Microsoft?s > long-term effort to deliver on our vision of Trustworthy Computing. We > are pleased that independent observers and many journalists continue > to show interest in NGSCB and what it will enable. While much of the > response has been positive, especially among analysts, security experts > and people concerned with privacy, we recognize that there are still > questions about NGSCB, and still a great deal of misunderstanding and > speculation around our intentions. > > In this newsletter I?d like to set the record straight on one of the more > common and persistent concerns, specifically that the NGSCB architecture > will limit the things that people can do with computers by forcing them > to run only ?approved? software, or software that is digitally signed. > In fact, NGSCB intends to do no such thing. It is important to understand > that NGSCB is operating system technology. Just as anyone can build a > program to run on Windows today using widely-published APIs, they will > be able to build new programs tomorrow that take advantage of the NGSCB > architecture when it is included in a future version of Windows. How these > new programs are built ? and what they will require of the user ? are > questions for the application developer to answer. But NGSCB inherently > has no requirements forcing approval of code, digital signatures, or > any other such qualifying mechanism. NGSCB will run any software that is > built to take advantage of its capabilities, and it will only run with > the user?s approval. Moreover, even when NGSCB is running, programs that > are not using NGSCB features will operate just as they do today. It is > true that NGSCB functionality can be used by an application (written by > anyone) to enforce a policy that is agreed to by a user and a provider, > including policies related to other software that the application can > ?load.? Such a policy could, for example: > > - Govern how private information is used by software > - Prevent malicious code from snooping private information, stealing keys, > or corrupting important information (i.e., banking transaction data) > - Govern how intellectual property running inside the application can > be used > > Policies like these could be set by the user at his or her sole > discretion, or they could be set in a manner mutually agreed to by > a user and one or more parties. However, NGSCB does no screening of > application components or content, and if any ?screening? took place, > it would be within the isolated bounds of an application running under > NGSCB. Moreover, no NGSCB application can ?censor? content played by > another NGSCB application. > > Policy in the Hands of the User > > The extent to which the NGSCB will be beneficial will largely depend on > the wisdom of the policies that people choose to embrace. We are designing > NGSCB to give individuals visibility to the policies available to them > in the programs they run, as well as control over how they proceed. By > offering new features to enhance privacy, security and system integrity, > we can foresee NGSCB enabling a wide range of beneficial scenarios, > including the following: > > - Helping to protect personal medical information > - Preventing a bad application from interfering with a banking transaction > - Preventing viruses from harming programs or data > - Preventing unauthorized people or applications from accessing a computer > remotely and carrying out unauthorized actions > > My colleagues and I appreciate your interest in the work we are doing. We > know we still have a lot of work to do, and value the beneficial influence > that discussion and debate provide as we strive to deliver trustworthy > computing technologies. > > - John Manferdelli --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From eugen at leitl.org Fri Mar 14 00:26:04 2003 From: eugen at leitl.org (Eugen Leitl) Date: Fri, 14 Mar 2003 06:26:04 +0100 (CET) Subject: Microsoft: Palladium will not limit what you can run In-Reply-To: <0365df8f385989030d23bbd42da18282@eocto.net> Message-ID: Unfortunately no one can accept in good faith a single word coming out of Redmond. Biddle has been denying Pd can be used for DRM in presentation (xref Lucky Green subsequent patent claims to call the bluff), however in recent (of this week) Focus interview Gates explicitly stated it does. This is merely a most recent lie in a long sequence of it. Operating from behind an anonymous remailer doesn't quite have the same handicap as having microsoft.com as part of your email address, but the heavy spinmeistering does reveal the origin as reliably. You can use your real emal address next time. Let's see, we have an ubiquitous built-in DRM infrastructure, developed under great expense and deployed under costs in an industry turning over every cent twice, and no-one is going to use it ("Palladium will limit what programs people can run")? Right. It's all completely voluntary. There will be no attempts whatsoever to lock-in, despite decades of attempts and considerable economic interests involved. On Thu, 13 Mar 2003, Hermes Remailer wrote: > Hopefully this will shed light on the frequent claims that Palladium will > limit what programs people can run, or "take over root" on your computer, > and similar statements by people who ought to know better. It is too > much to expect these "experts" to publicly revise their opinions, but > perhaps going forward they can begin gradually to bring their claims > into line with reality. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From jeroen at vangelderen.org Fri Mar 14 00:38:14 2003 From: jeroen at vangelderen.org (Jeroen C. van Gelderen) Date: Fri, 14 Mar 2003 00:38:14 -0500 Subject: Microsoft: Palladium will not limit what you can run In-Reply-To: Message-ID: <26663048-55DF-11D7-A0E3-000393754B1C@vangelderen.org> On Thursday, Mar 13, 2003, at 21:45 US/Eastern, Jay Sulzberger wrote: > On Thu, 13 Mar 2003, Hermes Remailer wrote: > >> The following comes from Microsoft's recent mailing of their awkwardly >> named "Windows Trusted Platform Technologies Information Newsletter >> March 2003". Since they've abandoned the Palladium name they are >> forced >> to use this cumbersome title. >> >> Hopefully this will shed light on the frequent claims that Palladium >> will >> limit what programs people can run, or "take over root" on your >> computer, >> and similar statements by people who ought to know better. It is too >> much to expect these "experts" to publicly revise their opinions, but >> perhaps going forward they can begin gradually to bring their claims >> into line with reality. > > The Xbox will not boot any free kernel without hardware modification. > > The Xbox is an IBM style peecee with some feeble hardware and software > DRM. and sold by Microsoft below cost (aka subsidized). With the expectation that you will be buying Microsoft games to offset the initial loss. (You don't have a right to this subsidy, it is up to Microsoft to set the terms here.) > A Palladiated box is an IBM style peecee with serious hardware and > software > DRM. and sold by numerous vendors. With no expectations like the ones above. > So, a fortiori, your claim is false. So, a fortiori you are comparing apples with oranges. Or you may have left out the part of your argument that bridges this gap. Obviously a vendor can restrict what kind of software runs on the hardware he sells, either by contract or trough technical means. In the latter case the consumer is of course free to circumvent the barriers, provided that he lives in a free country. If he doesn't like the vendor's policy, he is of course free to vote with his wallet. Your conclusion may or may not be warranted but it can definitely not be drawn from this 3-sentence argument. Cheers, -J -- Jeroen C. van Gelderen - jeroen at vangelderen.org "They accused us of suppressing freedom of expression. This was a lie and we could not let them publish it." -- Nelba Blandon, Nicaraguan Interior Ministry Director of Censorship --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From kelsey.j at ix.netcom.com Fri Mar 14 01:13:28 2003 From: kelsey.j at ix.netcom.com (John Kelsey) Date: Fri, 14 Mar 2003 01:13:28 -0500 Subject: Encryption of data in smart cards In-Reply-To: Message-ID: <5.2.0.9.0.20030314011154.04430a60@pop.ix.netcom.com> At 01:23 PM 3/13/03 -0500, Trei, Peter wrote: >Every PINned SC I've seen has a very limited (typically 3) number >of failed attempts before it locks itself up. Once it's locked up, it >can only be reactivated by an administrator PIN, which is held >at much higher security by the issuer, and not available to the >card user. Right. Which is good for the PIN-guessing-to-get-access attack, but not much help for the decrypting the extracted data using the PIN-generated key attack. >Peter --John Kelsey, kelsey.j at ix.netcom.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From bill.stewart at pobox.com Fri Mar 14 01:12:36 2003 From: bill.stewart at pobox.com (Bill Stewart) Date: Thu, 13 Mar 2003 22:12:36 -0800 Subject: Diffie-Hellman 128 bit In-Reply-To: <006201c2e9aa$54768200$6f42420a@lanwan> Message-ID: <5.1.1.6.2.20030313220902.02eb4568@idiom.com> At 01:48 PM 03/13/2003 -0800, NOP wrote: >I am looking at attacks on Diffie-Hellman. > >The protocol implementation I'm looking at designed their diffie-hellman >using 128 bit primes (generated each time, yet P-1/2 will be a prime, so no >go on pohlig-hellman attack), so what attacks are there that I can look at >to come up with either the logarithm x from (a=g^x mod p) or the session key >that is >calculated. A brute force wouldn't work, unless I know the starting range. >Are there any realistic >attacks on DH parameters of this size, or is theoretically based on >financial computation attacks? Google for "Odlyzko Diffie Hellman" and look at the various papers. Unless you're talking about elliptic curve versions of Diffie Hellman (and even then 128 bits probably isn't enough), 128 is way too weak. DH is similar in strength to RSA, so don't think about using less than 1024, and realistically go for 2048 or more. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From bill.stewart at pobox.com Fri Mar 14 01:32:46 2003 From: bill.stewart at pobox.com (Bill Stewart) Date: Thu, 13 Mar 2003 22:32:46 -0800 Subject: Brumley & Boneh timing attack on OpenSSL Message-ID: <5.1.1.6.2.20030313222547.02e84e40@idiom.com> From Slashdot: http://slashdot.org/article.pl?sid=03/03/14/0012214&mode=thread&tid=172 David Brumley and Dan Boneh write: "Timing attacks are usually used to attack weak computing devices such as smartcards. We show that timing attacks apply to general software systems. Specifically, we devise a timing attack against OpenSSL. Our experiments show that we can extract private keys from a OpenSSL-based server such as Apache with mod_SSL and stunnel running on a machine in the local network. Our results demonstrate that timing attacks against widely deployed network servers are practical. Subsequently, software should implement defenses against timing attacks. Our paper can be found at Stanford's Applied Crypto Group. http://crypto.stanford.edu/~dabo/abstracts/ssl-timing.html " Schmoo Group response on cryptonomicon.net http://www.cryptonomicon.net/modules.php?name=News&file=article&sid=263&mode=&order=0&thold=0 Apparently OpenSSL has code to prevent the timing attack, but it's often not compiled in (I'm not sure how much that's for performance reasons as opposed to general ignorance?) They also comment (as did somebody on Slashdot) that "this is distinct from the timing attack described in the paper by Canvel, Hiltgen, Vaudenay, and Vuagnoux last month." That one's an implementation problem and hard to exploit. http://lasecwww.epfl.ch/memo_ssl.shtml http://slashdot.org/article.pl?sid=03/02/20/1956229 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From anish at myrealbox.com Fri Mar 14 08:39:31 2003 From: anish at myrealbox.com (Anish) Date: Fri, 14 Mar 2003 13:39:31 +0000 Subject: Microsoft: Palladium will not limit what you can run Message-ID: <1047649171.abd963c0anish@myrealbox.com> Hi all, I would be really glad to know more on Pallidium .I have tried to get some info but havent been able to get much. I would be really thankful if some one could give me some pointers.This is inspite of having sat through two lectures one from Graeme Proudler(H.P. Research Labs),and Fabien Petitcolas ( Microsoft research , the title of the talk was ,A brief overview of Palladium ). thanks in advance regards anish --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From rah at shipwright.com Fri Mar 14 09:31:52 2003 From: rah at shipwright.com (R. A. Hettinga) Date: Fri, 14 Mar 2003 09:31:52 -0500 Subject: Face-Recognition Technology Improves Message-ID: The New York Times March 14, 2003 Face-Recognition Technology Improves By BARNABY J. FEDER Facial recognition technology has improved substantially since 2000, according to results released yesterday of a benchmark test by four federal government agencies involving systems from 10 companies. The data, which is the latest in a series of biannual tests overseen by the National Institute of Standards and Technology, is expected to encourage government security officers to deploy facial recognition systems in combination with fingerprinting and other biometric systems for applications like verifying that people are who they claim to be and identifying unknown people by comparing them with a database of images. But the report also highlighted continuing shortcomings, like the poor performance of recognition systems in outdoors settings in which even the best systems made correct matches to the database of images just 50 percent of the time. And it cited outcomes that it said needed more research, like the tendency of the systems to identify men better than women and older subjects better than young ones. The report was strictly a technical evaluation and did not discuss any of the privacy or civil rights concerns that have stirred opposition to the technology. Because the results of the different companies are public, the testing is also expected to become a marketing tool for those who did best, including Identix, Cognitec Systems and Eyematic Interfaces. It is expected to be especially helpful to Cognitec, a tiny German company that is not widely known in the United States, and Eyematic, a San Francisco-based company best known for capturing data from traits like facial structures, expressions and gait to create animated entertainment. ``Face recognition had been just a subdiscipline for us,'' said Hartmut Neven, chief technical officer and a founder of Eyematic. He said that domestic security needs had created a marketing opportunity that Eyematic was gearing up to chase. The results were not as positive for Viisage Technology, which had been among the leaders in 2000. Viisage said that the results, that it identified just 64 percent of the test subjects from a database of 37,437 individuals, were at odds with the strong performance it had been having with big customers, like the State of Illinois. While the government test is the largest for such technology, the number of images in the database was far below the 13 million that Viisage deals with for the Illinois Department of Motor Vehicles, where the company says it has picked thousand of individuals seeking multiple licenses under different names. ``We suspect there must have been human or software errors in how our system was interfaced with the test,'' said James Ebzery, senior vice president for sales and marketing for Viisage. While Viisage scrambles to explain its views to customers and chase down any potential problems in the test, it is taking comfort in the tendency of big companies and government agencies to perform their own testing on their own data before selecting Viisage or one of its rivals. The government's benchmarking was performed last summer but the results were not fully tabulated and analyzed until recently. The report singled out a finding that in ``reasonable controlled indoor lighting,'' the best facial recognition systems can correctly verify that a person in a photograph or video image is the same person whose picture is stored in a database 90 percent of the time. In addition, only one subject in 100 is falsely linked to an image in the data base in the top systems. The report also noted that performance has been enhanced by improving technology to rotate images taken at an angle so that the facial recognition software can be applied to a representation of a frontal view. The data examined whether facial recognition systems could help with the so-called watch list challenge, which involves determining if the person photographed is on a list of individuals who are wanted for some reason and then identifying who they are. Cognitec, the leading performer on that test, gained a 77 percent rating but its success rate fell to 56 percent when the watch list grew to 3,000. -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From astiglic at okiok.com Fri Mar 14 11:10:26 2003 From: astiglic at okiok.com (Anton Stiglic) Date: Fri, 14 Mar 2003 11:10:26 -0500 Subject: Diffie-Hellman 128 bit References: <006201c2e9aa$54768200$6f42420a@lanwan> Message-ID: <003d01c2ea44$3c6df4f0$90aa6395@p1038mobile> ----- Original Message ----- From: "NOP" To: Sent: Thursday, March 13, 2003 4:48 PM Subject: Diffie-Hellman 128 bit > I am looking at attacks on Diffie-Hellman. > > The protocol implementation I'm looking at designed their diffie-hellman > using 128 bit primes (generated each time, yet P-1/2 will be a prime, so no > go on pohlig-hellman attack), 128-bit prime DH would be trivially breakable, maybe you mean that it uses128-bit secret keys (and a larger prime, such as 512-bit prime at least)? In any case, you can probably get all the information you are looking for in this manuscript: http://crypto.cs.mcgill.ca/~stiglic/Papers/dhfull.pdf Cheers! --Anton --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From astiglic at okiok.com Fri Mar 14 11:14:27 2003 From: astiglic at okiok.com (Anton Stiglic) Date: Fri, 14 Mar 2003 11:14:27 -0500 Subject: Encryption of data in smart cards References: Message-ID: <005b01c2ea44$cc0858d0$90aa6395@p1038mobile> > > With any kind of reasonable PIN length, though, this isn't all that > > helpful, because of the small set of possible PINs. And smartcards don't > > generally have a lot of processing power, so making the PIN->key mapping > > expensive doesn't help much, either. > > > > > /Krister > > > > --John Kelsey, kelsey.j at ix.netcom.com > > > Every PINned SC I've seen has a very limited (typically 3) number > of failed attempts before it locks itself up. Once it's locked up, it > can only be reactivated by an administrator PIN, which is held > at much higher security by the issuer, and not available to the > card user. > > Peter Yes, but wasn`t the discussion about countermeasure to just reading the contents of the smart card. If you can read the encrypted data, and it`s encrypted under a key derived from a PIN, you have all the time and chances you want to try all PINs. That`s the reason why it doesn`t work. --Anton --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From schear at attbi.com Fri Mar 14 11:44:08 2003 From: schear at attbi.com (Steve Schear) Date: Fri, 14 Mar 2003 08:44:08 -0800 Subject: In-line Internet/crypto device Message-ID: <5.1.0.14.2.20030314084246.048b8548@mail.attbi.com> Apologies if this is rather old news. http://www.lantronix.com/products/eds/xport/index.html steve --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From nop at trapped-under-ice.com Fri Mar 14 14:39:50 2003 From: nop at trapped-under-ice.com (NOP) Date: Fri, 14 Mar 2003 11:39:50 -0800 Subject: Diffie-Hellman 128 bit References: <006201c2e9aa$54768200$6f42420a@lanwan> <003d01c2ea44$3c6df4f0$90aa6395@p1038mobile> Message-ID: <005901c2ea61$7a95cc40$6f42420a@lanwan> Nope, it uses 128 bit primes. I'm trying to compute the discrete logarithm and they are staying within a 128 bit GF(p) field. Sickening. Thnx. Lance ----- Original Message ----- From: "Anton Stiglic" To: "NOP" ; Sent: Friday, March 14, 2003 8:10 AM Subject: Re: Diffie-Hellman 128 bit > > ----- Original Message ----- > From: "NOP" > To: > Sent: Thursday, March 13, 2003 4:48 PM > Subject: Diffie-Hellman 128 bit > > > > I am looking at attacks on Diffie-Hellman. > > > > The protocol implementation I'm looking at designed their diffie-hellman > > using 128 bit primes (generated each time, yet P-1/2 will be a prime, so > no > > go on pohlig-hellman attack), > > 128-bit prime DH would be trivially breakable, maybe you mean that > it uses128-bit secret keys (and a larger prime, such as 512-bit prime at > least)? > > In any case, you can probably get all the information you are looking > for in this manuscript: > http://crypto.cs.mcgill.ca/~stiglic/Papers/dhfull.pdf > > Cheers! > > --Anton > > --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From derek at ihtfp.com Fri Mar 14 13:53:15 2003 From: derek at ihtfp.com (Derek Atkins) Date: 14 Mar 2003 13:53:15 -0500 Subject: Diffie-Hellman 128 bit In-Reply-To: <006201c2e9aa$54768200$6f42420a@lanwan> References: <006201c2e9aa$54768200$6f42420a@lanwan> Message-ID: Hi, I'm sorry to inform you, but a brute-force attack on a 128-bit prime is simple to mount. I don't think I can estimate the length of time to attack a prime of this length, but it wouldn't be very long. Consider that 425 bits is only about 4KMY (Kilo-MIP-Years) -- with todays 2KM+ processors you're probably talking about a week or less to crack it. Also, there aren't THAT many "strong" 128-bit primes. If you're using these numbers for real data (even if ephemeral), I would suggest using at least 512-bit ephemeral DH Primes.. But then you need some way to securely AGREE upon the ephemeral prime. How do you intend to prevent an attacker from forcing you to agree to a prime that it's already solved? -derek NOP writes: > I am looking at attacks on Diffie-Hellman. > > The protocol implementation I'm looking at designed their diffie-hellman > using 128 bit primes (generated each time, yet P-1/2 will be a prime, so no > go on pohlig-hellman attack), so what attacks are there that I can look at > to come up with either the logarithm x from (a=g^x mod p) or the session key > that is > calculated. A brute force wouldn't work, unless I know the starting range. > Are there any realistic > attacks on DH parameters of this size, or is theoretically based on > financial computation attacks? > > > Thanks for your time. > > Lance James > > > --------------------------------------------------------------------- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com -- Derek Atkins Computer and Internet Security Consultant derek at ihtfp.com www.ihtfp.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From daw at mozart.cs.berkeley.edu Fri Mar 14 14:23:51 2003 From: daw at mozart.cs.berkeley.edu (David Wagner) Date: 14 Mar 2003 19:23:51 GMT Subject: Microsoft: Palladium will not limit what you can run References: <0365df8f385989030d23bbd42da18282@eocto.net> Message-ID: Hermes Remailer wrote: >Hopefully this will shed light on the frequent claims that Palladium will >limit what programs people can run, [...] That's a strawman argument. The problem is not that Palladium will *itself* directly limit what I can run; the problem is what Palladium enables. Why are you focusing on strawmen? Why did you omit the real concerns about technology like Palladium? Palladium could enable big vendors to limit what applications I can run. Palladium could enable big vendors to behave anti-competitively. Palladium could enable big vendors to build document formats that aren't interoperable with open-source software. Palladium could be a net negative for consumers. Many of these risks are already possible today without Palladium, but Palladium may increase the risks. These risks are by no means guaranteed to occur, but they are a real risk. Shouldn't we think carefully about this technology before we deploy it? Shouldn't we at least consider these risks? --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From bear at sonic.net Fri Mar 14 16:23:31 2003 From: bear at sonic.net (bear) Date: Fri, 14 Mar 2003 13:23:31 -0800 (PST) Subject: Encryption of data in smart cards In-Reply-To: Message-ID: On Wed, 12 Mar 2003, Krister Walfridsson wrote: > >On Tue, 11 Mar 2003, Werner Koch wrote: > >> If you want to encrypt the >> data on the card, you also need to store the key on it. And well, if >> you are able to read out the data, you are also able to read out the >> key (more or less trivial for most mass market cards). > >This is not completely true -- I have seen some high-end cards that use >the PIN code entered by the user as the encryption key. And it is quite >easy to do similar things on Java cards... I've seen this too -- a little card that has its own 10key pad so you can enter your key directly to the card, and a little "purge" button next to the zero so you can tell it to forget the key you entered after each use. Also a red LED to tell you that it was "up" with a key entered, and that you needed to purge it before sticking it back in your wallet. The guy would enter his PIN, stick the card in the PCMCIA slot, and the machine would unlock. Slick little device, actually. Now can we get one that uses more than 5 digits for a key? Bear --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From rah at shipwright.com Fri Mar 14 18:06:32 2003 From: rah at shipwright.com (R. A. Hettinga) Date: Fri, 14 Mar 2003 18:06:32 -0500 Subject: Recent IOTP and ECML publiccations Message-ID: --- begin forwarded text Status: RO Date: Fri, 14 Mar 2003 13:56:25 -0700 From: lynn.wheeler at firstdata.com Subject: Recent IOTP and ECML publiccations To: epay at ca0.net, internet-payments at ls.fstc.org 3506 I Requirements and Design for Voucher Trading System (VTS), Eastlake D., Fujimura K., 2003 (15pp) (.txt=30945) (was draft-ietf-trade-drt-requirements-04.txt) 3505 I Electronic Commerce Modeling Language (ECML): Version 2 Requirements, Eastlake D., 2003 (8pp) (.txt=13915) (was draft-ietf-trade-ecml2-req-05.txt) 3504 I Internet Open Trading Protocol (IOTP) Version 1, Errata, Eastlake D., 2003 (6pp) (.txt=8655) (See Also 2801, 2802, 2803) (was draft-ietf-trade-iotp-v1-errata-01.txt) reference URL at rfcindex: http://www.garlic.com/~lynn/rfcidx11.htm#3504 http://www.garlic.com/~lynn/rfcidx11.htm#3505 http://www.garlic.com/~lynn/rfcide11.htm#3506 -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm --- end forwarded text -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From nikitab at cs.berkeley.edu Fri Mar 14 19:48:35 2003 From: nikitab at cs.berkeley.edu (Nikita Borisov) Date: Fri, 14 Mar 2003 16:48:35 -0800 Subject: Encryption of data in smart cards References: Message-ID: <3E727863.8090507@cs.berkeley.edu> Trei, Peter wrote: >>John Kelsey[SMTP:kelsey.j at ix.netcom.com] >>At 11:08 PM 3/12/03 +0100, Krister Walfridsson wrote: >>>This is not completely true -- I have seen some high-end cards that use >>>the PIN code entered by the user as the encryption key. And it is quite >>>easy to do similar things on Java cards... >> >>With any kind of reasonable PIN length, though, this isn't all that >>helpful, because of the small set of possible PINs. And smartcards don't >>generally have a lot of processing power, so making the PIN->key mapping >>expensive doesn't help much, either. > > Every PINned SC I've seen has a very limited (typically 3) number > of failed attempts before it locks itself up. Once it's locked up, it > can only be reactivated by an administrator PIN, which is held > at much higher security by the issuer, and not available to the > card user. I think John's point is still valid: encryption is only necessary to protect against people who bypass the standard API and somehow extract the data (microscopes, side channels?). In that case, the lock-out feature is irrelevant, and a short PIN is not much of a barrier. - Nikita --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From nop at trapped-under-ice.com Fri Mar 14 21:32:20 2003 From: nop at trapped-under-ice.com (NOP) Date: Fri, 14 Mar 2003 18:32:20 -0800 Subject: Diffie-Hellman 128 bit References: <006201c2e9aa$54768200$6f42420a@lanwan> Message-ID: <00b701c2ea9b$1b086280$6f42420a@lanwan> Well, I'm attacking a protocol, I know the rules of DH parameters, and the issue here is I'm trying to solve x, brute forcing that in the 128 bit range can be difficult, and x doesn't have to be a prime. (a = g^x mod P). Their primes are 128 bit primes, as well as their pubkeys, I've done some tests on their prime, and all perform under this method of (p-1)/2 = prime. This eliminates the pohlig-hellman discrete logarithm attack, but I'm trying to learn the Gaussian integer method. Lance James ----- Original Message ----- From: "Derek Atkins" To: "NOP" Cc: Sent: Friday, March 14, 2003 10:53 AM Subject: Re: Diffie-Hellman 128 bit > Hi, > > I'm sorry to inform you, but a brute-force attack on a 128-bit prime > is simple to mount. I don't think I can estimate the length of time > to attack a prime of this length, but it wouldn't be very long. > Consider that 425 bits is only about 4KMY (Kilo-MIP-Years) -- with > todays 2KM+ processors you're probably talking about a week or less to > crack it. Also, there aren't THAT many "strong" 128-bit primes. > > If you're using these numbers for real data (even if ephemeral), I > would suggest using at least 512-bit ephemeral DH Primes.. But then > you need some way to securely AGREE upon the ephemeral prime. > > How do you intend to prevent an attacker from forcing you to agree to > a prime that it's already solved? > > -derek > > NOP writes: > > > I am looking at attacks on Diffie-Hellman. > > > > The protocol implementation I'm looking at designed their diffie-hellman > > using 128 bit primes (generated each time, yet P-1/2 will be a prime, so no > > go on pohlig-hellman attack), so what attacks are there that I can look at > > to come up with either the logarithm x from (a=g^x mod p) or the session key > > that is > > calculated. A brute force wouldn't work, unless I know the starting range. > > Are there any realistic > > attacks on DH parameters of this size, or is theoretically based on > > financial computation attacks? > > > > > > Thanks for your time. > > > > Lance James > > > > > > --------------------------------------------------------------------- > > The Cryptography Mailing List > > Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com > > -- > Derek Atkins > Computer and Internet Security Consultant > derek at ihtfp.com www.ihtfp.com > > --------------------------------------------------------------------- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com > --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From sidney at sidney.com Fri Mar 14 23:18:16 2003 From: sidney at sidney.com (Sidney Markowitz) Date: Sat, 15 Mar 2003 17:18:16 +1300 Subject: Face-Recognition Technology Improves References: Message-ID: <005c01c2eaa9$e7b6e190$7901a8c0@sidora> > In addition, only one subject in 100 is falsely linked > to an image in the data base in the top systems. Wow, 99% accuracy for false positives! That means only a little more than 750000 people a year mistakenly detained for questioning in Atlanta HartsField Airport (ATL), and even fewer at the less busy airports (source Airports Council International, 10 Busiest Airports in US by Number of Passengers, 2001). -- sidney markowitz sidney at sidney.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From bear at sonic.net Sat Mar 15 03:40:31 2003 From: bear at sonic.net (bear) Date: Sat, 15 Mar 2003 00:40:31 -0800 (PST) Subject: Diffie-Hellman 128 bit In-Reply-To: <005901c2ea61$7a95cc40$6f42420a@lanwan> Message-ID: On Fri, 14 Mar 2003, NOP wrote: >Nope, it uses 128 bit primes. I'm trying to compute the discrete logarithm >and they are staying within a 128 bit GF(p) field. Sickening. > >Thnx. > >Lance If they're using 128-bit primes, you don't really need to look for breaks - just throw a cpu at it and you're done. Bear --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From nobody at cryptofortress.com Sat Mar 15 04:31:35 2003 From: nobody at cryptofortress.com (Anonymous) Date: Sat, 15 Mar 2003 03:31:35 -0600 (CST) Subject: Microsoft: Palladium will not limit what you can run Message-ID: <1ef9b04f5c9d4253c6159e8948f2c5bb@remailer.cryptofortress.com> Eugen Leitl writes: > Unfortunately no one can accept in good faith a single word coming out of > Redmond. Biddle has been denying Pd can be used for DRM in presentation > (xref Lucky Green subsequent patent claims to call the bluff), however in > recent (of this week) Focus interview Gates explicitly stated it does. I don't know what Gates said in this "Focus interview" but you have misstated the history here. Microsoft has never denied that Palladium can be used for DRM. Rather, the issue with regard to Lucky Green's supposed patent application (whatever happened to that, anyway?) was whether Palladium would be used for software copy protection. Microsoft said that they couldn't think of any way to use it for that purpose. See http://www.mail-archive.com/cryptography at wasabisystems.com/msg02554.html. > Let's see, we have an ubiquitous built-in DRM infrastructure, developed > under great expense and deployed under costs in an industry turning over > every cent twice, and no-one is going to use it ("Palladium will limit > what programs people can run")? Microsoft's point with regard to DRM has always been that Palladium had other uses besides that one which everyone was focused on. Obviously they fully expect people to use the technology. I'm not sure where you get the part about it being deployed under costs. Is this more of the XBox analogy? That's a video game system, where the economics are totally dissimilar to commodity PC's. All video game consoles are sold under cost today. PCs generally are not. This is a misleading analogy. In any case, DRM does not limit what programs people can run, at least not to a greater degree than does any program which encrypts its data. > Right. It's all completely voluntary. There will be no attempts whatsoever > to lock-in, despite decades of attempts and considerable economic > interests involved. Yes, it is completely voluntary, and we should all remain vigilant to make sure it stays that way. And no doubt there will be efforts to lock-in customers, just as there have been in the past. There is no contradiction between these two points. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From shamrock at cypherpunks.to Sat Mar 15 04:31:12 2003 From: shamrock at cypherpunks.to (Lucky Green) Date: Sat, 15 Mar 2003 01:31:12 -0800 Subject: Microsoft: Palladium will not limit what you can run In-Reply-To: <0365df8f385989030d23bbd42da18282@eocto.net> Message-ID: <000b01c2ead5$a0043880$6601a8c0@VAIO650> AARG!, having burned the nym with the moderator of this list and who is therefore now posting via the Hermes remailer commented on Microsoft, which similarly burned the Palladium name, claims: > Hopefully this will shed light on the frequent claims that > Palladium will limit what programs people can run, or "take > over root" on your computer, and similar statements by people > who ought to know better. It is too much to expect these > "experts" to publicly revise their opinions, but perhaps > going forward they can begin gradually to bring their claims > into line with reality. Part of me wonders if it worth my time to reply to this post, but what the heck, I'll take it. So let's talk about reality. It is true, at least for the moment, that Intel's La Grande initiative, which provides the hardware foundation for Palladium, just locks pages in memory that are designate as such by the application. It if further true that Palladium, as the aforementioned OS component, just designates certain blobs of data to be inaccessible to the user who has Ring 0 privileges. Whether Palladium takes over root on a computer or merely prevents the legitimate purchaser of a PC who otherwise has required privileges from performing certain actions on the PC that he legally owns with the data he lawfully created may be a matter of philosophical debate. For conciseness and clarity it suffices to say that the owner of a PC will not have root privileges on a PC on which Palladium is active and in force. No Microsoft press release can possibly alter this fact, since this restriction is fundamental to Palladium having any value at all to any entities. As Microsoft's John Manferdelli wrote: "How these new programs are built - and what they will require of the user - are questions for the application developer to answer." What John means is that Palladium in and by itself will not limit what applications you can run. Which is mostly true for the first phase. But if, in addition to Palladium, you would like to run application by vendors concerned about law-abiding, but undesirable, information flow, then you will find that the applications that you would like to run in addition to the above won't perform as expected. --Lucky --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From eugen at leitl.org Sat Mar 15 05:12:36 2003 From: eugen at leitl.org (Eugen Leitl) Date: Sat, 15 Mar 2003 11:12:36 +0100 (CET) Subject: Microsoft: Palladium will not limit what you can run In-Reply-To: <1ef9b04f5c9d4253c6159e8948f2c5bb@remailer.cryptofortress.com> Message-ID: On Sat, 15 Mar 2003, Anonymous wrote: > Microsoft's point with regard to DRM has always been that Palladium had > other uses besides that one which everyone was focused on. Obviously Of course it's useful. Does the usefulness outweigh the support for special interests (DRM, governments, software monopolies)? There is no value for the end user which can't be achieved with smart cards, which have the additional potential of being removable and transportable. > they fully expect people to use the technology. > > I'm not sure where you get the part about it being deployed under costs. > Is this more of the XBox analogy? That's a video game system, where No, I meant it's a nonnegligible incremental cost on the system. It increases the chipcount and/or the design complexity, and requires strong encryption on interchip and intercomponent bus traffic. I don't know what the increased cost on a motherboard is, but it's probably in the dollar range at least. Very nonegligible for an industry learned caution by low profit margins. There's clearly a long-term political motivation present. > the economics are totally dissimilar to commodity PC's. All video game > consoles are sold under cost today. PCs generally are not. This is a > misleading analogy. I notice that the technology is primarily rolled out in high-margin areas first like notbooks (and in game consoles where considerable front investments need to be protected). > In any case, DRM does not limit what programs people can run, at least > not to a greater degree than does any program which encrypts its data. This is a gross misrepresentation. Content (whether executable code or media, it doesn't really matter as the difference is blurring) can be keyed to individual machines. This kills copying. There's an intense battle going on between open science proponents and the likes of Elsevier. Distribution range of documents can be limited. Access to documents can be limited to specific time window. Secrets inserted at manufacture time ask for legislation demanding subpoenable records. Hardware can be made which prefers a specific vendor by selective disclosure of information. Capability for strong authentication asks for legislation making it nonfacultative, basically outlawing anonymity. Etc. etc. There are many way by which this envelope of technologies here informally called Pd will limit dissemination of information and increase control on side of governments and large companies. Above off-the-cuff list indicates it's a giant, yet untapped can of worms. Unlike subsidized smartcard readers to initial fax effect the user can only lose. > > Right. It's all completely voluntary. There will be no attempts whatsoever > > to lock-in, despite decades of attempts and considerable economic > > interests involved. > > Yes, it is completely voluntary, and we should all remain vigilant to > make sure it stays that way. And no doubt there will be efforts to > lock-in customers, just as there have been in the past. There is no > contradiction between these two points. This is an intensely political technology, and as such ignoring the political component by just focusing on fair and useful side of it will result in a very skewed estimate of its future impacts. It doesn't pay to be naive. Under the circumstances, it is much better to just block it. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From birger at takatukaland.de Sat Mar 15 13:17:50 2003 From: birger at takatukaland.de (Birger Toedtmann) Date: Sat, 15 Mar 2003 19:17:50 +0100 Subject: Microsoft: Palladium will not limit what you can run In-Reply-To: <26663048-55DF-11D7-A0E3-000393754B1C@vangelderen.org> References: <26663048-55DF-11D7-A0E3-000393754B1C@vangelderen.org> Message-ID: <20030315181750.GA13660@exp-math.uni-essen.de> Jeroen C. van Gelderen schrieb am Fri, Mar 14, 2003 at 12:38:14AM -0500: [...] > > Obviously a vendor can restrict what kind of software runs on the > hardware he sells, either by contract or trough technical means. In the > latter case the consumer is of course free to circumvent the barriers, > provided that he lives in a free country. If he doesn't like the > vendor's policy, he is of course free to vote with his wallet. If all vendors have agreed to the same policy [TCPA] you may experiece problems when trying to manufacture your own MB/cpu at home. Voting does not make sense without alternatives. So DRM with collusion of too many vendors will be a problem that even market forces cannot solve easily if it is hard for newcomers to enter the market segment (who has the money to set up a chip plant?). Birger --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From derek at ihtfp.com Sat Mar 15 09:01:36 2003 From: derek at ihtfp.com (Derek Atkins) Date: 15 Mar 2003 09:01:36 -0500 Subject: Face-Recognition Technology Improves In-Reply-To: <005c01c2eaa9$e7b6e190$7901a8c0@sidora> References: <005c01c2eaa9$e7b6e190$7901a8c0@sidora> Message-ID: "Sidney Markowitz" writes: > > In addition, only one subject in 100 is falsely linked > > to an image in the data base in the top systems. > > Wow, 99% accuracy for false positives! That means only a little more than > 750000 people a year mistakenly detained for questioning in Atlanta > HartsField Airport (ATL), and even fewer at the less busy airports (source > Airports Council International, 10 Busiest Airports in US by Number of > Passengers, 2001). Were there really 750 Million Passengers flying through ATL??? That number seems a bit high... Also, I'm not convinced that multiple trials for a single individual are independent. Indeed, one could easily assume that multiple trials for a single individual are highly correlated -- if the machine isn't going to recognize the person on the first try it's highly unliklely it will recognize the person on subsequent tries. It's not like there is a positive feedback mechanism. Therefore, a better question would be how many UNIQUE passengers flew threw ATL, and then take 1% of that for the number of false positives. I think it's safe to assume that the 99% accuracy for false-positives is over the population, not over the number of trials. > -- sidney markowitz > sidney at sidney.com -derek -- Derek Atkins Computer and Internet Security Consultant derek at ihtfp.com www.ihtfp.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From iang at systemics.com Sat Mar 15 11:05:14 2003 From: iang at systemics.com (Ian Grigg) Date: Sat, 15 Mar 2003 11:05:14 -0500 Subject: How effective is open source crypto? Message-ID: <200303151105.14524.iang@systemics.com> How effective is open source crypto? http://www.securityspace.com/s_survey/sdata/200302/protciph.html One measure is to look at how effective the open source crypto regime is in getting product out there. From the above, it is fairly easy to suggest that strong crypto is totally available to all, probably thanks to the efforts of open source crypto providers. How effective is the SSL cert regime? Last page showed 9,032,963 servers. This page shows 112,153 servers using certs. http://www.securityspace.com/s_survey/sdata/200302/index.html That's right, folks. In the particular case of web browsing, the USAGE of crypto has been relegated to 1% of potential opportunities. (Pprobably much less than that due to other factors, but 1% makes for a nice soundbite.) Why? Because a) it is relatively hard to get a server configured with a cert, and b) the browsers discriminate against self-signed certs, forcing administrators to go the more troublesome, costly and frustrating way of requiring purchased and "approved" certs. (For no measurable added value to the security.) (So they don't.) I suggest that open source crypto has won the crypto wars, and the implementations of SSL have bungled the peace for us. It is ludicrously easy to encourage more use of crypto, by repairing the browsers and servers in these two ways: Fix 1. browsers should not negatively discriminate between self-signed, CA-signed and unprotected HTTP. (For example, browsers might show one icon for the self-signed and another icon for the CA-signed - maybe a branded icon from the CA. There should be no FUD warnings when going from totally unprotected HTTP to connections secured by self-signed certs.) Fix 2. Apache and other servers should be configured out of the box automatically with SSL enabled over the default site. (Which means, a self-signed cert [unencrypted on disk] and the server listening on its port.) (There are plenty of minor fixes as well, such as renaming the self-signed certs to be self-signed. At the moment, they are sometimes incorrectly labelled as "snake oil", thus confusing the users by implying that that are not definitively better than unprotected HTTP.) To conclude, open source crypto has not shown itself to be effective, at least within the one protocol examined above, but could easily be so with some changes to the implementations. -- iang PS: I don't know who Security Space is, there is also another company called Netcraft that provides similar stats, but they do not release the results in so timely a fashion, so conclusions tend to suffer from being already "out of date." --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From sidney at sidney.com Sat Mar 15 14:55:44 2003 From: sidney at sidney.com (Sidney Markowitz) Date: Sun, 16 Mar 2003 07:55:44 +1200 Subject: Face-Recognition Technology Improves References: <005c01c2eaa9$e7b6e190$7901a8c0@sidora> Message-ID: <003e01c2eb2c$dec5ab60$7901a8c0@sidora> Derek Atkins wrote: > Were there really 750 Million Passengers flying through ATL? No, 75 million. If you look at my message again I did correctly say 750,000 for the 1% false positive figure, although I did not type a comma to make it easier to read. > Therefore, a better question would be how many UNIQUE > assengers flew threw ATL, and then take 1% of that True, but to a first approximation most of the 200,000 average passengers per day in ATL will be unique individuals, so the false positive rate over the entire population is a good indicator of the effect of deploying the system in an airport. In any case, unless the individuals who repeatedly are falsely matched against the database stop travelling, they would increase the overall false postive rate by the same amount that repeat passengers who are not falsely matched decrease the overall rate. The more important number in these trials to ask about is the size of the database. A 1% false positive rate on a large population matched against a database of 5 faces is much worse than the same rate against a database of 500000. The article mentioned a watch list size of 3000, which seems like a reasonable size for comparison, but the article implies that there were different trials conducted for the study. Without referring to the original report I can't tell if the 1% FP rate was based on that trial or one with a different size database. Taking into account the imprecision inherent in a news article reporting on a large study, all it is safe to say is that when it says "only one subject in a 100" the article is saying "only" while presenting a really horrific scenario for the airport security people if this system is used to screen all the passengers. -- sidney --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From bill.stewart at pobox.com Sat Mar 15 17:47:59 2003 From: bill.stewart at pobox.com (Bill Stewart) Date: Sat, 15 Mar 2003 14:47:59 -0800 Subject: Face-Recognition Technology Improves In-Reply-To: References: <005c01c2eaa9$e7b6e190$7901a8c0@sidora> <005c01c2eaa9$e7b6e190$7901a8c0@sidora> Message-ID: <5.1.1.6.2.20030315132937.02e75320@idiom.com> At 09:01 AM 03/15/2003 -0500, Derek Atkins wrote: >"Sidney Markowitz" writes: > > > > In addition, only one subject in 100 is falsely linked > > > to an image in the data base in the top systems. > > > > Wow, 99% accuracy for false positives! That means only a little more than > > 750000 people a year mistakenly detained for questioning in Atlanta > > HartsField Airport (ATL), and even fewer at the less busy airports (source > > Airports Council International, 10 Busiest Airports in US by Number of > > Passengers, 2001). > >Were there really 750 Million Passengers flying through ATL??? That >number seems a bit high... 750,000 * 100 = 75,000,000 usually (:-), which sounds more credible. No idea how many of those are unique passengers, but there are probably a lot of frequent business travellers going through there many times. >Also, I'm not convinced that multiple trials for a single individual >are independent. Indeed, one could easily assume that multiple trials >for a single individual are highly correlated -- if the machine isn't >going to recognize the person on the first try it's highly unliklely >it will recognize the person on subsequent tries. It's not like there >is a positive feedback mechanism. They're probably not independent, but they'll be influenced by lighting, precise viewing angles, etc., so they're probably nowhere near 100% correlated either. There could be some positive feedback, if they keep photographs of near matches. Another mechanism they could use is the set of names of people expected to fly in and out of the airport, but of course that only works for people who use their real names on airline tickets - it's better for tracking Green Party members than for tracking Carlos the Jackal. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From lynn at garlic.com Sat Mar 15 18:15:22 2003 From: lynn at garlic.com (Anne & Lynn Wheeler) Date: Sat, 15 Mar 2003 16:15:22 -0700 Subject: How effective is open source crypto? In-Reply-To: <200303151105.14524.iang@systemics.com> Message-ID: <4.2.2.20030315153610.00b4a150@mail.earthlink.net> having worked on some of the early e-commerce/certificate stuff ... recent ref: http://www.garlic.com/~lynn/aadsm13.htm#25 Certificate Policies (addenda) the assertion is that basic ssl domain name certificate is so that the browser can check the domain name from the url typed in against the domain name from the presented (trusted) certificate ... and have some confidence that the browser is really talking to the server that it thinks it is talking to (based on some trust in the issuing certification authority). in that context ... self-certification is somewhat superfluous ... if you trust the site to be who they claim to be ... then you shouldn't even have to bother to check. that eliminates having to have a certificate at all ... just transmit a public key so slight step up from MITM-attacks with self-signed certificates would be to register your public key at the same time you register the domain. browsers get the server's public key from dns at the same time it gets the ip-address (dns already supports binding of generalized information to domain ... more than simple ip-address). this is my long, repetitive argument about ssl domain name certification .... http://www.garlic.com/~lynn/subpubkey.html#sslcerts i believe a lot of the non-commercial sites have forgone SSL certificates .... because of the cost and bother. some number of the commercial sites that utilize SSL certificates .... only do it as part of financial transaction (and lots of them .... when it is time to "check-out" .... actually transfer to a 3rd party service site that specializes in SSL encruyption and payments). The claim by many for some time .... is that given the same exact hardware .... they can do 5-6 times as many non-SSL (non-encrypted) HTTP transactions as they can do SSL (encrypted) HTTPS transactions .... aka they claim 80 to 90 percent hit to the number of transactions that can be done switching from HTTP to HTTPS. a short version of the SSL server domain name certificate is worry about attacks on the domain name infrastructure that can route somebody to a different server. so SSL certificate is checked against to see if the browser is likely talking to the server they think they are talking to. the problem is that if somebody applies for a SSL server domain name certificate .... the CA (certification authority) has to check with the authoritative agency for domain names .... to validate the applicants domain name ownership. The authoritative agency for domain names is the domain name infrastructure that has all the integrity concerns giving rise for the need for SSL domain name certificates. So there is a proposal for improving the integrity of the domain name infrastructure (in part backed by the CA industry ... since the CA industry is dependent on the integrity of the domain name infrastructure for the integrity of the certificate of the certificates) which includes somebody registering a public key at the same time at a domain name. So we are in catch-22 .... 1) improving the overall integrity of the domain name infrastructure mitigates a lot of the justification for having SSL domain name certificates (sort of a catch-22 for the CA industry). 2) registering a public key at the same time as domain name infrastructure ... implies that the public key can be served up from the domain name infrastructure (at the same time as the ip-address .... eliminating all need for certificates). There is a description of doing an SSL transaction in single round trip. The browser contacts the domain name system and gets back in single transmission the 1) public key, 2) preferred server SSL parameters, 3) ip-address. The browser selects the SSL parameters, generates a random secret key, encrypts the HTTP request with the random secret key, encrypts the random secret key with the public key ... and sends off the whole thing in a single transmission .... eliminating all of the SSL protocol back&forth setup chatter. The browser had to contact the domain name system in any case to get the ip-address .... the change allows the browser to get back the rest of the information in the same transmission. -- Anne & Lynn Wheeler http://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From derek at ihtfp.com Sat Mar 15 18:55:00 2003 From: derek at ihtfp.com (Derek Atkins) Date: 15 Mar 2003 18:55:00 -0500 Subject: Face-Recognition Technology Improves In-Reply-To: <5.1.1.6.2.20030315132937.02e75320@idiom.com> References: <005c01c2eaa9$e7b6e190$7901a8c0@sidora> <005c01c2eaa9$e7b6e190$7901a8c0@sidora> <5.1.1.6.2.20030315132937.02e75320@idiom.com> Message-ID: Bill Stewart writes: > >Were there really 750 Million Passengers flying through ATL??? That > >number seems a bit high... > > 750,000 * 100 = 75,000,000 usually (:-), which sounds more credible. > No idea how many of those are unique passengers, but there are probably > a lot of frequent business travellers going through there many times. Ok Ok ok. I'm sorry for trying to do math on only 6 hours sleep before a flight. I mis-counted 0's. I'm sorry. -derek -- Derek Atkins Computer and Internet Security Consultant derek at ihtfp.com www.ihtfp.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From rsalz at datapower.com Sat Mar 15 20:16:00 2003 From: rsalz at datapower.com (Rich Salz) Date: Sat, 15 Mar 2003 20:16:00 -0500 (EST) Subject: Microsoft: Palladium will not limit what you can run In-Reply-To: <1ef9b04f5c9d4253c6159e8948f2c5bb@remailer.cryptofortress.com> Message-ID: > All video game > consoles are sold under cost today. This is wrong. Cf, http://www.actsofgord.com/Proclamations/chapter02.html /r$ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From bill.stewart at pobox.com Sun Mar 16 03:16:35 2003 From: bill.stewart at pobox.com (Bill Stewart) Date: Sun, 16 Mar 2003 00:16:35 -0800 Subject: Microsoft: Palladium will not limit what you can run In-Reply-To: <26663048-55DF-11D7-A0E3-000393754B1C@vangelderen.org> References: Message-ID: <5.1.1.6.2.20030316001048.02e708c0@idiom.com> Anish asked for references to Palladium. Using a search engine to find things with "palladium cryptography wasabisystems" or "palladium cypherpunks" will find a bunch of pointers to articles, some of them organized usefully. >On Thursday, Mar 13, 2003, at 21:45 US/Eastern, Jay Sulzberger wrote: >>The Xbox will not boot any free kernel without hardware modification. >>The Xbox is an IBM style peecee with some feeble hardware and software DRM. But is the Xbox running Nag-Scab or whatever Palladium was renamed? Or is it running something of its own, perhaps using some similar components? At 12:38 AM 03/14/2003 -0500, Jeroen C. van Gelderen wrote: >and sold by Microsoft below cost (aka subsidized). >With the expectation that you will be buying Microsoft games >to offset the initial loss. (You don't have a right to this subsidy, >it is up to Microsoft to set the terms here.) It doesn't need to be below cost; Walmart was selling machines with capabilities fairly similar to the Xbox for less, and they certainly don't do anything below cost. (This was the ~$200 Linux PCs.) Now, the amortized development cost of those PCs is probably less than that of X-box, and they were a bit less compact hardware (though Xbox is pretty much of a porker compared to most of the other gamer boxes), and of course the "cost" of the Xbox might include some amortized cost of developing whichever Windows variation it uses, while Walmart didn't have that cost. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From eugen at leitl.org Sun Mar 16 06:39:03 2003 From: eugen at leitl.org (Eugen Leitl) Date: Sun, 16 Mar 2003 12:39:03 +0100 (CET) Subject: Face-Recognition Technology Improves In-Reply-To: <5.1.1.6.2.20030315132937.02e75320@idiom.com> Message-ID: On Sat, 15 Mar 2003, Bill Stewart wrote: > They're probably not independent, but they'll be influenced by lighting, > precise viewing angles, etc., so they're probably nowhere near 100% > correlated either. I notice the systems mentioned in the study rely on biometrics extracted from flat images. Recent crop of systems actually scan the face geometry by using patterned light (apparently, cheaper than using a laser scanner), resulting in a much richer and standartized (lighting and facial orientation is irrelevant) biometric fingerprint. There's a world of difference between a line of people each slowly stepping through the gate past a sensor in roughly aligned orientation and a fixed-orientation no-zoom low-resolution camera looking at a group of freely behaving subjects at varying illumination. Even with basically single-source nonintegrative biometrics one could do a lot with hi-res camera with zoom actively tracking a single person at a time, using a NIR (skin is far more transparent to IR, resulting in a far richer pigmentation pattern fingerprint to be acquired) for illumination. Then there's gait, a physical body model, etc. Shortwave SAR (SAR for THz wavelenths seems to be doable according to recent publications), so reading body geometry would appear possible. Volatile MHC fragment chemosensors are being developed, a hi-tech variant of Stasi's approach with odor samples and canines. (Calibrated sensors, no need for sensor to be exponsed to the scent before, bit vectors never grow stale). By using multichannel, integrative approaches and more sophisticated DSP the error rate can be eventually brought down arbitrarily low, and simultaneously become increasingly hard to falsify. The costs will come down eventually for such integrative telebiometrics systems realtime connected via wireless to be blanket deployable. Unlike a mobile telephone, you can't switch your body off, or leave it at home. It will be interesting to see what will happen politically once the majority of voters will realize they're living in a strictly unilateral version of Brinworld. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ekr at rtfm.com Sun Mar 16 11:40:06 2003 From: ekr at rtfm.com (Eric Rescorla) Date: 16 Mar 2003 08:40:06 -0800 Subject: How effective is open source crypto? In-Reply-To: <4.2.2.20030315153610.00b4a150@mail.earthlink.net> References: <4.2.2.20030315153610.00b4a150@mail.earthlink.net> Message-ID: Anne & Lynn Wheeler writes: > There is a description of doing an SSL transaction in single round > trip. The browser contacts the domain name system and gets back in > single transmission the 1) public key, 2) preferred server SSL > parameters, 3) ip-address. The browser selects the SSL parameters, > generates a random secret key, encrypts the HTTP request with the > random secret key, encrypts the random secret key with the public key > ... and sends off the whole thing in a single transmission > .... eliminating all of the SSL protocol back&forth setup chatter. You still need a round trip in order to prevent replay attacks. The fastest that things can be while still preserving the security properties of TLS is: ClientHello -> ClientKeyExchange -> Finished -> <- ServerHello <- Finished Data -> See Boneh and Schacham's "Fast-Track SSL" paper in Proc.ISOC NDSS 2002 for a description of a scheme where the client caches the server's parameters for future use, which is essentially isomorphic to having the keys in the DNS as far as the SSL portion goes. In any case, the optimization you describe provides almost no performance improvement for the server because the load on the server derives almost entirely from the cryptography, not from transmitting the ServerHello [0]. What it does is provide reduced latency, but this is only of interest to the client, not the server, and really only matters on very constrained links. -Ekr [0] With the exception of the ephemeral modes, but they're simply impossible in the scheme you describe. -- [Eric Rescorla ekr at rtfm.com] http://www.rtfm.com/ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From lynn at garlic.com Sun Mar 16 12:17:39 2003 From: lynn at garlic.com (Anne & Lynn Wheeler) Date: Sun, 16 Mar 2003 10:17:39 -0700 Subject: How effective is open source crypto? In-Reply-To: References: <4.2.2.20030315153610.00b4a150@mail.earthlink.net> <4.2.2.20030315153610.00b4a150@mail.earthlink.net> Message-ID: <4.2.2.20030316094712.00bbced0@mail.earthlink.net> At 08:40 AM 3/16/2003 -0800, Eric Rescorla wrote: >You still need a round trip in order to prevent replay attacks. The >fastest that things can be while still preserving the security >properties of TLS is: > >ClientHello -> >ClientKeyExchange -> >Finished -> > <- ServerHello > <- Finished >Data -> > >See Boneh and Schacham's "Fast-Track SSL" paper in Proc.ISOC NDSS 2002 >for a description of a scheme where the client caches the server's >parameters for future use, which is essentially isomorphic >to having the keys in the DNS as far as the SSL portion goes. > >In any case, the optimization you describe provides almost no >performance improvement for the server because the load on the server >derives almost entirely from the cryptography, not from transmitting >the ServerHello [0]. What it does is provide reduced latency, >but this is only of interest to the client, not the server, >and really only matters on very constrained links. > >-Ekr > >[0] With the exception of the ephemeral modes, but they're simply >impossible in the scheme you describe. Sorry, there were two pieces being discussed. The part about SSL being a burden/load on servers .... and the shorten SSL description taken from another discussion. The shorten SSL description was (in fact) from a discussion of the round-trips and latency ... not particularly burden on the server. In the original discussion there was mention about HTTP requires TCP setup/teardown which is minimum seven packet exchange .... and any HTTPS chatter is in addition to that. VMTP, from rfc1045 is minimum five packet exchange, and XTP is minimum three packet exchange. A cached/dns SSL is still minimum seven packet exchange done over TCP (although XTP would reduce that to three packet exchange). So what kind of replay attack is there. Looking at purely e-commerce ... there is no client authentication. Also, since the client always chooses a new, random key .... there is no replay attack on the client ... since the client always sends something new (random key) every time. That just leaves replay attacks on the server (repeatedly sending the same encrypted data). As follow-up to doing the original e-commerce stuff ... we then went on to look at existing vulnerabilities and solutions .... and (at least) the payment system has other methods already in place with regard to getting duplicate transaction .... aka standards body for all payments (credit, debit, stored-value, etc) in all (electronic) environments (internet, point-of-sale, self-serve, face-to-face, etc), X9.59 http://www.garlic.com/~lynn/index.html#x959 (standard) http://www.garlic.com/~lynn/index.html#aadsnacha (debit/atm network pilot) Replay for simple information retrieval isn't particularly serious except as DOS .... but serious DOS can be done whether flooding is done with encrypted packets or non-encrypted packets. Another replay attack is transaction based ... where each transaction represents something like performing real world transaction (send a shirt and debit account). If it actually involves payment ... the payment infrastructure has provisions in place to handle repeat/replay and will reject. So primarily what is left .... are simple transaction oriented infrastructures that don't have their own mechanism for detecting replay/repeats and are relying on SSL. I would also contend that this is significantly smaller exposure than self-signed certificates. -- Anne & Lynn Wheeler http://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ekr at rtfm.com Sun Mar 16 12:30:55 2003 From: ekr at rtfm.com (Eric Rescorla) Date: 16 Mar 2003 09:30:55 -0800 Subject: How effective is open source crypto? In-Reply-To: <4.2.2.20030316094712.00bbced0@mail.earthlink.net> References: <4.2.2.20030315153610.00b4a150@mail.earthlink.net> <4.2.2.20030315153610.00b4a150@mail.earthlink.net> <4.2.2.20030316094712.00bbced0@mail.earthlink.net> Message-ID: Anne & Lynn Wheeler writes: > At 08:40 AM 3/16/2003 -0800, Eric Rescorla wrote: > > Sorry, there were two pieces being discussed. > > The part about SSL being a burden/load on servers .... > > and the shorten SSL description taken from another discussion. This wasn't clear from your message. > The > shorten SSL description was (in fact) from a discussion of the > round-trips and latency ... not particularly burden on the server. In > the original discussion there was mention about HTTP requires TCP > setup/teardown which is minimum seven packet exchange .... TCP setup is 3 packets. The teardown doesn't have any effect whatsoever on the performance of the system (and often isn't done anyway). It's a very modest load on the network and one which is far outstripped by the traffic sent by SSL and HTTP. > So what kind of replay attack is there. Looking at purely e-commerce > ... there is no client authentication. Also, since the client always > chooses a new, random key .... there is no replay attack on the client > ... since the client always sends something new (random key) every > time. That just leaves replay attacks on the server (repeatedly > sending the same encrypted data). Correct. It's considered bad form to design systems which have known replay attacks when it's just as easy to design systems which don't. If there were some overriding reason why it was impractical to mount a defense, then it might be worth living with a replay attack. However, since it would have only a very minimal effect on offered load to the network and--in most cases--only a marginal effect on latency, it's not worth doing. -Ekr -- [Eric Rescorla ekr at rtfm.com] http://www.rtfm.com/ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From lynn at garlic.com Sun Mar 16 12:40:52 2003 From: lynn at garlic.com (Anne & Lynn Wheeler) Date: Sun, 16 Mar 2003 10:40:52 -0700 Subject: How effective is open source crypto? (addenda) In-Reply-To: References: <4.2.2.20030315153610.00b4a150@mail.earthlink.net> <4.2.2.20030315153610.00b4a150@mail.earthlink.net> Message-ID: <4.2.2.20030316103002.00bbab30@mail.earthlink.net> ... small side-note .... part of the x9.59 work for all payments in all environments .... was that the transaction system needed to be resilient to repeats and be done in a single round-trip (as opposed to the transport). there needed to be transaction resiliency with respect to single round trip with something like email that might not happen in strictly real-time (extremely long round-trip delays). Real-world systems have been known to have glitches ... order/transaction generation that accidentally repeats (regardless of whether or not transport is catching replay attacks). -- Anne & Lynn Wheeler http://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From lynn at garlic.com Sun Mar 16 13:26:59 2003 From: lynn at garlic.com (Anne & Lynn Wheeler) Date: Sun, 16 Mar 2003 11:26:59 -0700 Subject: How effective is open source crypto? (bad form) In-Reply-To: References: <4.2.2.20030316094712.00bbced0@mail.earthlink.net> <4.2.2.20030315153610.00b4a150@mail.earthlink.net> <4.2.2.20030315153610.00b4a150@mail.earthlink.net> <4.2.2.20030316094712.00bbced0@mail.earthlink.net> Message-ID: <4.2.2.20030316104514.00bb5970@mail.earthlink.net> At 09:30 AM 3/16/2003 -0800, Eric Rescorla wrote: >Correct. > >It's considered bad form to design systems which have known replay >attacks when it's just as easy to design systems which don't. >If there were some overriding reason why it was impractical >to mount a defense, then it might be worth living with a replay >attack. However, since it would have only a very minimal effect >on offered load to the network and--in most cases--only a marginal >effect on latency, it's not worth doing. > >-Ekr > >-- >[Eric Rescorla ekr at rtfm.com] > http://www.rtfm.com/ so, lets look at the alternatives for servers that are worried about server replay attacks: client has public key & crypto-preferred info (dns or cached), generates random secret key, encrypts request, encrypts random secret key, single transmission server gets request ... application has opened the connection with or w/o server replay attack. if the application, higher level protocol has its own repeat checking .... it has opened the connection w/o server replay attack. and the server sends the request up the stack to the application. If the application has opened the connection with server replay attack, the protocol sends back some random data (aka its own secret)... that happens to be encrypted with the random key. The client is expecting either the actual response or the replay attack check. If the client gets the actual response, everything is done. If the clients gets back the replay attack check .... it combines it with something .... and returns to the server. The difference is basic two packet exchange (within setup/teardown packet exchange overhead) plus an additional replay prevention two packet exchange (if the higher level protocol doesn't have its own repeat handling protocol). The decision as to whether it is two packet exchange or four packet exchange is not made by client ... nor the server ... but by the server application. Simple example for e-commerce is sending a P.O. along with payment authorization ... the transmitted P.O. form is guaranteed to have a unique identifier. The P.O. processing system has logic for handling repeat POs ... for numerous reasons (not limited to replay attacks). Single round-trip transaction: ClientHello/Trans-> <- ServerResponse/Finish Transaction w/replay challenge: ClientHello/Trans-> <-Server replay challenge ClientResp-> <-ServerResponse/Finish Now, ClientHello/Trans can indicate whether the client is expecting a single round-trip or additional data. Also, the ServerResponse can indicate whether it is a piggy-backed finish or not. So, the vulnerability analysis is what is the object of the replay attack and what needs to be protected. I would contend that the object of the replay attack isn't directly the protocol, server, or the system .... but the specific server application. Problem of course, is that with generic webserver (making the connection) there might be a couple levels of indirection between the webserver specifying the connection parameters and the actual server application (leading to webservers always specifying replay challenge option). -- Anne & Lynn Wheeler http://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ekr at rtfm.com Sun Mar 16 13:41:42 2003 From: ekr at rtfm.com (Eric Rescorla) Date: 16 Mar 2003 10:41:42 -0800 Subject: How effective is open source crypto? (bad form) In-Reply-To: <4.2.2.20030316104514.00bb5970@mail.earthlink.net> References: <4.2.2.20030316094712.00bbced0@mail.earthlink.net> <4.2.2.20030315153610.00b4a150@mail.earthlink.net> <4.2.2.20030315153610.00b4a150@mail.earthlink.net> <4.2.2.20030316094712.00bbced0@mail.earthlink.net> <4.2.2.20030316104514.00bb5970@mail.earthlink.net> Message-ID: Anne & Lynn Wheeler writes: > The difference is basic two packet exchange (within setup/teardown > packet exchange overhead) plus an additional replay prevention two > packet exchange (if the higher level protocol doesn't have its own > repeat handling protocol). The decision as to whether it is two packet > exchange or four packet exchange is not made by client ... nor the > server ... but by the server application. You've already missed the point. SSL/TLS is a generic security protocol. As such, the idea is to push all the security into the protocol layer where possible. Since, as I noted, the performance improvement achieved by not doing so is minimal, it's better to just have replay protection here. -Ekr -- [Eric Rescorla ekr at rtfm.com] http://www.rtfm.com/ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From bill.stewart at pobox.com Sun Mar 16 14:11:40 2003 From: bill.stewart at pobox.com (Bill Stewart) Date: Sun, 16 Mar 2003 11:11:40 -0800 Subject: Face-Recognition Technology Improves In-Reply-To: References: <5.1.1.6.2.20030315132937.02e75320@idiom.com> Message-ID: <5.1.1.6.2.20030316110721.02edacc0@idiom.com> At 12:39 PM 03/16/2003 +0100, Eugen Leitl wrote: >On Sat, 15 Mar 2003, Bill Stewart wrote: > > > They're probably not independent, but they'll be influenced by lighting, > > precise viewing angles, etc., so they're probably nowhere near 100% > > correlated either. > >I notice the systems mentioned in the study rely on biometrics extracted >from flat images. Recent crop of systems actually scan the face geometry >by using patterned light (apparently, cheaper than using a laser scanner), >resulting in a much richer and standartized (lighting and facial >orientation is irrelevant) biometric fingerprint. But there are two sides to the problem - recording the images of the people you're looking for, and viewing the crowd to try to find matches. You're right that airport security gates are probably a pretty good consistent place to view the crowd, but getting the target images is a different problem - some of the Usual Suspects may have police mugshots, but for most of them it's unlikely that you've gotten them to sit down while you take a whole-face geometry scan to get the fingerprint. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From schoen at loyalty.org Sun Mar 16 14:11:55 2003 From: schoen at loyalty.org (Seth David Schoen) Date: Sun, 16 Mar 2003 11:11:55 -0800 Subject: Microsoft: Palladium will not limit what you can run In-Reply-To: <5.1.1.6.2.20030316001048.02e708c0@idiom.com> References: <5.1.1.6.2.20030316001048.02e708c0@idiom.com> Message-ID: <20030316191155.GA15220@zork.net> Bill Stewart writes: > >On Thursday, Mar 13, 2003, at 21:45 US/Eastern, Jay Sulzberger wrote: > >>The Xbox will not boot any free kernel without hardware modification. > >>The Xbox is an IBM style peecee with some feeble hardware and software > >>DRM. > > But is the Xbox running Nag-Scab or whatever Palladium was renamed? > Or is it running something of its own, perhaps using some similar > components? The Xbox is definitely not based on NGSCB; Microsoft told EFF very clearly last year that Palladium was still being designed and hadn't gone into manufacturing. The Xbox was certainly being sold then. The Xbox was analyzed by Andrew "bunnie" Huang, who found that it was using a sui generis security system. ftp://publications.ai.mit.edu/ai-publications/2002/AIM-2002-008.pdf -- Seth David Schoen | Very frankly, I am opposed to people http://www.loyalty.org/~schoen/ | being programmed by others. http://vitanuova.loyalty.org/ | -- Fred Rogers (1928-2003), | 464 U.S. 417, 445 (1984) --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From eugen at leitl.org Sun Mar 16 14:44:47 2003 From: eugen at leitl.org (Eugen Leitl) Date: Sun, 16 Mar 2003 20:44:47 +0100 (CET) Subject: Face-Recognition Technology Improves In-Reply-To: <5.1.1.6.2.20030316110721.02edacc0@idiom.com> Message-ID: On Sun, 16 Mar 2003, Bill Stewart wrote: > You're right that airport security gates are probably a pretty good > consistent place to view the crowd, but getting the target images > is a different problem - some of the Usual Suspects may have police mugshots, > but for most of them it's unlikely that you've gotten them to sit down > while you take a whole-face geometry scan to get the fingerprint. I think the security-crazed data gatherers would just want to scan biometrics of every single person passing through the metal detector gates, check them against the list of usual suspects, and insert them in realtime into a central database. Where they will remain, for indefinite time, free for any authorized party to do data mining on. Unless explict laws have been passed preventing this very eventuality, and the systems are actually audited that no data is retained beyond what is necessary for processing. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From lynn at garlic.com Sun Mar 16 15:48:02 2003 From: lynn at garlic.com (Anne & Lynn Wheeler) Date: Sun, 16 Mar 2003 13:48:02 -0700 Subject: How effective is open source crypto? (aads addenda) In-Reply-To: References: <4.2.2.20030316094712.00bbced0@mail.earthlink.net> <4.2.2.20030315153610.00b4a150@mail.earthlink.net> <4.2.2.20030315153610.00b4a150@mail.earthlink.net> <4.2.2.20030316094712.00bbced0@mail.earthlink.net> Message-ID: <4.2.2.20030316113717.00b36ef0@mail.earthlink.net> we did something similar for AADS PPP Radius http://www.garlic.com/~lynn/index.html#aads AADS radius example http://www.asuretee.com/ ... with FIPS186-2, x9.62, ecdsa digital signature authentication on sourceforce .... http://ecdsainterface.sourceforge.net/ radius digital signature protocol has replay challenge. so adding radius option to webserver client authentication stub (infrastructure can share common administration client authentication across all of its environments). then client clicks on https client authentication, generates secret random key, encrypts request for client authentication with random key, encrypts random key with server public key, sends off single transmission. Server responds with radius connect request .... which includes replay challenge value as part of message (encrypted with random key). Client responds with digital signature on the server radius message (and some of its own data, encrypted with random key). Basically use the same packet sequence as in transaction w/o replay challenge ... since higher level protocol contains replay challenge. Then can use same packet sequence for webserver TLS and encrypted PPP (and works as VPN; possibly can define also as encrypted TCP) .... along with the same client authentication infrastructure Infrastructure can use the same administration (RADIUS) infrastructure for all client authentication .... say enterprise with both extranet connections as well as webserver .... or ISP that also supplies webhosting. The same administrative operation can be used to support client authentication at the PPP level as well as at the webserver level. The same packet exchange sequence is used for both PPP level encryption with client authentication as well as TLS for webserver level encryption with client authentication. The higher level application can decide whether it already has sufficient replay/repeat resistance or request replay/repeat resistance from lower level protocol. So regardless of TLS, PPP, or TCP, client authentication (using same packet sequence as transaction, w/o lower level replay challenge): 1) client picks up server public key and encryption options (from cache or DNS) 2) client sends of radius client authentication, encrypted with random secret key, encrypted with server public key ... 3) server lower level protocol handles the decryption of the random secret key and the decryption of the client request (which happens to be radius client authentication .... but could be any other kind of transaction request) and passes up the decrypted client request 4) server higher level protocol (radius client authentication) responds with radius replay challenge 5) client gets the replay challenge, adds some stuff, digitally signs it and responds 6) server higher level radius client authentication protocol appropriately processes Same server public key initial connect code works at TLS, PPP, and possibly TCP protocol levels. The same server public key initial connect code supports both lower-level replay challenge and no replay challenge. Same radius client authentication works at TLS, PPP, and possibly TCP protocol levels. Same client administrative processes works across the whole environment. aka .... the radius client authentication protocol is just another example (like the purchasse order example) of the higher level protocol having its own replay/repeat handling infrastructure (whether it is something like log checking or its own replay challenge). -- Anne & Lynn Wheeler http://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From pgut001 at cs.auckland.ac.nz Mon Mar 17 08:09:44 2003 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Tue, 18 Mar 2003 01:09:44 +1200 Subject: Brumley & Boneh timing attack on OpenSSL Message-ID: <200303171309.h2HD9iG17136@medusa01.cs.auckland.ac.nz> Bill Stewart writes: >Schmoo Group response on cryptonomicon.net >http://www.cryptonomicon.net/modules.php?name=News&file=article&sid=263&mode=&order=0&thold=0 >Apparently OpenSSL has code to prevent the timing attack, >but it's often not compiled in (I'm not sure how much that's for >performance reasons as opposed to general ignorance?) I had blinding code included in my crypto code for about 3 years, when not a single person used it in all that time I removed it again (actually I think it's probably still there, but disconnected). I'm leaning strongly towards "general ignorance" here... Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From astiglic at okiok.com Mon Mar 17 11:16:13 2003 From: astiglic at okiok.com (Anton Stiglic) Date: Mon, 17 Mar 2003 11:16:13 -0500 Subject: Diffie-Hellman 128 bit References: <006201c2e9aa$54768200$6f42420a@lanwan> <00b701c2ea9b$1b086280$6f42420a@lanwan> Message-ID: <004e01c2eca0$8a69b0a0$5ba96395@p1038mobile> > Well, I'm attacking a protocol, I know the rules of DH parameters, and the > issue here is I'm trying to solve x, brute forcing that in the 128 bit range > can be difficult, and x doesn't have to be a prime. (a = g^x mod P). Their > primes are 128 bit primes, as well as their pubkeys, I've done some tests on > their prime, and all perform under this method of (p-1)/2 = prime. This > eliminates the pohlig-hellman discrete logarithm attack, but I'm trying to > learn the Gaussian integer method. No, just use the Number Field Sieve algorithm (this is mentioned in section 3.5 of the manuscript I gave you the link to). You could read section 3.6 of the Handbook of Applied Cryptography for a basic introduction to the problem of discrete logarithm. --Anton --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From astiglic at okiok.com Mon Mar 17 14:24:42 2003 From: astiglic at okiok.com (Anton Stiglic) Date: Mon, 17 Mar 2003 14:24:42 -0500 Subject: Diffie-Hellman 128 bit References: <006201c2e9aa$54768200$6f42420a@lanwan> <00b701c2ea9b$1b086280$6f42420a@lanwan> Message-ID: <000f01c2ecba$e2bca040$10976395@p1038mobile> ----- Original Message ----- From: "NOP" To: "Derek Atkins" Cc: Sent: Friday, March 14, 2003 9:32 PM Subject: Re: Diffie-Hellman 128 bit > Well, I'm attacking a protocol, I know the rules of DH parameters, and the > issue here is I'm trying to solve x, brute forcing that in the 128 bit range > can be difficult, and x doesn't have to be a prime. (a = g^x mod P). Their > primes are 128 bit primes, as well as their pubkeys, I've done some tests on > their prime, and all perform under this method of (p-1)/2 = prime. This > eliminates the pohlig-hellman discrete logarithm attack, but I'm trying to > learn the Gaussian integer method. Sorry, I mentioned using NFS in my previous reply, which is probably not the way you want to go about this (since it's not as efficient for small values and more complicated to code). Index-Calculus with Gaussian integers is indeed a good way. You can look at the paper from LaMacchia and Odlyzko http://citeseer.nj.nec.com/lamacchia91computation.html which Derek and maybe someone else pointed out.. They easily calculated discret logs modulo a 192-bit integer. --Anton --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From vlastimil.klima at i.cz Tue Mar 18 11:42:04 2003 From: vlastimil.klima at i.cz (Vlastimil Klima) Date: Tue, 18 Mar 2003 17:42:04 +0100 Subject: Another side channel weakness in the SSL/TLS Message-ID: <9E85DC6CA1D5D311BB460006293960FE089D3F@dcrfs.decros.cz> Dear colleagues we would like to inform you about a new attack on SSL/TLS. For further details see the cryptologic report at or the press release at ICZ web site at http://www.i.cz/en/onas/tisk7.html. Best regards Vlastimil Klima and Tomas Rosa, {vlastimil.klima, tomas.rosa}@i.cz --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From novalis at novalis.org Tue Mar 18 13:33:35 2003 From: novalis at novalis.org (David Turner) Date: 18 Mar 2003 13:33:35 -0500 Subject: Microsoft: Palladium will not limit what you can run In-Reply-To: References: Message-ID: <1048012415.22335.404.camel@banks> On Sat, 2003-03-15 at 05:12, Eugen Leitl wrote: > On Sat, 15 Mar 2003, Anonymous wrote: > > > Microsoft's point with regard to DRM has always been that Palladium had > > other uses besides that one which everyone was focused on. Obviously > > Of course it's useful. Does the usefulness outweigh the support for > special interests (DRM, governments, software monopolies)? There is no > value for the end user which can't be achieved with smart cards, which > have the additional potential of being removable and transportable. I have my own problems with Pd, but I'm not sure how remote attestation can be achieved without something like Pd or TCPA. And remote attestation is quite useful (although also dangerous) for online gaming, and distributed computing. -- -Dave Turner Stalk Me: 617 441 0668 "On matters of style, swim with the current, on matters of principle, stand like a rock." -Thomas Jefferson --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From info at hbarel.com Thu Mar 20 07:56:33 2003 From: info at hbarel.com (Hagai Bar-El) Date: Thu, 20 Mar 2003 14:56:33 +0200 Subject: Diffie-Hellman 128 bit In-Reply-To: <006201c2e9aa$54768200$6f42420a@lanwan> Message-ID: <5.2.0.9.2.20030320145029.00acd088@mail.hbarel.com> At 13/03/03 23:48, you wrote: >I am looking at attacks on Diffie-Hellman. > >The protocol implementation I'm looking at designed their diffie-hellman >using 128 bit primes (generated each time, yet P-1/2 will be a prime, so no >go on pohlig-hellman attack), so what attacks are there that I can look at >to come up with either the logarithm x from (a=g^x mod p) or the session key >that is >calculated. A brute force wouldn't work, unless I know the starting range. >Are there any realistic >attacks on DH parameters of this size, or is theoretically based on >financial computation attacks? You can find good explanation for the rationale behind Diffie-Hellman parameters as well as general precautions for implementation in a good paper called "Security Issues in the Diffie-Hellman Key Agreement Protocol" You can find it in: http://citeseer.nj.nec.com/483430.html Regards, Hagai. Hagai Bar-El - Information Security Analyst Tel.: 972-8-9354152 Fax.: 972-8-9354152 E-mail: info at hbarel.com Web: www.hbarel.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From mctylr at privacy.nb.ca Thu Mar 20 11:15:55 2003 From: mctylr at privacy.nb.ca (M Taylor) Date: Thu, 20 Mar 2003 16:15:55 +0000 Subject: Certicom unveils S/MIME client for PDAs Message-ID: <20030320161555.A3193@pull.privacy.nb.ca> http://www.globetechnology.com/servlet/story/RTGAM.20030317.gtb3/GTStory Monday, March 17 [2003] Certicom unveils movianMail Certicom Corp., a provider of wireless security solutions, has taken the wraps off movianMail, a secure e-mail solution based on S/MIME version 3 for use with Microsoft Pocket Outlook. movianMail enables enterprise and government users to send and receive digitally-signed and encrypted e-mail messages on their Pocket PC device. According to the company, it is the only wireless secure e-mail solution to store all messages encrypted on the e-mail server, in addition to offering proof of the message's origin through digital signatures. Governments and other organizations that require highly protected information are mandating S/MIME to secure their e-mail. To meet the strict security requirements of the U.S. Government, movianMail is available as a Government Security Edition (GSE) product, which also supports certificates and keys stored on the Department of Defense (DoD) Common Access Card, ensuring even stronger security and authentication of e-mail messages and attachments, the company said. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From kelm at secorvo.de Thu Mar 20 11:39:45 2003 From: kelm at secorvo.de (Stefan Kelm) Date: Thu, 20 Mar 2003 17:39:45 +0100 Subject: Interception of Telecommunications in Germany Message-ID: <3E79FCE1.16818.16F95E5@localhost> The German 'Regulatory Authority for Telecommunications and Posts' has drafted the translation of a much-discussed document: "Technical Directive setting forth Requirements relating to the implementation of Legal Measures for the Interception of Telecommunications (TR TK?)" It is available at http://home.t-online.de/home/regtp.referat335/TRTKUE-40-draft18-03-03.zip ( http://home.t-online.de/home/regtp.referat335/ ) Cheers, Stefan. ------------------------------------------------------- Dipl.-Inform. Stefan Kelm Security Consultant Secorvo Security Consulting GmbH Albert-Nestler-Strasse 9, D-76131 Karlsruhe Tel. +49 721 6105-461, Fax +49 721 6105-455 E-Mail kelm at secorvo.de, http://www.secorvo.de ------------------------------------------------------- PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From orourked at eeng.dcu.ie Fri Mar 21 11:14:10 2003 From: orourked at eeng.dcu.ie (Damien O'Rourke) Date: Fri, 21 Mar 2003 16:14:10 -0000 Subject: Cryptoprocessors compliant with FIPS 140-2 Message-ID: <000701c2efc4$e88b31a0$8023ce88@eeng.dcu.ie> Hi, I was wondering if anyone could list a number of cryptographic processors that are compliant with the Federal information processing standard (FIPS) 140-2 "Security Requirements for cryptographic modules". I know that the IBM-4758 was compliant with FIPS 140-1 up to level 4 but I don't think it has been tested under the newer version of the standard (correct me if I'm wrong). Specifically I am wondering about section 4.11 on page 39 entitled "Mitigation of Other Attacks" which discusses, power analysis, timing attacks, TEMPEST and fault induction. If you could tell me what level they have been certified to and where I might find some more information on them that would be great. In fact, any relevant information would be greatly appreciated. Thanks for your time. Best Regards, Damien. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From schear at attbi.com Fri Mar 21 22:24:20 2003 From: schear at attbi.com (Steve Schear) Date: Fri, 21 Mar 2003 19:24:20 -0800 Subject: Spammers Would Be Made To Pay Under IBM Research Proposal In-Reply-To: Message-ID: <5.1.0.14.2.20030321191443.0491ccf8@mail.attbi.com> >Spammers Would Be Made To Pay Under IBM Research Proposal > >By Tony Kontzer, InformationWeek, InternetWeek >Mar 20, 2003 (8:45 PM) >URL: http://www.internetweek.com/story/showArticle.jhtml?articleID=7900141 > >Companies and consumers alike have been looking to two primary aids in the >battle to stem the flood of spam. On the practical side, they're turning >to a seemingly endless parade of filters and other software products >designed to slow the tide of unwanted E-mail by doing things such as >checking messages against known spam, using textual clues to glean whether >a message is spam, or blocking the IP addresses of known spammers. On the >more hopeful side, they're pressuring legislators for federal laws banning >spam. > >IBM researchers say both approaches miss the target--that the software >approach amounts to a constant game of trying to stay one step ahead of >spammers, while legislation, if and when it comes, won't be able to >address spam coming from outside U.S. borders. As a result, they've come >up with another approach: Make spammers pay to send messages. It sounds >absurdly simple, and Scott Fahlman, a research staff member at IBM's >Watson Research Center, says it is. Fahlman is trying to build momentum >behind a concept he's calling the "charity stamp" approach, which would >force anyone sending unsolicited messages to pay to reach recipients >participating in the program unless they had an authenticated code. >Of course none of this is news to many readers on this list. A number of >people in the crypto/cypherpunk community (e.g, Adam Back, Eric S. >Johansson and Ben Laurie) have worked for some time to develop the >mathematics and code to launch proof-of-concept e-stamp systems based on >either Proof-of-Work algorithims or real value. Recently Microsoft also >unveiled a similar project PennyBlack >http://research.microsoft.com/research/sv/PennyBlack/ steve --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From eugen at leitl.org Sat Mar 22 03:51:22 2003 From: eugen at leitl.org (Eugen Leitl) Date: Sat, 22 Mar 2003 09:51:22 +0100 (CET) Subject: Brumley & Boneh timing attack on OpenSSL (fwd) Message-ID: Some clarification by Peter Gutmann on why cryptlib doesn't do timing attack resistance default: Peter Gutmann : cryptlib was never intended to be a high-performance SSL server (the docs are fairly clear on this), and I don't think anyone is using it to replace Apache or IIS. OTOH it is used in a number of specialised environments such as closed environments, embedded systems and mainframes. For example two real-world uses of the cryptlib SSL server are in embedded environment A and mainframe environment B. In A, the processing is handled by a low-power embedded processor. It takes 10-15s to perform an SSL handshake, and that's after the code has been optimised to death to squeeze every possible bit of performance out of it. Performing the necessary 1.5M queries at 15s each would take approximately 8 1/2 months at 100% CPU load (meaning that the device is unable to perform any other operations in that entire time). This is unlikely to go unnoticed, given that it's polled from other devices for status updates. In B, CPU resources are so scarce that the implementation uses null cipher suites because it can't afford the overhead of even RC4 for encryption (admittedly this required a custom code hack, cryptlib doesn't normally support null encryption suites). After about 100 or so attempts at a full SSL handshake, klaxons would sound and blue-suited troops would deploy onto the raised flooring to determine where all the CPU time is going. In neither of these environments (and various similar ones) would a side- channel attack requiring 1M or so queries (e.g. this one, or the Bleichenbacher attack, or the Klima-Pokorny-Rosa attack, which cryptlib shouldn't be vulnerable to since I'm paranoid about error reporting) be terribly feasible. OTOH blinding does produce a noticeable slowdown for a process that's already regarded by its users as unacceptably slow and/or CPU-intensive (I have some users who've hacked the key-exchange process to use fixed shared keys because they just can't spare the CPU time to do a real handshake, e.g. by injecting the shared key into the SSL session cache so you just do a pseudo-resume for each new connection). For this reason, cryptlib makes the use of sidechannel- attack-protection an optional item, which must be selected by the user (via use of the blinding code, now admittedly I should probably make this a bit easier to do in future releases than having to hack the source :-). This is not to downplay the seriousness of the attack, merely to say that in some cases the slowdown/CPU consumption vs.attack risk doesn't make it worthwhile to defend against. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From dfc at anize.org Sat Mar 22 17:12:59 2003 From: dfc at anize.org (Douglas F. Calvert) Date: 22 Mar 2003 17:12:59 -0500 Subject: Keysigning @ CFP2003 Message-ID: <1048371179.24681.32.camel@liberate.anize.org> GPG/PGP Keysigning @ Computers, Freedom and Privacy 2003 April 2nd, 9:45pm (First BoF Session) I will be organizing a keysigning session for CFP2003. Please submit your keys to cfp-keys at anize.org and I will print out sheets with key information in order to speed up the process. Bring a photo ID and a copy of your key information so that you can verify what is on the printout. A list of submitted keys and a keyring will be available on: http://anize.org/cfp2003/ Thank you... -- + Douglas Calvert dfc at anize.org http://anize.org/dfc/ + | Key Id 0xC9541FB2 http://anize.org/dfc-keys.asc | | [X] User wants to receive encrypted mail | +| 0817 30D4 82B6 BB8D 5E66 06F6 B796 073D C954 1FB2 |+ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 193 bytes Desc: This is a digitally signed message part URL: From bill.stewart at pobox.com Sat Mar 22 15:25:58 2003 From: bill.stewart at pobox.com (Bill Stewart) Date: Sat, 22 Mar 2003 12:25:58 -0800 Subject: Brumley & Boneh timing attack on OpenSSL (fwd) In-Reply-To: Message-ID: <5.1.1.6.2.20030322121904.02ebe2d8@idiom.com> At 09:51 AM 03/22/2003 +0100, Eugen Leitl wrote: >Some clarification by Peter Gutmann on why >cryptlib doesn't do timing attack resistance default: > >Peter Gutmann : >cryptlib was never intended to be a high-performance SSL server (the docs are >fairly clear on this), and I don't think anyone is using it to replace Apache >or IIS. OTOH it is used in a number of specialised environments such as >closed ... > For this reason, cryptlib makes the use of sidechannel- >attack-protection an optional item, which must be selected by the user >(via use >of the blinding code, now admittedly I should probably make this a bit easier >to do in future releases than having to hack the source :-). This is not to >downplay the seriousness of the attack, merely to say that in some cases the >slowdown/CPU consumption vs.attack risk doesn't make it worthwhile to defend >against. If it's not meant to be a high-performance server, then slowing it down another 20% by doing RSA timing things is probably fine for most uses, and either using compiler flags or (better) friendlier options of some sort to turn off the timing resistance is probably the better choice. I'm not sure how flexible things need to be - real applications of the openssl code include non-server things like certificate generation, and probably some reasonable fraction of the RSA or DH calculations don't need to be timing-protected, but many of them are also things that aren't CPU-consumption-critical either. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From iang at systemics.com Sun Mar 23 23:10:22 2003 From: iang at systemics.com (Ian Grigg) Date: Sun, 23 Mar 2003 23:10:22 -0500 Subject: Who's afraid of Mallory Wolf? Message-ID: <200303232310.22334.iang@systemics.com> Who's afraid of Mallory Wolf? By common wisdom, SSL is designed to defeat the so-called "Man in the Middle" attack, or MITM for short. Also known as Mallory, in crypto circles. The question arises, why? For what reason is the MITM a core part of the SSL threat model? And, why do all the implementations assume this? (It is, in fact, possible to use SSL, or TLS as it is now known, without regard to the MITM protection that is part of the model - certs - but I ignore that here, as do implementations!) One has to go back to the original invention of SSL, back in 1994 or so: the web was storming the barricades as the 2nd great killer application for the net (email was the 1st). Companies were dipping their toes into the endless possibilities of commerce. Netscape was evolving as the master of the new net, the challenge to Microsoft, the owner of all things it surveyed. And, as with all dot-com crazies to follow, it had nothing spectacular in the way of a business model. Selling a few secured servers, was all. This whole commerce thing was, at that time, a great wonder, because it involved earning money, and money that was honestly earnt was a precious short commodity at Netscape in those days. To cut a long story off at the knees, Netscape put together a variant of the HTTP protocol layered over crypto. This was sold in addition to its servers as the way to secure credit card payments over the net. The analysis of the designers of SSL indicated that the threat model included the MITM. On what did they found this? It's hard to pin it down, and it may very well be, being blessed with nearly a decade's more experience, that the inclusion of the MITM in the threat model is simply best viewed as a mistake. Consider this simple fact: There has been no MITM attack, in the lifetime of the Internet, that has recorded or documented the acquisition and fraudulent use of a credit card (CC). (Over any Internet medium.) Even worse, there's not been any known MITM of any aggresive form. The only cases known are a bunch of demos, under laboratory conditions. They don't count, and MITM remains a theoretical attack, more the subject of learnings and design exercises than the domain of business or crypto engineering. How hard is this fact? A bit softish, actually, but given the amount of traffic we have seen in the last decade, one would think that MITMs would have made their appearance in aggressive attacks by now, perhaps by scanning emails, perhaps by listening to unprotected HTTP. (In fact, there are now fertile grounds for the attack, with the advent of 802.11b. There are even kits available for it.) But so far, no cases have been found. (In fact, there isn't too much evidence, beyond the circumstantial bemoanings of those that can't, to indicate that aggressors are even passively listening, let alone trying more sophisticated MITM attacks.) Within the world of credit cards, the people who work directly within the ecommerce industry admit privately that this is true [1]. All lost credit card events are based on other attacks. Which leads one to wonder what the threat is? And if there is a threat? That is, should the MITM be in the threat model for SSL, or should it be excluded? Internet cryptography gives us one answer: If it can be protected against, it should be, as to do otherwise results in a false sense of security. This is what I call "100% cryptography" for want of a better term. It's a sort of journeyman phase of crypto-plumbing, at that time when as beginners, we read from the big read book. We imagined how to deal with many dark and scary threats and we all agreed, no question, the goal was to cover more of them than the next guy. We would swap conspiracy theories well into the night, all the while, bemoaning the lack of usage of real cryptography, the poverty of our opponent's wit, and the fruitiness of our cheap red wine. I miss those days, if not the product of those mad times. It was also a time where we rarely saw the real life implications of our code, deployed in a threatening environment. In short, we 100%-ers built systems based on expectations, but we did not close the feedback loop to push the real life results back into the deployed systems. Economics gives us another answer: a standard approach to deciding how to spend money. 1. estimate the average cost of each attack. 2. estimate the number of attacks 3. multiply the above two to get a total cost. 4. likewise, estimate the total cost of avoiding the attacks. 5.a if you can avoid these attacks by spending less money, you profit. 5.b if you spend more than you save, you lose. It's just economics, and statistics, and the validity here is simply that credit cards are nothing if they are not economically- and statistically-based models of commerce and fraud. So, let's guess the cost of each CC lost to our MITM as $1000. (Pick your own number if you don't like that one.) Then, how many attacks? None, from the above. Multiplied together, and you get ... nothing. What does that mean? This theory predicts that if you spend one cent protecting against the MITM, you lose. Because according to an economics and statistics analysis, based on there being no measurable risk to you of MITM, there is no reason to spend any money to avoid it. If one believes in economics - or, at least, the above risks and costs model, then it becomes very important indeed to quantify the threat. If there is no experience of MITMs and there are no consequent costs, then the model suggests no threat. Is there a compromise? Well, there is the other side of the equation. Let's look at that: the inclusion of MITM protection comes at a cost. That cost should be estimated and compared to the losses from any MITMs. (If there were any. Regardless, we can be more ready for that day; I feel in my bones it is going to happen one day. I mean, 10 million unprotected sites, there's gotta be a time coming soon!) A "good" server cert costs about $700. The average cost of installing it - from start to finish - at an average company seems to run to many days elapsed, but let's estimate it at 6 hours time. Why so long? Because it is infrequent and unautomated. There are dozens of single steps to go through. Due diligence, documents, and the like all of which befuddle the techie, challenge the manager, and daunt the quality controller. Call the cost at your average western company as $50 per hour, and we have an estimate of $300 for time. Forget other costs, but what we can do is estimate the cost per certificate as $1000 as a ballpark. I think it is more, but call it $1000. Multiply by the number of certificates in operation, about 100,000, and we get a cost incurred of $100 million to protect against the MITM. Every year, or however often the certificates expire, we, as a networked society, are spending $100 million dollars to avert something that doesn't exist. Back to that compromise. Imagine 10 MITMs successfully steal credit cards and organise successful heists of $1000 each. $10,000 of value is thus being protected. Society - that's us, all of us - is losing big time. We would need to see 100,000 MITMs at that size to justify the infrastructure. Or, 100 sheiks with million dollar cards! And that's just to break even. We need more to cut a profit. This is totally ludicrous. These numbers are just unmalleable to achieving any sort of aggregate benefit to society. So, we can suggest that, not only is there no measureable threat from the MITM (Mallory is not to be found anywhere near any credit cards known to the issuers of same) there is also rampant waste going on in protecting servers against some imagined bogey man with a silly name like Mallory. Now, for a particular server, any given server, it *might* be prudent to protect against the MITM. Maybe the server owner has a higher threat model than the ordinary purveyor of goods. Maybe the users demand it. Or maybe the owner has more money and simply doesn't care about saving it. All of which is well and good, *if* the owner was solely capable of this decision. That is, spending own money. But, in the web world of today, the owner has no choice. If encrypted communications are required - useful to stop a simple listening attack - then a certificate is required! The software mandates it: mostly the browsers, but also the servers, are configured to kick up a stink at the thought of talking to a site that has no certificate. As such, SSL, as implemented, shows itself to include a gross failure of engineering. The threat is not present, but the browsers mandate the protection. As they migrate from unprotected to protected browsing, users are coralled into certware, as if that made any difference. Clearly, the browsers should not discriminate against cert-less browsing opportunities. Indeed, I'd go further. If a self-signed cert was encountered, the browser should praise the user's choice: Congratulations! You have selected a site that wisely protects our communications with a FREEDOM CERTIFICATE, designed to thwart scurillous and undesired spies and help win the war against the axis of evil listeners! As the servers cannot communicate so readily with the user, they would have to limit their fight against waste and misallocated resources by configuring with the best protection fastest and up front. Automatically generated self- signed FREEDOM CERTIFICATES, as a convenient temporary measure until widespread Anonymous- Diffie-Hellman is deployed in the field, would appear to strike the quickest and most cost- effective blow for Browsing Liberty [2]. iang [1] See for example, Lynn Wheeler, 17th March, 2003: .... Now SSL protects credit card numbers while in flight. However, we never actually saw a reported exploit against credit card numbers in flight. All the reported instances of major credit card exploits have to do with harvesting of credit card merchant files ... at rest at the merchant. So for the major exploit, SSL has no effect on. http://www.garlic.com/~lynn/subpubkey.html#fraud [2] AFAIR, Anonymous-Diffie-Hellman, or ADH, is inside the SSL/TLS protocol, and would represent a mighty fine encrypted browsing opportunity. Write to your browser coder today and suggest its immediate employment in the fight against the terrorists with the flappy ears. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From iang at systemics.com Mon Mar 24 11:00:01 2003 From: iang at systemics.com (Ian Grigg) Date: Mon, 24 Mar 2003 11:00:01 -0500 Subject: Keysigning @ CFP2003 In-Reply-To: <1048371179.24681.32.camel@liberate.anize.org> References: <1048371179.24681.32.camel@liberate.anize.org> Message-ID: <200303241100.01141.iang@systemics.com> On Saturday 22 March 2003 17:12, Douglas F. Calvert wrote: > I will be organizing a keysigning session for CFP2003. Please submit > your keys to cfp-keys at anize.org and I will print out sheets with key > information in order to speed up the process. Bring a photo ID and a > copy of your key information so that you can verify what is on the > printout. A list of submitted keys and a keyring will be available on: I must be out of touch - since when did PGP key signing require a photo id? -- iang --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From astiglic at okiok.com Mon Mar 24 11:33:30 2003 From: astiglic at okiok.com (Anton Stiglic) Date: Mon, 24 Mar 2003 11:33:30 -0500 Subject: Cryptoprocessors compliant with FIPS 140-2 References: <000701c2efc4$e88b31a0$8023ce88@eeng.dcu.ie> Message-ID: <006701c2f223$1ca619e0$3d976395@p1038mobile> The list of all FIPS 140-1 and 140-2 validated modules can be found here http://csrc.nist.gov/cryptval/140-1/1401val.htm (this includes software and hardware modules). For "Mitigation of Other Attacks", the FIPS 140 evaluation doesn't look at these. Some vendors might consider these attacks and implement some kind of protection, but these will not be evaluated. Documentation for a specific module might discuss countermeasures to these attacks if they have been implemented. --Anton ----- Original Message ----- From: "Damien O'Rourke" To: Sent: Friday, March 21, 2003 11:14 AM Subject: Cryptoprocessors compliant with FIPS 140-2 > Hi, > > I was wondering if anyone could list a number of cryptographic processors > that are compliant with the Federal information processing standard (FIPS) > 140-2 "Security Requirements for cryptographic modules". I know that the > IBM-4758 was compliant with FIPS 140-1 up to level 4 but I don't think > it has been tested under the newer version of the standard (correct me if > I'm > wrong). Specifically I am wondering about section 4.11 on page 39 entitled > "Mitigation of Other Attacks" which discusses, power analysis, timing > attacks, > TEMPEST and fault induction. > > If you could tell me what level they have been certified to and where I > might > find some more information on them that would be great. In fact, any > relevant > information would be greatly appreciated. Thanks for your time. > > Best Regards, > Damien. > > > --------------------------------------------------------------------- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com > --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From rsalz at datapower.com Mon Mar 24 11:29:08 2003 From: rsalz at datapower.com (Rich Salz) Date: Mon, 24 Mar 2003 11:29:08 -0500 Subject: Cryptoprocessors compliant with FIPS 140-2 In-Reply-To: <000701c2efc4$e88b31a0$8023ce88@eeng.dcu.ie> References: <000701c2efc4$e88b31a0$8023ce88@eeng.dcu.ie> Message-ID: <3E7F3254.3040208@datapower.com> Damien O'Rourke wrote: > I was wondering if anyone could list a number of cryptographic processors > that are compliant with the Federal information processing standard (FIPS) > 140-2 "Security Requirements for cryptographic modules". NIST, the US Government Agency responsible for FIPS 140, maintains lists of certified products: http://csrc.nist.gov/cryptval/vallists.htm --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From bear at sonic.net Mon Mar 24 11:32:00 2003 From: bear at sonic.net (bear) Date: Mon, 24 Mar 2003 08:32:00 -0800 (PST) Subject: Face-Recognition Technology Improves In-Reply-To: Message-ID: On Sun, 16 Mar 2003, Eugen Leitl wrote: >There's a world of difference between a line of people each slowly >stepping through the gate past a sensor in roughly aligned orientation and >a fixed-orientation no-zoom low-resolution camera looking at a group of >freely behaving subjects at varying illumination. The problem is that's exactly the sort of barrier that goes away over time. We face the inevitable advance of Moore's Law. The prices on those cameras are coming down, and the prices of the media to store higher-res images (which plays a major part in how much camera people decide is worth the money) is coming down even more rapidly. Face recognition was something that was beyond our computing abilities for a long time, but the systems are here now and we have to decide how to deal with them - not on the basis of what they are capable of this month, but on the basis of what kind of society they enable in coming decades. Also, face recognition is not like cryptography; you can't make your face sixteen bits longer and stave off advances in computer hardware for another five years. These systems are here now, and they're getting better. Varied lighting, varied perspective, moving faces, pixel counts, etc -- these are all things that make the problem harder, but none of them is going to put it out of reach for more than six months or a year. Five years from now those will be no barrier at all, and the systems they have five years from now will be deployed according to the decisions we make about such systems now. Bear --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From pete at flatline.org.uk Mon Mar 24 11:37:03 2003 From: pete at flatline.org.uk (Peter Clay) Date: Mon, 24 Mar 2003 16:37:03 +0000 (GMT) Subject: Who's afraid of Mallory Wolf? In-Reply-To: <200303232310.22334.iang@systemics.com> Message-ID: On Sun, 23 Mar 2003, Ian Grigg wrote: > Consider this simple fact: There has been no > MITM attack, in the lifetime of the Internet, > that has recorded or documented the acquisition > and fraudulent use of a credit card (CC). > > (Over any Internet medium.) How do you view attacks based on tricking people into going to a site which claims to be affiliated with e.g. Ebay or Paypal, getting them to enter their login information as usual, and using that to steal money? It's not a pure MITM attack, but the current system at least makes it possible for people to verify with the certificate whether or not the site is a spoof. > So, let's guess the cost of each CC lost to our > MITM as $1000. (Pick your own number if you > don't like that one.) > > Then, how many attacks? None, from the above. > > Multiplied together, and you get ... nothing. So, you claim that a system designed to make MITM attacks impossible has not suffered a successful MITM attack. Sounds rather tautologous to me. > The software mandates it: mostly the browsers, > but also the servers, are configured to kick up > a stink at the thought of talking to a site that > has no certificate. > As such, SSL, as implemented, shows itself to > include a gross failure of engineering. The system was engineered very well to requirements with which you disagree. > [2] AFAIR, Anonymous-Diffie-Hellman, or ADH, is > inside the SSL/TLS protocol, and would represent > a mighty fine encrypted browsing opportunity. > Write to your browser coder today and suggest > its immediate employment in the fight against > the terrorists with the flappy ears. Just out of interest, do you have an economic cost/benefit analysis for the widespread deployment of gratuitous encryption? It's just not that important. If your browsing privacy is important, you're prepared to click through the alarming messages. If the value of privacy is less than the tiny cost of clicking "accept this certificate forever" for each site, then it's not a convincing argument for exposing people who don't understand crypto to the risk of MITM. Pete --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From bear at sonic.net Mon Mar 24 11:42:28 2003 From: bear at sonic.net (bear) Date: Mon, 24 Mar 2003 08:42:28 -0800 (PST) Subject: Face-Recognition Technology Improves In-Reply-To: <5.1.1.6.2.20030316110721.02edacc0@idiom.com> Message-ID: On Sun, 16 Mar 2003, Bill Stewart wrote: > But there are two sides to the problem - recording the images of the > people you're looking for, and viewing the crowd to try to find > matches. You're right that airport security gates are probably a > pretty good consistent place to view the crowd, but getting the > target images is a different problem - some of the Usual Suspects > may have police mugshots, but for most of them it's unlikely that > you've gotten them to sit down while you take a whole-face geometry > scan to get the fingerprint. I'm reasonably certain that a 'whole-face geometry scan' is a reasonable thing to expect to be able to extract from six or eight security-gate images. If you've been through the airport four or five times in the last year, and they know whose boarding pass was associated with each image, then they've probably got enough images of your face to construct it without your cooperation. And if they don't do it today, there's no barrier in place preventing them from doing it tomorrow. Five years from now, I bet the cameras and systems will be good enough to make it a one-pass operation. I'd be surprised if they don't then "scan" routinely as people go through the security booths in airports, and if you've been scanned before they make sure it matches, and if you haven't you now have a scan on file so they can make sure it matches next time. Bear --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From lynn at garlic.com Mon Mar 24 12:10:53 2003 From: lynn at garlic.com (Anne & Lynn Wheeler) Date: Mon, 24 Mar 2003 10:10:53 -0700 Subject: Who's afraid of Mallory Wolf? In-Reply-To: <200303232310.22334.iang@systemics.com> Message-ID: <4.2.2.20030324084733.00a8c870@mail.earthlink.net> At 11:10 PM 3/23/2003 -0500, Ian Grigg wrote: >Who's afraid of Mallory Wolf? slight observations ... i've heard of no cases of credit card number intercepted on the internet "in flight" (requiring crypto) ... and no known cases of MITM attack (requiring certificates) However there have been some cases of impersonation ... being directed to a counterfeit web-site. I know of no cases of that being done with DNS cache poisoning ... which is also what certificates are targeted at ... both MITM and other impersonations of various kind. the ones i'm aware of is that the person clicks on some URL and goes to that site .... which is a counterfeit website. This isn't caught by SSL ... since it just compares the domain name in the URL against the domain name in the certificate presented by the server. Since the subterfuge happens well before any DNS cache is involved ... the SSL check of matching domain names doesn't catch anything. There have also been various impersonation involving frames and other screen painting techniques. There have been cache poisonings (ip-address take over) ... there have been also incidents in the press of domain name hijacking ... sending updates to domain name infrastructure convincing them that somebody else is the new domain name owner. getting a new certificate as the new domain name owner is also a way of subverting the SSL check of matching domain names. http://www.garlic.com/~lynn/aepay4.htm#dnsinteg1 http://www.garlic.com/~lynn/aepay4.htm#dnsinteg2 people registering public keys at the same time they register domain names was one of the suggested countermeasures to domain name hijacking. There was another press thing last week regarding DNS attacks. The issue raised by the DNS attack last fall and the latest warning is that these have the potential to bring the internet to a halt. http://www.computerworld.com/securitytopics/security/story/0,10801,79576,00. html so there is some effort regarding dns integrity because of its critical importance for just having internet function at all. past dns attack refs: http://www.garlic.com/~lynn/2003.html#49 also http://www.computerworld.com/securitytopics/security/cybercrime/story/0,1080 1,75564,00.html http://www.zdnetindia.com/news/commentary/stories/73781.html http://www.zdnetindia.com/print.html?iElementId=73777 from a cost of business standpoint ... i've suggested why not use the existing DNS infrastructure to distribute server public keys in the same way they distribute ip-address (they are pieces of information bound to the domain name, a function of the domain name infrastructure).... and are capable of distributing other things ... like administrative & technical contacts .... although that is getting restricted ... some bleed over from pkix http://www.garlic.com/~lynn/aadsm13.htm#38 The case against directories http://www.garlic.com/~lynn/aadsm14.htm#0 The case against directories they could be naked public keys ... which would also be subject to DNS cache poisoning ... or they could be "signed" public keys .... doesn't need all the baggage of x509 certs ... can just be really simple signed public key. Slightly related to the above posting about long ago and far away .... when looking at allowing people (20 plus years ago) on business trips to use portable terminals/PCs to dial in and access the internal network/email .... a vulnerability assesement found that one of the highest problem areas was hotel PBXs. as a result a special 2400 baud encrypting modem was created. encrypting modem anecdote from the time: http://www.garlic.com/~lynn/2002d.html#11 Security Proportional to Risk (was: IBM Mainframe at home) ... these weren't in any related to the link encrypters from the previous reference (aka supposedly over half of the link encrypters in the world were installed on the internal network). in any case, there was a big concern about numerous kinds of evesdropping ... requiring encryption for information hiding. however, the current internet credit card scenario seems to be that it is so much easier to harvest a whole merchant file with tens or hundreds of thousands of numbers ... than trying to get them one or two at a time off some internet connection. note that the x9.59 approach has always been to remove the credit card numbers as a point of attack (form of shared-secret) by requiring all transactions to be authenticated. as a result, just knowing the number isn't sufficient for fraud (countermeasure against all account number harvesting .... regardless of the technique and whether insider or outsider attack): http://www.garlic.com/~lynn/index.html#x959 the low-hanging fruit theory is that if merchant sites were armored then there could be more interest in evesdropping-based harvesting ... (leading to more demand for internet encryption). However. armoring merchant sites is difficult since 1) there are potentially millions, 2) human mistake is frequent/common vulnerability, 3) still leaves insiders as threat. other parts of security proportional to risk thread: http://www.garlic.com/~lynn/2002d.html#8 Security Proportional to Risk (was: IBM Mainframe at home) http://www.garlic.com/~lynn/2002d.html#9 Security Proportional to Risk (was: IBM Mainframe at home) http://www.garlic.com/~lynn/2002d.html#11 Security Proportional to Risk (was: IBM Mainframe at home) http://www.garlic.com/~lynn/2002d.html#24 Security Proportional to Risk (was: IBM Mainframe at home) http://www.garlic.com/~lynn/2002d.html#25 Security Proportional to Risk (was: IBM Mainframe at home) http://www.garlic.com/~lynn/2002d.html#28 Security Proportional to Risk (was: IBM Mainframe at home) -- Anne & Lynn Wheeler http://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From lynn at garlic.com Mon Mar 24 12:21:47 2003 From: lynn at garlic.com (Anne & Lynn Wheeler) Date: Mon, 24 Mar 2003 10:21:47 -0700 Subject: Who's afraid of Mallory Wolf? (addenda) In-Reply-To: <200303232310.22334.iang@systemics.com> Message-ID: <4.2.2.20030324101407.00b52a90@mail.earthlink.net> .... and while I don't know of any internet-based evesdropping for account number harvesting .... there are numerous reports of skimming in the physical world .... harvesting of account numbers by all sorts of techniques. These include things like video cameras by crooks trained on various kinds of POS and other terminals. misc. skimming references: http://www.garlic.com/~lynn/aadsm12.htm#40 In Brief: Anti-'Skimming' Guidelines Coming http://www.garlic.com/~lynn/aadsm12.htm#57 eBay Customers Targetted by Credit Card Scam http://www.garlic.com/~lynn/aadsm6.htm#pcards The end of P-Cards? http://www.garlic.com/~lynn/aadsm6.htm#pcards2 The end of P-Cards? (addenda) http://www.garlic.com/~lynn/aadsm6.htm#pcards3 The end of P-Cards? (addenda) http://www.garlic.com/~lynn/aepay10.htm#3 High-tech Thieves Snatch Data From ATMs (including PINs) http://www.garlic.com/~lynn/aepay10.htm#41 ATM Scams - Whose Liability Is It, Anyway? http://www.garlic.com/~lynn/aepay10.htm#44 Credit Card Skimming Rising In The US http://www.garlic.com/~lynn/aepay6.htm#ccfraud2 "out of control credit card fraud" http://www.garlic.com/~lynn/aepay9.htm#skim High-tech Thieves Snatch Data From ATMs (including PINs) http://www.garlic.com/~lynn/2001f.html#40 Remove the name from credit cards! http://www.garlic.com/~lynn/2002i.html#74 A Lesson In Security http://www.garlic.com/~lynn/2002j.html#60 How to map a user account to a digital cert? http://www.garlic.com/~lynn/2002j.html#63 SSL integrity guarantees in abscense of client certificates http://www.garlic.com/~lynn/2002l.html#20 Backdoor in AES ? http://www.garlic.com/~lynn/2002m.html#36 (OT) acceptance of technology, was: Convenient and secure -- Anne & Lynn Wheeler http://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From smb at research.att.com Mon Mar 24 13:02:37 2003 From: smb at research.att.com (Steven M. Bellovin) Date: Mon, 24 Mar 2003 13:02:37 -0500 Subject: Who's afraid of Mallory Wolf? In-Reply-To: Your message of "Sun, 23 Mar 2003 23:10:22 EST." <200303232310.22334.iang@systemics.com> Message-ID: <20030324180237.B0AB77B4D@berkshire.research.att.com> In message <200303232310.22334.iang at systemics.com>, Ian Grigg writes: >Who's afraid of Mallory Wolf? > > >Even worse, there's not been any known MITM of >any aggresive form. The only cases known are >a bunch of demos, under laboratory conditions. >They don't count, and MITM remains a theoretical >attack, more the subject of learnings and design >exercises than the domain of business or crypto >engineering. Sorry, that's flat-out false. If nothing else, there was a large-scale MITM attack on the conference 802.11 net at the 2001 Usenix Security Symposium. Spammers are hijacking BGP prefixes; see http://www.merit.edu/mail.archives/nanog/2002-10/msg00068.html for one such incident. Eugene Kashpureff was pleaded guilty to domain-name hijacking; used very slightly differently, that's a MITM attack. See http://www.usdoj.gov/criminal/cybercrime/kashpurepr.htm for details. I warned of the possibility of hijacking via routing attacks in 1989, and via DNS attacks in 1995. (See the 'papers' directory on my Web site.) Given that the attacks were demonstrably feasible, Netscape would have been negligent not to design for it. Given that such attacks or their near cousins have actually occurred, I'd say they were right. And yes, you're probably right that no one has stolen credit card numbers that way. Of course, since the defense was in place before people had an opportunity to try, one can quite plausibly argue that Netscape prevented the attack.... --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From nobody at dizum.com Mon Mar 24 13:20:02 2003 From: nobody at dizum.com (Nomen Nescio) Date: Mon, 24 Mar 2003 19:20:02 +0100 (CET) Subject: Brumley & Boneh timing attack on OpenSSL Message-ID: <279f7c15c754f6304687a90be549e267@dizum.com> Regarding using blinding to defend against timing attacks, and supposing that a crypto library is going to have support for blinding: - Should it do blinding for RSA signatures as well as RSA decryption? - How about for ElGamal decryption? - Non-ephemeral (static) DH key exchange? - Ephemeral DH key exchange? - How about for DSS signatures? In other words, what do we need as far as blinding support either in developing a crypto library or in evaluating a crypto library for use? Suppose we are running a non-SSL protocol but it is across a real-time Internet or LAN connection where timing attacks are possible. And suppose our goal is not to see a paper and exploit published within the next three years telling how to break the protocol's security with a few hours of connect time. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From novalis at novalis.org Mon Mar 24 14:11:22 2003 From: novalis at novalis.org (David Turner) Date: 24 Mar 2003 14:11:22 -0500 Subject: Who's afraid of Mallory Wolf? In-Reply-To: <200303232310.22334.iang@systemics.com> References: <200303232310.22334.iang@systemics.com> Message-ID: <1048533083.27535.40342.camel@banks> Grigg counts the benefits of living in a MITM-protected world (no MITM attacks recorded), as though they would happen with or without MITM protection. Is there any reason to believe that's this is, in fact, true? That is, if zero dollars were spent on MITM protection, would there still be no recoreded attacks? Until that's answered, Grigg's "economic" analysis is flawed. "I used to get picked on, but since I bulked up and learned karate, nobody's picked on me. I guess it was pointless to do those things." On Sun, 2003-03-23 at 23:10, Ian Grigg wrote: > The question arises, why? For what reason is > the MITM a core part of the SSL threat model? > And, why do all the implementations assume this? [...] > The analysis of the designers of SSL indicated > that the threat model included the MITM. [...] > Consider this simple fact: There has been no > MITM attack, in the lifetime of the Internet, > that has recorded or documented the acquisition > and fraudulent use of a credit card (CC). -- -Dave Turner Stalk Me: 617 441 0668 "I believe there is no righteousness in the situation in which we find ourselves." -Real Live Preacher --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From lynn at garlic.com Mon Mar 24 14:29:17 2003 From: lynn at garlic.com (Anne & Lynn Wheeler) Date: Mon, 24 Mar 2003 12:29:17 -0700 Subject: Armoring websites In-Reply-To: <200303232310.22334.iang@systemics.com> Message-ID: <4.2.2.20030324122023.00b78100@mail.earthlink.net> ref: http://www.garlic.com/~lynn/aadsm14.htm#1 Who's afraid of Mallory Wolf? http://www.garlic.com/~lynn/aadsm14.htm#2 Who's afraid of Mallory Wolf? (addenda) here is discussion of armoring websites with respect to security proportional to what is at risk http://www.garlic.com/~lynn/2001h.html#61 net banking, is it safe??? http://www.garlic.com/~lynn/aepay7.htm#netbank2 net banking, is it safe?? ... security proportional to risk random refs to hardened sites: http://www.garlic.com/~lynn/aadsm2.htm#risk another characteristic of online validation. http://www.garlic.com/~lynn/2001.html#33 Where do the filesystem and RAID system belong? http://www.garlic.com/~lynn/2002.html#44 Calculating a Gigalapse http://www.garlic.com/~lynn/2002m.html#5 Dumb Question - Hardend Site ? http://www.garlic.com/~lynn/2002m.html#6 Dumb Question - Hardend Site ? http://www.garlic.com/~lynn/2002o.html#14 Home mainframes http://www.garlic.com/~lynn/2003c.html#52 diffence between itanium and alpha -- Anne & Lynn Wheeler http://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From trevp at trevp.net Mon Mar 24 14:35:23 2003 From: trevp at trevp.net (Trevor Perrin) Date: Mon, 24 Mar 2003 11:35:23 -0800 Subject: Who's afraid of Mallory Wolf? In-Reply-To: <200303232310.22334.iang@systemics.com> Message-ID: <5.2.0.9.0.20030324113245.02eb5650@postoffice.pacbell.net> At 11:10 PM 3/23/2003 -0500, Ian Grigg wrote: >Automatically generated self- >signed FREEDOM CERTIFICATES, as a convenient >temporary measure until widespread Anonymous- >Diffie-Hellman is deployed in the field, would >appear to strike the quickest and most cost- >effective blow for Browsing Liberty [2]. Even if Anonymous DH was widely deployed, it might be better to use self-signed certs, or certs signed by an untrusted root - the browser could remember the cert, and warn the user "this site has a different identity than last time". Or the browser could log the certs that are used for connections, and at some later date, if the user suspected MITM attacks, the user could review the logs for discrepancies - thus giving, if not "tamper resistance" against MITM attacks, at least the possibility for post-facto "tamper detection". However, changing https to allow untrusted root certs without warnings might not be a good idea - users expect an https URL to be authenticated, so this changes the semantics. Maybe unauthenticated, ie "opportunistic", encryption in HTTP with SSL/TLS should happen via something like the RFC 2817 upgrade mechanism? (I believe this particular mechanism has problems). The server could advertise that it supports opportunistic encryption, and a browser could choose it automatically, and the user wouldn't even be notified. Then https semantics could be left unchanged. Trevor --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From dave at netmedic.net Mon Mar 24 15:19:37 2003 From: dave at netmedic.net (dave) Date: Mon, 24 Mar 2003 15:19:37 -0500 Subject: Cryptoprocessors compliant with FIPS 140-2 In-Reply-To: <000701c2efc4$e88b31a0$8023ce88@eeng.dcu.ie> Message-ID: There are only about 310 fips-140-1/2 total validation certificates since 1995. http://csrc.nist.gov/cryptval/ Since the FIPS-140-2 was not signed in until mid-2001 there where very few in 2002 - see the 2 links below. http://csrc.nist.gov/cryptval/140-1/1401val2002.htm http://csrc.nist.gov/cryptval/140-1/1401val2003.htm _____________________ Dave Kleiman dave at netmedic.net www.netmedic.net -----Original Message----- From: owner-cryptography at wasabisystems.com [mailto:owner-cryptography at wasabisystems.com] On Behalf Of Damien O'Rourke Sent: Friday, March 21, 2003 11:14 To: cryptography at wasabisystems.com Subject: Cryptoprocessors compliant with FIPS 140-2 Hi, I was wondering if anyone could list a number of cryptographic processors that are compliant with the Federal information processing standard (FIPS) 140-2 "Security Requirements for cryptographic modules". I know that the IBM-4758 was compliant with FIPS 140-1 up to level 4 but I don't think it has been tested under the newer version of the standard (correct me if I'm wrong). Specifically I am wondering about section 4.11 on page 39 entitled "Mitigation of Other Attacks" which discusses, power analysis, timing attacks, TEMPEST and fault induction. If you could tell me what level they have been certified to and where I might find some more information on them that would be great. In fact, any relevant information would be greatly appreciated. Thanks for your time. Best Regards, Damien. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From perry at piermont.com Mon Mar 24 15:24:44 2003 From: perry at piermont.com (Perry E. Metzger) Date: 24 Mar 2003 15:24:44 -0500 Subject: Supreme Court Refuses to Review Wiretaps Ruling Message-ID: <87isu8wm0j.fsf@snark.piermont.com> >From the New York Times: Supreme Court Refuses to Review Wiretaps Ruling March 24, 2003 By DAVID STOUT WASHINGTON, March 24 - In a case balancing national security with civil liberties, the Supreme Court refused to interfere today with a lower court ruling giving the Justice Department broad new powers to use wiretaps to prosecute terrorists. The justices declined without comment to review a decision last Nov. 18 in which a special federal appeals court found that, under a law passed after the terror attacks of Sept. 11, 2001, the Justice Department can use wiretaps installed for intelligence operations to go after terrorists. That November decision was crucial, because for some two decades there was presumed to be a "wall" between wiretap operations for intelligence-gathering and wiretapping in the course of criminal investigations. Obtaining permission for a wiretap to gather intelligence has generally been easier than getting authorization for a wiretap in a straightforward criminal investigation. Thus, prosecutors were admonished not to try to skirt the tougher standards for a wiretap in a criminal investigation by claiming it was actually to gather intelligence. The landscape changed with the passage of legislation, shortly after the Sept. 11 attacks, broadening government surveillance powers. Justice Department investigators applied last May for permission to wiretap an individual who was identified in court papers only as a resident of the United States. The department met resistance from the three-member Foreign Intelligence Surveillance Act Court, which exists solely to administer a 1978 law allowing the government to conduct intelligence wiretaps inside the United States. That court ordered the Justice Department to show that its primary purpose in applying for the wiretap was intelligence gathering and not for a criminal case. Moreover, the three-member court decreed that prosecutors in the Justice Department's criminal division could not take an active role in directing activities of the department's intelligence division. Attorney General John Ashcroft appealed to the United States Foreign Intelligence Surveillance Court of Review, which had never met before and which exists, like the lower court, only to oversee the 1978 law. The court of review ruled in November that the lower court had erred when it tried to impose restrictions on the Justice Department. Furthermore, the court of review said, there never was supposed to be a "wall" between intelligence gathering and criminal investigations. "Effective counterintelligence, as we have learned, requires the wholehearted cooperation of all the government's personnel who can be brought to the task," the review panel wrote. "A standard which punishes such cooperation could well be thought dangerous to national security." The review panel criticized the lower court, declaring that it had improperly tried to tell the Justice Department how to do its business, in violation of the Constitution's separation of powers between equal branches of government. The Court of Review is made up of Judges Ralph B. Guy of the United States Court of Appeals for the Sixth Circuit; Edward Leavy of the Court of Appeals for the Ninth Circuit; and Laurence H. Silberman of the Court of Appeals for the District of Columbia Circuit. All were appointed to the panel by Chief Justice William H. Rehnquist of the Supreme Court. Mr. Ashcroft praised the November decision as one that "revolutionizes our ability to investigate terrorists and prosecute terrorist acts." But the American Civil Liberties Union, the National Association of Criminal Defense Lawyers, the American-Arab Anti-Discrimination Committee and the Arab Community Center for Economic and Social Services, a Michigan-based organization, assailed the November decision. "These fundamental issues should not be finally adjudicated by courts that sit in secret, do not ordinarily publish their decisions, and allow only the government to appear before them," the groups said in asking the Supreme Court to review it. The A.C.L.U. and its allies had only friend-of-the-court status in the case, since technically the Justice Department was the only party. Thus, it was not surprising that the Supreme Court declined today to review the lower courts' decision. http://www.nytimes.com/2003/03/24/politics/24CND-SCOT.html?ex=1049536949&ei=1&en=6cbee835b0f1acbe -- Perry E. Metzger perry at piermont.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From iang at systemics.com Mon Mar 24 15:26:59 2003 From: iang at systemics.com (Ian Grigg) Date: Mon, 24 Mar 2003 15:26:59 -0500 Subject: Who's afraid of Mallory Wolf? In-Reply-To: References: Message-ID: <200303241526.59727.iang@systemics.com> On Monday 24 March 2003 11:37, Peter Clay wrote: > On Sun, 23 Mar 2003, Ian Grigg wrote: > > > Consider this simple fact: There has been no > > MITM attack, in the lifetime of the Internet, > > that has recorded or documented the acquisition > > and fraudulent use of a credit card (CC). > > > > (Over any Internet medium.) > > How do you view attacks based on tricking people into going to a site > which claims to be affiliated with e.g. Ebay or Paypal, getting them to > enter their login information as usual, and using that to steal money? Yes, that's definately an attack. As was pointed out, the use of the cert seems to do two things: stop the MITM (via a secured key exchange so the listener cannot see inside the packets) and confirm the site as per what is stated in the URL. My post of last night addressed the MITM only. I completely ignored the issue of spoofing, which would only be possible if there is no complex relationship between them - which is a debateable point. > It's not a pure MITM attack, but the current system at least makes it > possible for people to verify with the certificate whether or not the site > is a spoof. Does the cert stop spoofing? That's the question! If it does, then there might be value there. In which case we can measure it and construct a cost- benefit analysis to decide whether to protect against it. > > So, let's guess the cost of each CC lost to our > > MITM as $1000. (Pick your own number if you > > don't like that one.) > > > > Then, how many attacks? None, from the above. > > > > Multiplied together, and you get ... nothing. > > So, you claim that a system designed to make MITM attacks impossible has > not suffered a successful MITM attack. Sounds rather tautologous to me. No, there has been little evidence of MITMs *outside* the system. (I said none, Steve Bellovin said some...) The fact that there are none within the system, yes, that would only show either the attacks were defeated, or there weren't going to be any, or that there are better pickings elsewhere... It doesn't allow you to conclude anything about the need for protection. Check Lynn Wheeler's new post (thanks Lynn!) which points to a lot of inside knowledge about the absence of any aggressive MITM activity inside the credit card world. And, see Steve Bellovin's post for some evidence of MITM outside the credit card world. > > The software mandates it: mostly the browsers, > > but also the servers, are configured to kick up > > a stink at the thought of talking to a site that > > has no certificate. > > > As such, SSL, as implemented, shows itself to > > include a gross failure of engineering. > > The system was engineered very well to requirements with which you > disagree. :-) Terms are always debatable! I'd say that engineering *includes* the appropriateness of the requirements. Science does not. Where I would agree: the _protocol_ was engineered very well to meet its requirements. It's not a bad protocol, by any logic. However, no protocol exists within a vacuum, this one exists within a _system_ that is commonly also known as SSL. (Therein lies a big problem here: I know of no separate term to distinguish SSL the protocol from SSL, the secure browsing system that you or I use to send our credit card numbers safely.) > > [2] AFAIR, Anonymous-Diffie-Hellman, or ADH, is > > inside the SSL/TLS protocol, and would represent > > a mighty fine encrypted browsing opportunity. > > Write to your browser coder today and suggest > > its immediate employment in the fight against > > the terrorists with the flappy ears. > > Just out of interest, do you have an economic cost/benefit analysis for > the widespread deployment of gratuitous encryption? No, but it would be an interesting exercise! > It's just not that important. It's interesting that you say that ... why is it then that people like Ben Laurie, Eric Young, Eric Rescola and others spent years writing and deploying software for free? Why do the people at Safari and Mozilla and Konqueror also spend all that time getting SSL to work? I don't claim to know the answer. But, if their answer is "to protect credit card numbers" well, actually, I don't think so! And that's the point of the rant: to identify some of these underlying assumptions like "SSL protects your credit card numbers" and reveal the truth or otherwise. Hopefully, if we can strip out the myths, we'll find the truth. > If your browsing privacy is important, > you're prepared to click through the alarming messages. If the value of > privacy is less than the tiny cost of clicking "accept this certificate > forever" for each site, then it's not a convincing argument for exposing > people who don't understand crypto to the risk of MITM. People don't think like us techies do. They see the messages, and they ask for explanations from other people. Who may or may not know what it all means. The end result is the lowest common denominator - if there is a message, then something is wrong. And that's the point: if there is nothing wrong, the browser shouldn't say there is something wrong! So, what is this "risk of MITM" that the browser is protecting us against? -- iang --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From iang at systemics.com Mon Mar 24 16:06:38 2003 From: iang at systemics.com (Ian Grigg) Date: Mon, 24 Mar 2003 16:06:38 -0500 Subject: Who's afraid of Mallory Wolf? In-Reply-To: <20030324180237.B0AB77B4D@berkshire.research.att.com> References: <20030324180237.B0AB77B4D@berkshire.research.att.com> Message-ID: <200303241606.38157.iang@systemics.com> On Monday 24 March 2003 13:02, Steven M. Bellovin wrote: > In message <200303232310.22334.iang at systemics.com>, Ian Grigg writes: > >Who's afraid of Mallory Wolf? > > > > > > >Even worse, there's not been any known MITM of > >any aggresive form. The only cases known are > >a bunch of demos, under laboratory conditions. > >They don't count, and MITM remains a theoretical > >attack, more the subject of learnings and design > >exercises than the domain of business or crypto > >engineering. > > Sorry, that's flat-out false. If nothing else, there was a large-scale > MITM attack on the conference 802.11 net at the 2001 Usenix Security > Symposium. Thanks Steve, now we are getting closer. 802.11b is where I'd been expecting it to happen, as the costs of the MITM come right down there. Would you characterise the attack as a bunch of techies mucking around, or would you characterise it as an aggressive attempt to gain a commercial advantage? I.e., did the attackers steal anything? Or did they just annoy people by showing how cool they were? I would surmise that's a techie conference, and is thus a demonstration, not a measurable risk. > Spammers are hijacking BGP prefixes; see > http://www.merit.edu/mail.archives/nanog/2002-10/msg00068.html > for one such incident. I'm can't see clearly whether this is an MITM or a spoofing - did they stand in the middle and listen and divert? Or, did they just tell innocent servers to start re-routing traffic? It seems like an announcement of routes, and the listeners just believed... (But, it is an aggressive attack, someone tried to steal traffic for commercial gain.) I think you may be right in that my use of the term MITM is too broad. The cert in SSL protects against a cryptographic MITM in, for example, an ADH session. But, MITMs outside that are important measurable risks so we can create our threat model. The fact that this attack appears not to be analogous to the SSL-style MITM may or may not be relevant. > Eugene Kashpureff was pleaded guilty to domain-name hijacking; used > very slightly differently, that's a MITM attack. See > http://www.usdoj.gov/criminal/cybercrime/kashpurepr.htm for > details. >From what I recall, this was a "demo". He didn't do it to steal. He did it to highlight the business aspects. Sadly for him, he miscalculated (grossly, it seems). But, his case fits in the sense of "not a criminal seeking to steal value," and therefore not a case of measurable risk. > I warned of the possibility of hijacking via routing attacks in 1989, > and via DNS attacks in 1995. (See the 'papers' directory on my Web > site.) I certainly accept them as possible. That's not disputed, and never has been, as indeed, that was the whole thrust of the discussion: The SSL designers put the protection in because the threat was possible. They quite rightly offered the choice in the protocols. Where I am concerned is that they also wrongly forced the certificate path on browsers and servers. To our detriment, and to theirs.) > Given that the attacks were demonstrably feasible, Netscape > would have been negligent not to design for it. Given that such attacks > or their near cousins have actually occurred, I'd say they were right. No, I'm afraid that does not hold. The reason we protect against attacks is because when they happen, they incur costs. But, designing in protection also incurs costs. We must do a cost-benefit analysis to decide if it is appropriate to protect against it. To say that attacks are "feasible" and therefore must be defended against is not how we work. We can guaruntee that you are immune to car accidents, simply by asking you to stay at home. You (probably) chose not to do so, because you chose to enjoy the higher benefit of travelling, as against the smaller expected cost of a suffering an accident. > And yes, you're probably right that no one has stolen credit card numbers > that way. Of course, since the defense was in place before people > had an opportunity to try, one can quite plausibly argue that Netscape > prevented the attack.... Right. But it's an empty argument if there is no need. We don't carry umbrellas when the sun is shining, only when the sky is grey. And, we don't build meteorite protection at all, even though we could, and they happen! We use information about real threats and how they hurt us to decide whether to worry about them. And that's why the question about MITMs is so key! The question is, is there a need? From several economic points of view, the need fails to show itself. And, the cost is quite high, both in cash, and lost security. Taking your links above at face value, I'll assume that the cost of stolen/hijacked IP number there was about $10,000 in lost business and customers being annoyed at unexpected porn. Say that happens once a metric month to some random victim ... or, $100,000 per year. That cost simply fails to justify any level of signed-certificate infrastructure, so, I'd conclude that the BGP protocol designers have done exactly the right thing in not deploying certs, and saved the users a bundle. (And, Netscape has done exactly the wrong thing by setting up CA-signed certs as required.) The fact that the MITM is possible, doesn't make for a need. Especially when we are all paying O($100m) per year for that possibility. Thanks for the MITM pointers. I'm going to have to look deeper into that BGP think to see whether I'm wrong on the "none at all" case. MITMs are going to happen one day, and then, we will be able to properly measure the costs. That's where we want to be! -- iang --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From daw at mozart.cs.berkeley.edu Mon Mar 24 17:02:43 2003 From: daw at mozart.cs.berkeley.edu (David Wagner) Date: 24 Mar 2003 22:02:43 GMT Subject: Who's afraid of Mallory Wolf? References: <200303232310.22334.iang@systemics.com> Message-ID: Ian Grigg wrote: >By common wisdom, SSL is designed to defeat >the so-called "Man in the Middle" attack, or >MITM for short. > >The question arises, why? One possible reason: Because DNS is insecure. If you can spoof DNS, you can mount a MITM attack. A second possible reason: It's hard to predict what attacks will become automated. Internet attacks seem to have an all-or-nothing feel: either almost noone exploits them, or they get exploited en masse. The latter ones can be really painful, if you haven't built in protection in advance. You could take your argument even further and ask whether any crypto was needed at all. After all, most attacks have worked by compromising the endpoint, not by sniffing network traffic. I'll let you decide whether to count this as a success story for SSL, or as indication that the crypto wasn't needed in the first place. (I'm a little skeptical of this argument, by the way, but hey, if we're playing devil's advocate, why not aim high?) --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From daw at mozart.cs.berkeley.edu Mon Mar 24 18:22:05 2003 From: daw at mozart.cs.berkeley.edu (David Wagner) Date: 24 Mar 2003 23:22:05 GMT Subject: Brumley & Boneh timing attack on OpenSSL References: <279f7c15c754f6304687a90be549e267@dizum.com> Message-ID: Nomen Nescio wrote: >Regarding using blinding to defend against timing attacks, and supposing >that a crypto library is going to have support for blinding: > > - Should it do blinding for RSA signatures as well as RSA decryption? > - How about for DSS signatures? My guess is that it's not necessary, as the attacker doesn't have as much control over the input to the modular exponentiation process in the case of RSA signatures. (For RSA decryption, the attacker can specify the ciphertext freely. However, for signatures, the input to the modular exponentiation is a hash of the attacker's chosen input, which gives the attacker a lot less freedom to play Bleichenbacher-like games.) But then, the recent Klima-Pokorny-Rosa paper shows how even just a tiny crack can lead to subtle, totally unexpected attacks. Who would have thought that SSL's version rollback check (two bytes in the input to the modular exponentiation) could enable such a devastating attack? Not me. The Boneh-Brumley and KPR papers have made me much more paranoid about side-channel attacks. As a result, I might turn blinding on even for signatures by default, out of caution, even though I can't see how such an attack could possibly work. > - How about for ElGamal decryption? > - Non-ephemeral (static) DH key exchange? Yes, I think I'd use side channel defenses (like blinding) here. I don't know of any attacks off the top of my head, but it sure seems plausible to me that there might be some. > - Ephemeral DH key exchange? I wouldn't tend to be very worried about ephemeral exchanges, since all the attacks we've seen so far require many interactions with the server with the same key. I could be wrong, but this seems pretty safe to me. >In other words, what do we need as far as blinding support either in >developing a crypto library or in evaluating a crypto library for use? > >Suppose we are running a non-SSL protocol but it is across a real-time >Internet or LAN connection where timing attacks are possible. And suppose >our goal is not to see a paper and exploit published within the next >three years telling how to break the protocol's security with a few >hours of connect time. Good question. Personally, I'd enable side channel defenses (like blinding) by default in the crypto library in every place that the library does some lengthy computation with a long-lived secret. But I'll be interested to hear what others think. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From egerck at nma.com Mon Mar 24 18:57:18 2003 From: egerck at nma.com (Ed Gerck) Date: Mon, 24 Mar 2003 15:57:18 -0800 Subject: Who's afraid of Mallory Wolf? References: <200303232310.22334.iang@systemics.com> Message-ID: <3E7F9B5E.A3E29595@nma.com> Ian Grigg wrote: > ... > The analysis of the designers of SSL indicated > that the threat model included the MITM. > > On what did they found this? It's hard to pin > it down, and it may very well be, being blessed > with nearly a decade's more experience, that > the inclusion of the MITM in the threat model > is simply best viewed as a mistake. I'm sorry to say it but MITM is neither a fable nor restricted to laboratory demos. It's an attack available today even to script kiddies. For example, there is a possibility that some evil attacker redirects the traffic from the user's computer to his own computer by ARP spoofing. With the programs arpspoof, dnsspoof and webmitm in the dsniff package it is possible for a script kiddie to read the SSL traffic in cleartext (list of commands available if there is list interest). For this attack to work the user and the attacker must be on the same LAN or ... the attacker could be somewhere else using a hacked computer on the LAN -- which is not so hard to do ;-) >... > Clearly, the browsers should not discriminate > against cert-less browsing opportunities The only sign of the spoofing attack is that the user gets a warning about the certificate that the attacker is presenting. It's vital that the user does not proceed if this happens -- contrary to what you propose. BTW, this is NOT the way to make paying for CA certs go away. A technically correct way to do away with CA certs and yet avoid MITM has been demonstrated to *exist* (not by construction) in 1997, in what was called intrinsic certification -- please see www.mcg.org.br/cie.htm Cheers, Ed Gerck --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From iang at systemics.com Mon Mar 24 19:03:50 2003 From: iang at systemics.com (Ian Grigg) Date: Mon, 24 Mar 2003 19:03:50 -0500 Subject: Who's afraid of Mallory Wolf? In-Reply-To: <1048533083.27535.40342.camel@banks> References: <200303232310.22334.iang@systemics.com> <1048533083.27535.40342.camel@banks> Message-ID: <200303241903.50570.iang@systemics.com> On Monday 24 March 2003 14:11, David Turner wrote: > Grigg counts the benefits of living in a MITM-protected world (no MITM > attacks recorded), as though they would happen with or without MITM > protection. Is there any reason to believe that's this is, in fact, > true? That is indeed the question, sans personal issues. > That is, if zero dollars were spent on MITM protection, would > there still be no recoreded attacks? Actually, I think that if zero dollars had been spent on MITM protection for SSL, then there may well have been some MITM attacks. That then would be a good position to be in, because we could measure the costs of those attacks, and decide from a monetary perspective whether protection at the level of requiring signed certificates is a good thing or just a waste of money. My own guess is that MITM activity is so low across all domains of the net that we would not be able to reliably measure it, and if we could measure it, we'd find it not sufficient to mandate certificates as is currently done. Which - to repeat - is not to remove certs from the servers or browser, but to change the way in which we assume that "only cert-protected browsing is good enough." The certs are really good for high end sites (because, economically, they return benefits even if there was no MITM threat). But why are they needed for smaller things? Why do I need a certficate to run an SSL server so that my family can share snapshots for instance? Just a hypothetical... > Until that's answered, Grigg's > "economic" analysis is flawed. > > "I used to get picked on, but since I bulked up and learned karate, > nobody's picked on me. I guess it was pointless to do those things." You provided your own answer :-) You used to get picked on, so you had a measure of its cost. You acted to defend against those costs. Did you ever get MITM'd? Anywhere? Any time? Anyone you know? -- iang --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From jeroen at vangelderen.org Mon Mar 24 19:24:55 2003 From: jeroen at vangelderen.org (Jeroen C. van Gelderen) Date: Mon, 24 Mar 2003 19:24:55 -0500 Subject: Keysigning @ CFP2003 In-Reply-To: <200303241100.01141.iang@systemics.com> Message-ID: <3423551E-5E58-11D7-B5A0-000393754B1C@vangelderen.org> On Monday, Mar 24, 2003, at 11:00 US/Eastern, Ian Grigg wrote: > On Saturday 22 March 2003 17:12, Douglas F. Calvert wrote: > >> I will be organizing a keysigning session for CFP2003. Please submit >> your keys to cfp-keys at anize.org and I will print out sheets with key >> information in order to speed up the process. Bring a photo ID and a >> copy of your key information so that you can verify what is on the >> printout. A list of submitted keys and a keyring will be available on: > > I must be out of touch - since when did > PGP key signing require a photo id? It's rather efficient if you want to sign a large number of keys of people you mostly do not know personally. -J -- Jeroen C. van Gelderen - jeroen at vangelderen.org War prosperity is like the prosperity that an earthquake or a plague brings. The earthquake means good business for construction workers, and cholera improves the business of physicians, pharmacists, and undertakers; but no one has for that reason yet sought to celebrate earthquakes and cholera as stimulators of the productive forces in the general interest. -- Ludwig von Mises --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From bear at sonic.net Mon Mar 24 19:26:08 2003 From: bear at sonic.net (bear) Date: Mon, 24 Mar 2003 16:26:08 -0800 (PST) Subject: Who's afraid of Mallory Wolf? In-Reply-To: Message-ID: On Mon, 24 Mar 2003, Peter Clay wrote: >On Sun, 23 Mar 2003, Ian Grigg wrote: > >> Consider this simple fact: There has been no >> MITM attack, in the lifetime of the Internet, >> that has recorded or documented the acquisition >> and fraudulent use of a credit card (CC). >> >> (Over any Internet medium.) There have, however, been numerous MITM attacks for stealing or eavesdropping on email. A semi-famous case I'm thinking of involves a rabid baptist minister named fred phelps and a topeka city councilwoman who had the audacity to vote against him running roughshod over the law. He set up routing tables to fool DNS into thinking his machine was the shortest distance from the courthouse where she worked to her home ISP and eavesdropped on her mail. Sent a message to every fax machine in town calling her a "Jezebellian whore" after getting the skinny on the aftermath of an affair that she was discussing with her husband. And as for theft of credit card numbers, the lack of MITM attacks directly on them is just a sign that other areas of security around them are so loose no crooks have yet had to go to that much trouble. Weakest link, remember? No need to mount a MITM attack if you're able to just bribe the data entry clerk. Just because most companies' security is so poor that it's not worth the crook's time and effort doesn't mean we should throw anyone who takes security seriously enough that a MITM vulnerability might be the weakest link to the wolves. >How do you view attacks based on tricking people into going to a site >which claims to be affiliated with e.g. Ebay or Paypal, getting them to >enter their login information as usual, and using that to steal money? These, technically speaking, are impostures, not MITM attacks. The web makes it ridiculously easy. You can use any linktext or graphic to link to anywhere, and long cryptic URL's are sufficiently standard practice that people don't actually look at them any more to notice a few characters' difference. On the occasions where people have actually spoofed DNS to route the "correct" URL to the "wrong" server in order to get info on people's accounts, that is a full-on MITM attack. And that definitely has happened. I'm surprised to hear someone claim that credit card numbers haven't been stolen that way. I've been more concerned about email than credit cards, so I don't know for sure, but if credit cards haven't been stolen this way then the guys who want them are way behind the guys who want to eavesdrop on email. >> [2] AFAIR, Anonymous-Diffie-Hellman, or ADH, is >> inside the SSL/TLS protocol, and would represent >> a mighty fine encrypted browsing opportunity. >> Write to your browser coder today and suggest >> its immediate employment in the fight against >> the terrorists with the flappy ears. > Just out of interest, do you have an economic cost/benefit analysis > for the widespread deployment of gratuitous encryption? This is a simple consequence of the fact that the main market for SSL encryption is financial transactions. And no credit card issuer wants fully anonymous transactions; it leaves them holding the bag if anything goes wrong. Anonymous transactions require a different market, which has barely begun to make itself felt in a meaningful way (read: by being willing to pay for it) to anyone who has pockets deep enough to do the development. Bear --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From jeroen at vangelderen.org Mon Mar 24 19:50:39 2003 From: jeroen at vangelderen.org (Jeroen C. van Gelderen) Date: Mon, 24 Mar 2003 19:50:39 -0500 Subject: Who's afraid of Mallory Wolf? In-Reply-To: Message-ID: On Monday, Mar 24, 2003, at 11:37 US/Eastern, Peter Clay wrote: > On Sun, 23 Mar 2003, Ian Grigg wrote: > >> Consider this simple fact: There has been no >> MITM attack, in the lifetime of the Internet, >> that has recorded or documented the acquisition >> and fraudulent use of a credit card (CC). >> >> (Over any Internet medium.) > > How do you view attacks based on tricking people into going to a site > which claims to be affiliated with e.g. Ebay or Paypal, getting them to > enter their login information as usual, and using that to steal money? > > It's not a pure MITM attack, but the current system at least makes it > possible for people to verify with the certificate whether or not the > site > is a spoof. Correct. On the other hand, in a lot of cases people cannot be expected to do the verification. This shows in the number of people that can be tricked into being spoofed out of their passwords, even when certificates are deployed. That is not an argument against certificates though, it is (partially) an argument against broken user interfaces. > Just out of interest, do you have an economic cost/benefit analysis for > the widespread deployment of gratuitous encryption? What makes you say it is gratuitous? Or: how can you state my privacy is gratuitous? > It's just not that important. If your browsing privacy is important, > you're prepared to click through the alarming messages. If the value of > privacy is less than the tiny cost of clicking "accept this certificate > forever" for each site, then it's not a convincing argument for > exposing > people who don't understand crypto to the risk of MITM. This is illogical. Even if a server operator would prefer to allow unauthenticated encryption, he cannot do so without annoying 90% of his customers because they too will be getting these alarming messages. In general, if my browsing privacy is important to me and the server operator is willing to accomodate me, he cannot do so. This however still does not constitute an argument against certificates. It can be morphed as an argument against browsers not supporting Anonymous-DH. (Note that I'm favoring treating sites offering ADH the same as sites offering a certificate. Each offers different functionality which should be distinguishable in the GUI.) Cheers, -J -- Jeroen C. van Gelderen - jeroen at vangelderen.org The python has, and I fib no fibs, 318 pairs of ribs. In stating this I place reliance On a s?ance with one who died for science. This figure is sworn to and attested; He counted them while being digested. -- Ogden Nash --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From nop at trapped-under-ice.com Mon Mar 24 21:19:57 2003 From: nop at trapped-under-ice.com (NOP) Date: Mon, 24 Mar 2003 18:19:57 -0800 Subject: Who's afraid of Mallory Wolf? References: Message-ID: <029701c2f275$083dd2c0$6f42420a@lanwan> So far, as I see it, this is not an issue of specific SSL protocol, but of unrestrictive browser to user interfacing. The only MITM attacks that have been practical valid attacks as of lately were specific to microsoft browser issues when interfacing with SSL. On another note, MITM attacks on SSL, is strictly a user education issue. How many users know what a fingerprint is, or what it is designed for? Unless we either force the browser to be that strict and never interface with unseen or untrusted fingerprints (impractical), what can you do? ----- Original Message ----- From: "Jeroen C. van Gelderen" To: "Peter Clay" Cc: "Ian Grigg" ; Sent: Monday, March 24, 2003 4:50 PM Subject: Re: Who's afraid of Mallory Wolf? On Monday, Mar 24, 2003, at 11:37 US/Eastern, Peter Clay wrote: > On Sun, 23 Mar 2003, Ian Grigg wrote: > >> Consider this simple fact: There has been no >> MITM attack, in the lifetime of the Internet, >> that has recorded or documented the acquisition >> and fraudulent use of a credit card (CC). >> >> (Over any Internet medium.) > > How do you view attacks based on tricking people into going to a site > which claims to be affiliated with e.g. Ebay or Paypal, getting them to > enter their login information as usual, and using that to steal money? > > It's not a pure MITM attack, but the current system at least makes it > possible for people to verify with the certificate whether or not the > site > is a spoof. Correct. On the other hand, in a lot of cases people cannot be expected to do the verification. This shows in the number of people that can be tricked into being spoofed out of their passwords, even when certificates are deployed. That is not an argument against certificates though, it is (partially) an argument against broken user interfaces. > Just out of interest, do you have an economic cost/benefit analysis for > the widespread deployment of gratuitous encryption? What makes you say it is gratuitous? Or: how can you state my privacy is gratuitous? > It's just not that important. If your browsing privacy is important, > you're prepared to click through the alarming messages. If the value of > privacy is less than the tiny cost of clicking "accept this certificate > forever" for each site, then it's not a convincing argument for > exposing > people who don't understand crypto to the risk of MITM. This is illogical. Even if a server operator would prefer to allow unauthenticated encryption, he cannot do so without annoying 90% of his customers because they too will be getting these alarming messages. In general, if my browsing privacy is important to me and the server operator is willing to accomodate me, he cannot do so. This however still does not constitute an argument against certificates. It can be morphed as an argument against browsers not supporting Anonymous-DH. (Note that I'm favoring treating sites offering ADH the same as sites offering a certificate. Each offers different functionality which should be distinguishable in the GUI.) Cheers, -J -- Jeroen C. van Gelderen - jeroen at vangelderen.org The python has, and I fib no fibs, 318 pairs of ribs. In stating this I place reliance On a s?ance with one who died for science. This figure is sworn to and attested; He counted them while being digested. -- Ogden Nash --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From bear at sonic.net Mon Mar 24 22:32:08 2003 From: bear at sonic.net (bear) Date: Mon, 24 Mar 2003 19:32:08 -0800 (PST) Subject: Keysigning @ CFP2003 In-Reply-To: <3423551E-5E58-11D7-B5A0-000393754B1C@vangelderen.org> Message-ID: On Mon, 24 Mar 2003, Jeroen C. van Gelderen wrote: >It's rather efficient if you want to sign a large number of keys of >people you mostly do not know personally. > Right, but remember that knowing people personally was supposed to be part of the point of vouching for their identity to others. "I know this guy. We spent a couple years working on X together." is different in kind from "I met this guy once in my life, and he had a driver license that said his name was mike." Bear --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From lynn at garlic.com Mon Mar 24 19:50:41 2003 From: lynn at garlic.com (Anne & Lynn Wheeler) Date: Mon, 24 Mar 2003 17:50:41 -0700 Subject: Who's afraid of Mallory Wolf? In-Reply-To: References: <200303232310.22334.iang@systemics.com> Message-ID: <4.2.2.20030324164709.00bb9220@mail.earthlink.net> At 10:02 PM 3/24/2003 +0000, David Wagner wrote: >You could take your argument even further and >ask whether any crypto was needed at all. >After all, most attacks have worked by compromising >the endpoint, not by sniffing network traffic. >I'll let you decide whether to count this as a >success story for SSL, or as indication that the >crypto wasn't needed in the first place. >(I'm a little skeptical of this argument, by the >way, but hey, if we're playing devil's advocate, >why not aim high?) I assert that there may be more sites that transmit credit card numbers w/o crypto, as sites that use SSL (although transaction rates are highly skewed so they even if it were ten times the number of sites, it might represent fewer actual transmissions). I don't have actual numbers, but I am aware of significant number of sites. However, I would contend that harvesting numbers from end-point merchant files has significantly higher return (ROI, expected results for the effort) than any sort of network evesdropping ... and that it is practically impossible to provide the necessary armoring as countermeasure for this vulnerability; end point attacks by either insider and outsider (historically, insider attacks on financial infrastructure have represented vast majority of incidents. While it may be possible to do a single armored site .... it isn't practical to do a million such sites (for one thing, people make too many mistakes) ... as per previous ref to security proportional to risk (and the merchant file risk is proportional to the credit limits of the accounts, not the specific merchant transaction). I would expect that network evesdropping would be employed where vulnerability was something other than kind of fraud do'able by attacking the end-point merchant file. Note however, skimming (various kinds of electronic & non-electronic recording) does go on in the physical world. Part of the issue may be that the target object (account number) has much lower occurance in general internet traffic (physical world skimming involves traffic that is almost solely account numbers). If you just have to skim, there are some number of points that are much more target rich environments (better fraud ROI) than internet traffic. There is some phrase that if the only thing you know how to use is a hammer, then every solution may involve a nail. The fundamental problem with account numbers is that they are effectively a kind of shared-secret .... acquiring/harvesting the numbers enables fraud. There are significant number of business processes that require the availability of the account numbers. This is one of the reasons for the end-point merchant files and also why "SET" (with significantly more complex crypto infrastructure and essentially only, also addressing data in-flight) offered very little additional over what my wife and I were involved with setting up the original SSL for e-commerce. http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 The point of x9.59 wasn't to add even more layers of crypto and information hiding to protect these shared-secrets .... but to change the business model so that the account numbers were no longer shared-secrets. X9.59 uses simple digital signature for authenticated payment transactions and a business rule that account numbers used in x9.59 transactions can't be used in non-authenticated payment transactions. http://www.garlic.com/~lynn/index.html#x959 aka just by evesdropping an x9.59 transactions or harvesting account numbers used in x9.59 transactions doesn't enable a crook to initiate a fraudulent payment transaction. -- Anne & Lynn Wheeler http://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From astiglic at okiok.com Tue Mar 25 00:20:59 2003 From: astiglic at okiok.com (Anton Stiglic) Date: Tue, 25 Mar 2003 00:20:59 -0500 Subject: Brumley & Boneh timing attack on OpenSSL References: <279f7c15c754f6304687a90be549e267@dizum.com> Message-ID: <001d01c2f28e$561a09a0$629f6395@p1038mobile> ----- Original Message ----- From: "Nomen Nescio" To: Sent: Monday, March 24, 2003 1:20 PM Subject: Re: Brumley & Boneh timing attack on OpenSSL > Regarding using blinding to defend against timing attacks, and supposing > that a crypto library is going to have support for blinding: > > - Should it do blinding for RSA signatures as well as RSA decryption? If you are a client, and you manually control the signature generation (like you use PGP to sign email messages), I wouldn't implement blinding. But if you are a server (or a client that automatically responds to requests) that signs message for some reason, and you receive many requests, I would. RSA decryption, yes for servers. > - How about for ElGamal decryption? > > - Non-ephemeral (static) DH key exchange? Again, if you are automatically answer to requests, yes I would. In the Freedom network, servers had non-ephemeral keys and did a DH key exchange with clients (client side used ephemeral keys and was anonymous), we implemented blinding on the server side to counter timing attacks because we had a hunch that they could work over network connections. > - Ephemeral DH key exchange? No, I wouldn't. I would be very surprised if you could do timing attacks on one execution of a modulo exponentiation, unless there is some way to trick a server in using the same secret on different inputs, even though it's suppose to do ephemeral DH. > - How about for DSS signatures? Yes if you automatically answer to requests. Paul Kocher's initial paper on the subject explicitly mentions DH, RSA and DSS. If there is a possibility that you can be used as an oracle, and you have a static key, you should be careful. --Anton --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From iang at systemics.com Tue Mar 25 00:17:22 2003 From: iang at systemics.com (Ian Grigg) Date: Tue, 25 Mar 2003 00:17:22 -0500 Subject: Who's afraid of Mallory Wolf? In-Reply-To: References: Message-ID: <200303250017.22958.iang@systemics.com> On Monday 24 March 2003 19:26, bear wrote: > On Mon, 24 Mar 2003, Peter Clay wrote: > > >On Sun, 23 Mar 2003, Ian Grigg wrote: > > > >> Consider this simple fact: There has been no > >> MITM attack, in the lifetime of the Internet, > >> that has recorded or documented the acquisition > >> and fraudulent use of a credit card (CC). > >> > >> (Over any Internet medium.) > > There have, however, been numerous MITM attacks for stealing > or eavesdropping on email. A semi-famous case I'm thinking > of involves a rabid baptist minister named fred phelps and > a topeka city councilwoman who had the audacity to vote against > him running roughshod over the law. He set up routing tables > to fool DNS into thinking his machine was the shortest distance > from the courthouse where she worked to her home ISP and > eavesdropped on her mail. Sent a message to every fax machine > in town calling her a "Jezebellian whore" after getting the > skinny on the aftermath of an affair that she was discussing > with her husband. I love it! Then, I'm wrong on that point, we do in fact have some aggressive MITMs occuring in some mediums over the net. Steve Bellovin pointed one out, this is another. Which gets us to the next stage of the analysis (what did they cost!). > And as for theft of credit card numbers, the lack of MITM > attacks directly on them is just a sign that other areas of > security around them are so loose no crooks have yet had to > go to that much trouble. Weakest link, remember? No need > to mount a MITM attack if you're able to just bribe the data > entry clerk. I'd say, SSL with the cert protection is the strongest link in the chain. In fact, it's ludicrously strong. It's like a Chubb vault lock on a screen door. If we were getting physical here, the door wouldn't be strong enough to hold up the lock. So, cut to the chase: if we "mandate" that from now on, all commerce servers use ADH, just hypothetically, for the sake of argument, do you think that the connection would then become anything other than the strongest link in the chain? (I think it would remain the strongest link, by far. In fact, even if it was unencrypted, I think it would be one of the stronger links, c.f., David Wagner's devilish advocacy. But, nobody would suggest we throw away the current cert infrastructure, just that we back off a little and accept the intermediate path of ADH / self-signed certs.) > Just because most companies' security is so > poor that it's not worth the crook's time and effort doesn't > mean we should throw anyone who takes security seriously > enough that a MITM vulnerability might be the weakest link > to the wolves. Nobody's saying that we should. I'm saying that the server and browser should offer the choice to deploy and use more convenient levels of security. The message should congratulate the user for moving up to a more secure channel than HTTP, not annoy them with imponderables about how self-signed certs might be insecure under a certain hard-to-measure threat model... as is the case now. -- iang --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From jeroen at vangelderen.org Tue Mar 25 00:22:04 2003 From: jeroen at vangelderen.org (Jeroen van Gelderen) Date: Tue, 25 Mar 2003 00:22:04 -0500 Subject: Keysigning @ CFP2003 In-Reply-To: Message-ID: On Monday, Mar 24, 2003, at 22:32 US/Eastern, bear wrote: > On Mon, 24 Mar 2003, Jeroen C. van Gelderen wrote: > >> It's rather efficient if you want to sign a large number of keys of >> people you mostly do not know personally. > > Right, but remember that knowing people personally was supposed > to be part of the point of vouching for their identity to others. Not that I heard of. I always understood that I should be 'convinced' of the identity and willing to state that to others. Knowing someone personally is very nice and gives you rather a lot of assurance that their identity is being used consistently and that others know the person by the same identity. (It is for precisely that reason that I have signed a few keys for people who use an alias.) Sometimes however you have the choice between a 'weaker' form of certification and no certification at all. I prefer the former because it increases the chances of the WoT being useful. Key signing parties' reliance on passports are a case in point. In general passports are a reasonable indication of identity. > "I know this guy. We spent a couple years working on X together." > is different in kind from "I met this guy once in my life, and he > had a driver license that said his name was mike." Yes. But PGP doesn't mandate either interpretation. That is what you use your trust knobs for: you decide on a per-user basis how trustworthy an identity certification from that user is. The redundancy of a well-connected WoT then helps you a bit in eliminating simple errors. Cheers, Jeroen -- Jeroen C. van Gelderen - jeroen at vangelderen.org The python has, and I fib no fibs, 318 pairs of ribs. In stating this I place reliance On a s?ance with one who died for science. This figure is sworn to and attested; He counted them while being digested. -- Ogden Nash --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From iang at systemics.com Tue Mar 25 00:36:20 2003 From: iang at systemics.com (Ian Grigg) Date: Tue, 25 Mar 2003 00:36:20 -0500 Subject: Keysigning @ CFP2003 In-Reply-To: References: Message-ID: <200303250036.20891.iang@systemics.com> On Tuesday 25 March 2003 00:22, Jeroen van Gelderen wrote: > On Monday, Mar 24, 2003, at 22:32 US/Eastern, bear wrote: > > On Mon, 24 Mar 2003, Jeroen C. van Gelderen wrote: > > > >> It's rather efficient if you want to sign a large number of keys of > >> people you mostly do not know personally. > > > > Right, but remember that knowing people personally was supposed > > to be part of the point of vouching for their identity to others. > > Not that I heard of. I always understood that I should be 'convinced' > of the identity and willing to state that to others. Well, that's a surprise to me! My understanding of the PGPid signature was that the semantics were loose, deliberately undefined. And, within that limitation, it came down to "I met this guy, he called himself Micky Mouse." I've only been to one key signing event, and no identity was flashed around that I recall. So, do we have two completely disjoint communities here? One group that avoids "photo id" and another that requires it? Or is one group or the other so small that nobody really noticed? I'm curious, is all! > Yes. But PGP doesn't mandate either interpretation. That is what you > use your trust knobs for: you decide on a per-user basis how > trustworthy an identity certification from that user is. The redundancy > of a well-connected WoT then helps you a bit in eliminating simple > errors. Um. So, there are people out there that I am convinced are who they say they are. They happen to be nyms, but I know that, and they are consistent nyms. Can I sign their key with the highest level? -- iang --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From jeroen at vangelderen.org Tue Mar 25 01:42:53 2003 From: jeroen at vangelderen.org (Jeroen C. van Gelderen) Date: Tue, 25 Mar 2003 01:42:53 -0500 Subject: Who's afraid of Mallory Wolf? In-Reply-To: <3E7F9B5E.A3E29595@nma.com> Message-ID: <013F443A-5E8D-11D7-B5A0-000393754B1C@vangelderen.org> On Monday, Mar 24, 2003, at 18:57 US/Eastern, Ed Gerck wrote: > I'm sorry to say it but MITM is neither a fable nor > restricted to laboratory demos. It's an attack available > today even to script kiddies. > > For example, there is a possibility that some evil attacker > redirects the traffic from the user's computer to his own > computer by ARP spoofing. With the programs arpspoof, > dnsspoof and webmitm in the dsniff package it is possible > for a script kiddie to read the SSL traffic in cleartext (list > of commands available if there is list interest). For this attack > to work the user and the attacker must be on the same LAN > or ... the attacker could be somewhere else using a hacked > computer on the LAN -- which is not so hard to do ;-) This is good info! >> ... >> Clearly, the browsers should not discriminate >> against cert-less browsing opportunities > > The only sign of the spoofing attack is that the user gets a > warning about the certificate that the attacker is presenting. > It's vital that the user does not proceed if this happens -- > contrary to what you propose. True. Based on his first post however I think that IanG is saying something like: 1. Presently 1% of Internet traffic is protected by SSL against MITM and eavesdropping. 2. 99% of Internet traffic is not protected at all. 3. A significant portion of the 99% could benefit from protection against eavesdropping but has no need for MITM protection. (This is a priori a truth, or the traffic would be secured with SSL today or not exist.) 4. The SSL infrastructure (the combination of browsers, servers and the protocol) does not allow the use of SSL for privacy protection only. AnonDH is not supported by browsers and self-signed certificates as a workaround don't work well either. 5. The reason for (4) is that the MITM attack is overrated. People refuse to provide the privacy protection because it doesn't protect against MITM. Even though MITM is not a realistic attack (2), (3). (That is not to say that (1) can do without MITM protection. I suspect that IanG agrees with this even though his post seemed to indicate the contrary.) 6. What is needed is a system that allows hassle-free, incremental deployment of privacy-protecting crypto without people whining about MITM protection. Now, this is could be achieved by enabling AnonDH in the SSL infrastructure and making sure that the 'lock icon' is *not* displayed when AnonDH is in effect. Also, servers should enable and support AnonDH by default, unless disabled for performance reasons. > BTW, this is NOT the way to make paying for CA certs go > away. A technically correct way to do away with CA certs > and yet avoid MITM has been demonstrated to *exist* > (not by construction) in 1997, in what was called intrinsic > certification -- please see www.mcg.org.br/cie.htm Phew, that is a lot of pages to read (40?). Its also rather though material for me to digest. Do you have something like an example approach written up? I couldn't find anything on the site that did not require study. Cheers, Jeroen -- Jeroen C. van Gelderen - jeroen at vangelderen.org The python has, and I fib no fibs, 318 pairs of ribs. In stating this I place reliance On a s?ance with one who died for science. This figure is sworn to and attested; He counted them while being digested. -- Ogden Nash --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From jeroen at vangelderen.org Tue Mar 25 02:07:49 2003 From: jeroen at vangelderen.org (Jeroen van Gelderen) Date: Tue, 25 Mar 2003 02:07:49 -0500 Subject: Keysigning @ CFP2003 In-Reply-To: <200303250036.20891.iang@systemics.com> Message-ID: <7D30ADE4-5E90-11D7-B5A0-000393754B1C@vangelderen.org> On Tuesday, Mar 25, 2003, at 00:36 US/Eastern, Ian Grigg wrote: > On Tuesday 25 March 2003 00:22, Jeroen van Gelderen wrote: >> On Monday, Mar 24, 2003, at 22:32 US/Eastern, bear wrote: >>> On Mon, 24 Mar 2003, Jeroen C. van Gelderen wrote: >>> >>>> It's rather efficient if you want to sign a large number of keys of >>>> people you mostly do not know personally. >>> >>> Right, but remember that knowing people personally was supposed >>> to be part of the point of vouching for their identity to others. >> >> Not that I heard of. I always understood that I should be 'convinced' >> of the identity and willing to state that to others. > > Well, that's a surprise to me! My understanding > of the PGPid signature was that the semantics > were loose, deliberately undefined. And, within > that limitation, it came down to "I met this guy, > he called himself Micky Mouse." I don't think that is a contradiction. This is just your personal requirements for being 'convinced'. > I've only been to one key signing event, and no > identity was flashed around that I recall. > > So, do we have two completely disjoint communities > here? One group that avoids "photo id" and another > that requires it? Or is one group or the other so > small that nobody really noticed? Nah. I think the photo-id case just makes large key-signing parties easier (or possible). I suspect that for a large group of people (excluding you(?)) the following statement holds: "When I see a new person for 30 seconds she cannot 'convince' me of her identity. If a passport is flashed in my face in those 30 seconds I actually am quite certain of it." So there you have it: the difference between being able to sign in 30 seconds, or not. A practical -if not optimal- way to grow the WoT. This does *not* mean photo-id is a pre-condition for signing someone's key. It does *not* mean you should sign a key if you are shown a photo-id. It just *might* make it possible to sign a key where otherwise no certification would be possible. >> Yes. But PGP doesn't mandate either interpretation. That is what you >> use your trust knobs for: you decide on a per-user basis how >> trustworthy an identity certification from that user is. The >> redundancy >> of a well-connected WoT then helps you a bit in eliminating simple >> errors. > > Um. So, there are people out there that I am convinced > are who they say they are. They happen to be nyms, > but I know that, and they are consistent nyms. Can I > sign their key with the highest level? Why not? It is *your* definition of 'convinced'. Other people will use their trust knobs to translate your judgement to their reliance on said judgement. Cheers, Jeroen -- Jeroen C. van Gelderen - jeroen at vangelderen.org Western Corporations That Supplied Iraq's Weapons Program: http://www.thememoryhole.org/corp/iraq-suppliers.htm --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From egerck at nma.com Tue Mar 25 02:20:48 2003 From: egerck at nma.com (Ed Gerck) Date: Mon, 24 Mar 2003 23:20:48 -0800 Subject: Who's afraid of Mallory Wolf? References: <013F443A-5E8D-11D7-B5A0-000393754B1C@vangelderen.org> Message-ID: <3E800350.5908EAE8@nma.com> "Jeroen C. van Gelderen" wrote: > 1. Presently 1% of Internet traffic is protected by SSL against > MITM and eavesdropping. > > 2. 99% of Internet traffic is not protected at all. I'm sorry, but no. The bug in MSIE, that prevented the correct processing of cert path restraints and which led to easy MITM attacks, has been fixed for some time now. Consulting browser statistics sites will show that the MSIE update in question, fueled by the need for other security updates, is making good progress. > 3. A significant portion of the 99% could benefit from > protection against eavesdropping but has no need for > MITM protection. (This is a priori a truth, or the > traffic would be secured with SSL today or not exist.) I'm sorry but the "a priori truth" above is false . Ignorance about the flaw, that is now fixed, and the need to do a LAN attack (if you want not to mess with the DNS) have helped avert a major public exploit. The hole is now fixed and the logic fails for this reason as well. > 4. The SSL infrastructure (the combination of browsers, > servers and the protocol) does not allow the use of > SSL for privacy protection only. AnonDH is not supported > by browsers and self-signed certificates as a workaround > don't work well either. There is a good reason -- MITM. AnonDH and self-signed certs cannot prevent MITM. > > 5. The reason for (4) is that the MITM attack is overrated. > People refuse to provide the privacy protection because > it doesn't protect against MITM. Even though MITM is not > a realistic attack (2), (3). But it is, please see the spoof/MITM method in my previous post. Which, BTW, is rather old info in some circles (3 years?) and is easy to do by script kiddies with no knowledge about anything we are talking here -- they can simply do it. Anyone can do it. > (That is not to say that (1) can do without MITM > protection. I suspect that IanG agrees with this > even though his post seemed to indicate the contrary.) I think Ian's post, with all due respect to Ian, reflects a misconception about cert validation. The misconception is that cert validation can be provided as an absolute reference -- it cannot. The *mathematical* reasons are explained in the paper I cited. This misconception was discussed some 6 years in the ssl-talk list and other lists, and clarified at the time -- please see the archives. It was good, however, to post this again and, again, to allow this to be clarified. > > 6. What is needed is a system that allows hassle-free, > incremental deployment of privacy-protecting crypto > without people whining about MITM protection. You are asking for the same thing that was asked, and answered, 6 years ago in the ssl-talk and other lists. There is a way to do it and the way is not self-signed certs or SSL AnonDH. > Now, this is could be achieved by enabling AnonDH in the SSL > infrastructure and making sure that the 'lock icon' is *not* displayed > when AnonDH is in effect. Also, servers should enable and support > AnonDH by default, unless disabled for performance reasons. Problem -- SSL AnonDH cannot prevent MITM. The solution is not to deny the problem and ask "who cares about MITM?" > Ed Gerck wrote: > > BTW, this is NOT the way to make paying for CA certs go > > away. A technically correct way to do away with CA certs > > and yet avoid MITM has been demonstrated to *exist* > > (not by construction) in 1997, in what was called intrinsic > > certification -- please see www.mcg.org.br/cie.htm > > Phew, that is a lot of pages to read (40?). Its also rather though > material for me to digest. Do you have something like an example > approach written up? I couldn't find anything on the site that did not > require study. > ;-) If anyone comes across a way to explain it, that does not require study, please let me know and I'll post it. OTOH, some practical code is being developed, and has been sucessfully tested in the past 3 years with up to 300,000 simultaneous users, which may provide the example you ask for. Please write to me privately if you'd like to use it. Cheers, Ed Gerck --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From jeroen at vangelderen.org Tue Mar 25 03:36:14 2003 From: jeroen at vangelderen.org (Jeroen van Gelderen) Date: Tue, 25 Mar 2003 03:36:14 -0500 Subject: Who's afraid of Mallory Wolf? In-Reply-To: <3E800350.5908EAE8@nma.com> Message-ID: On Tuesday, Mar 25, 2003, at 02:20 US/Eastern, Ed Gerck wrote: > > > "Jeroen C. van Gelderen" wrote: > >> 1. Presently 1% of Internet traffic is protected by SSL against >> MITM and eavesdropping. >> >> 2. 99% of Internet traffic is not protected at all. > > I'm sorry, but no. The bug in MSIE, that prevented the correct > processing of cert path restraints and which led to easy MITM > attacks, has been fixed for some time now. Consulting browser > statistics sites will show that the MSIE update in question, > fueled by the need for other security updates, is making > good progress. Heu? I am talking about HTTPS (1) vs HTTP (2). I don't see how the MSIE bug has any effect on this. -- Jeroen C. van Gelderen - jeroen at vangelderen.org "Be precise in the use of words and expect precision from others" -- Pierre Abelard --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From bill.stewart at pobox.com Tue Mar 25 06:06:39 2003 From: bill.stewart at pobox.com (Bill Stewart) Date: Tue, 25 Mar 2003 03:06:39 -0800 Subject: Who's afraid of Mallory Wolf? In-Reply-To: <200303232310.22334.iang@systemics.com> Message-ID: <5.1.1.6.2.20030325024822.02d86078@idiom.com> At 11:10 PM 03/23/2003 -0500, Ian Grigg wrote: >Consider this simple fact: There has been no >MITM attack, in the lifetime of the Internet, >that has recorded or documented the acquisition >and fraudulent use of a credit card (CC). >(Over any Internet medium.) One of the major reasons for this, of course, is the requirement for certificates, which give at least some vague level of authentication that you're talking to the site you wanted, as well as some much vaguer level of authentication that the web site might correspond to some actual business that at least had enough capital to buy a cert. Sure, there are a variety of subtle and entertaining ways to pull of MITM attacks, but one crude and obvious one is to forge either an entire site or at least the parts of it that ask for your credit card number, and use something like DNS hacking or minor name misspellings to get people to visit your site instead of the real one. If you need to forward some of the requests on to the real site, that's a bit more work, and makes you easier to trace, so if you can be a MITM without bothering with the back half, great. And of course the cruder and more obvious attack was to create a site for a company that wasn't actually on the web yet, so nobody's watching the site, and then fly-by-night out of there. Is it perfect? No, but it does tend to raise the bar on attacks to the point that keeps out lots of the anklebiters and makes it more effective to attack a badly-administered server instead of forging a better-administered server. Oh, and it also let merchants who desperately wanted the public to trust them enough to give them credit card numbers tell their potential customers "See, we've got *cryptography*!" instead of "See, we've got servers sitting exposed to the net", which is a social engineering problem, and also let them say "See, the certificates let you know you're talking to the REAL Example Inc. instead a some faker putting up example.com." Because the real economics is whether you can get customers to show up. (Well, ok, and whether you can make money if they do show up :-) --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From alex at syjon.fantastyka.net Tue Mar 25 07:52:07 2003 From: alex at syjon.fantastyka.net (Janusz A. Urbanowicz) Date: Tue, 25 Mar 2003 13:52:07 +0100 (CET) Subject: Keysigning @ CFP2003 In-Reply-To: <200303241100.01141.iang@systemics.com> Message-ID: [ Charset UTF-8 unsupported, converting... ] > On Saturday 22 March 2003 17:12, Douglas F. Calvert wrote: > > > I will be organizing a keysigning session for CFP2003. Please submit > > your keys to cfp-keys at anize.org and I will print out sheets with key > > information in order to speed up the process. Bring a photo ID and a > > copy of your key information so that you can verify what is on the > > printout. A list of submitted keys and a keyring will be available on: > > I must be out of touch - since when did > PGP key signing require a photo id? It is an usual requirement for a keysigning party to bring a photo ID to validate if theirs key ids are the same as their names (and to get class 3 key signatures) http://www.cryptnet.net/fdp/crypto/gpg-party.html#ss1.1 Alex --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From harted at csn.ul.ie Tue Mar 25 08:32:48 2003 From: harted at csn.ul.ie (Dave Harte) Date: Tue, 25 Mar 2003 13:32:48 +0000 (GMT) Subject: CTKS? Message-ID: Change the Key Stupid ? Just a nice simple question. I have previously implemented a process to generate new dsa/rsa keys for ssh and transfer them over the existing encrypted session with time interval t, the following connection will use the new keys & so forth.. The reason behind this was, if anyone robbed the private key and knew the passphrase ( in fact I had no passphrase above, and allowed any of the last 3 keys pairs to be used ), it would only be valid for a short time interval... The benefit is simple for ssh, blank passphrase private keys are useful for time interval t and no longer, gaining access to these via backups, temporary root, temporary contract etc, are of little use if time internal is sufficiently short. I have not seen this technique documented/ mentioned for ssh or any other protocols ? links & references ? or is this a case of CTKSS! ( Change the key Stupid, Stupid ) ? ..surely where there is risk of keys being copied and allowing either access, future decryption or MITM attacks with private key, it makes sense to automate the key exchange when possible ? and also to continue to have the 1-3 month manual key exchange over alternate channel. Thoughts / criticisms welcome --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From crawdad at fnal.gov Tue Mar 25 10:55:46 2003 From: crawdad at fnal.gov (Matt Crawford) Date: Tue, 25 Mar 2003 09:55:46 -0600 Subject: Keysigning @ CFP2003 In-Reply-To: Your message of Mon, 24 Mar 2003 19:24:55 EST. <3423551E-5E58-11D7-B5A0-000393754B1C@vangelderen.org> Message-ID: <200303251555.h2PFtk2Y007710@gungnir.fnal.gov> > > I must be out of touch - since when did > > PGP key signing require a photo id? > > It's rather efficient if you want to sign a large number of keys of > people you mostly do not know personally. Assuming, of course, that the ID is of a sort for which you have an "is-a-forgery" oracle. Has anyone ever weighted a PGP key's certification value as a function of how many keys it's know to have certified? --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From lynn at garlic.com Tue Mar 25 12:15:00 2003 From: lynn at garlic.com (Anne & Lynn Wheeler) Date: Tue, 25 Mar 2003 10:15:00 -0700 Subject: Who's afraid of Mallory Wolf? In-Reply-To: <200303250017.22958.iang@systemics.com> References: Message-ID: <4.2.2.20030325100549.00b5cac0@mail.earthlink.net> At 12:17 AM 3/25/2003 -0500, Ian Grigg wrote: >I'd say, SSL with the cert protection is the >strongest link in the chain. In fact, it's >ludicrously strong. It's like a Chubb vault >lock on a screen door. If we were getting >physical here, the door wouldn't be strong >enough to hold up the lock. except the certification authorities ... when doing the certification of who owns a domain name .... still asks the domain name infrastructure as to who really owns the domain name .... when they get a request for a SSL domain name certificate. SSL domain name certificate request after a domain name hijack still is possible (aka a chubb vault lock with a possible backdoor). the other scenario that has been raised before is that the browsers treat all certification authorities the same .... aka if the signature on the certificate can be verified with any of the public keys in a browser's public key table ... it is trusted. in effect, possibly 20-40 different manufactures of chubb vault locks .... with a wide range of business process controls ... and all having the same possible backdoor. Furthermore, the consumer doesn't get to choose which chubb lock is being chosen. -- Anne & Lynn Wheeler http://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From bear at sonic.net Tue Mar 25 12:07:40 2003 From: bear at sonic.net (bear) Date: Tue, 25 Mar 2003 09:07:40 -0800 (PST) Subject: Who's afraid of Mallory Wolf? In-Reply-To: <200303250017.22958.iang@systemics.com> Message-ID: On Tue, 25 Mar 2003, Ian Grigg wrote: >On Monday 24 March 2003 19:26, bear wrote: >> him running roughshod over the law. He set up routing tables >> to fool DNS into thinking his machine was the shortest distance >> from the courthouse where she worked to her home ISP and >> eavesdropped on her mail. Sent a message to every fax machine >> in town calling her a "Jezebellian whore" after getting the >> skinny on the aftermath of an affair that she was discussing >> with her husband. > >I love it! Then, I'm wrong on that point, we >do in fact have some aggressive MITMs >occuring in some mediums over the net. >Steve Bellovin pointed one out, this is >another. > >Which gets us to the next stage of the >analysis (what did they cost!). Wait. Time out. Setting aside the increased monetary cost of her reelection campaign in a fairly conservative state capitol, and setting aside the increased difficulty of raising money for that campaign, the main costs here are intangible. On a professional level, she had reduced power in office because of the scandal this clown created publishing her personal email, but the intangible costs go both directions from there. Toward the personal end of the spectrum, discussing the aftermath of an affair with one's husband is sensitive and personal, and making that whole thing public can't have done either of them, or their marriage for that matter, any good. In the public sphere, this is a case in which information gained from an attack on email was being employed directly for undeserved influence on government officials. Being timed to interfere with her reelection makes it a direct means of removing political opponents from office, and it has probably had a "chilling effect" on other council members in that benighted city who might otherwise have voted in ways Phred didn't like. What he did was nothing less than a direct assault on the democratic process of government. I don't think mere monetary costs are even germane to something like this. The costs, publicly and personally, are of a different kind than money expresses. And we're going to continue to have this problem for as long as we continue to use unencrypted SMTP for mail transport. Bear --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From bear at sonic.net Tue Mar 25 12:25:57 2003 From: bear at sonic.net (bear) Date: Tue, 25 Mar 2003 09:25:57 -0800 (PST) Subject: Keysigning @ CFP2003 In-Reply-To: <200303251555.h2PFtk2Y007710@gungnir.fnal.gov> Message-ID: On Tue, 25 Mar 2003, Matt Crawford wrote: >Has anyone ever weighted a PGP key's certification value as a >function of how many keys it's know to have certified? An interesting idea: At one extreme you could view the whole universe as having a finite amount of trust and every certification is a transfer of some trust from one person to another. But then companies like verisign, after the first thousand or so certs, would have nothing left to sell. At the other, you could view verisign as providing a fairly reliable indication, not necessarily of who X is, but certainly of the fact that somebody was willing to spend thousands of dollars to claim to be X and the financial records are on file if you absolutely need to figure out who that was, so they "create" trust in a way that most keysigners don't. Neither model is perfect, but the latter one seems to have more appeal to people in protecting financial transactions and the former to people who are more concerned about personal privacy. Bear --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ben at algroup.co.uk Tue Mar 25 12:28:44 2003 From: ben at algroup.co.uk (Ben Laurie) Date: Tue, 25 Mar 2003 17:28:44 +0000 Subject: Who's afraid of Mallory Wolf? In-Reply-To: <3E800350.5908EAE8@nma.com> References: <013F443A-5E8D-11D7-B5A0-000393754B1C@vangelderen.org> <3E800350.5908EAE8@nma.com> Message-ID: <3E8091CC.40808@algroup.co.uk> Ed Gerck wrote: >>>BTW, this is NOT the way to make paying for CA certs go >>>away. A technically correct way to do away with CA certs >>>and yet avoid MITM has been demonstrated to *exist* >>>(not by construction) in 1997, in what was called intrinsic >>>certification -- please see www.mcg.org.br/cie.htm >> >>Phew, that is a lot of pages to read (40?). Its also rather though >>material for me to digest. Do you have something like an example >>approach written up? I couldn't find anything on the site that did not >>require study. >> > > ;-) If anyone comes across a way to explain it, that does not require study, > please let me know and I'll post it. AFAICS, what it suggests, in a very roundabout way, is that you may be able to verify the binding between a key and some kind of DN by being given a list of signatures attesting to that binding. This is pretty much PGP's Web of Trust, of course. I could be wrong, I only read it quickly. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From bear at sonic.net Tue Mar 25 12:28:58 2003 From: bear at sonic.net (bear) Date: Tue, 25 Mar 2003 09:28:58 -0800 (PST) Subject: Who's afraid of Mallory Wolf? In-Reply-To: <4.2.2.20030325100549.00b5cac0@mail.earthlink.net> Message-ID: On Tue, 25 Mar 2003, Anne & Lynn Wheeler wrote: >the other scenario that has been raised before is that the browsers treat >all certification authorities the same .... aka if the signature on the >certificate can be verified with any of the public keys in a browser's >public key table ... it is trusted. in effect, possibly 20-40 different >manufactures of chubb vault locks .... with a wide range of business >process controls ... and all having the same possible backdoor. >Furthermore, the consumer doesn't get to choose which chubb lock is being >chosen. Of course the consumer gets to make that choice. I can go into my browser's keyring and delete root certs that have been sold, ever. And I routinely do. A fair number of sites don't work for me anymore, but I'm okay with that. Bear --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From iang at systemics.com Tue Mar 25 12:42:38 2003 From: iang at systemics.com (Ian Grigg) Date: Tue, 25 Mar 2003 12:42:38 -0500 Subject: Who's afraid of Mallory Wolf? In-Reply-To: References: Message-ID: <200303251242.38253.iang@systemics.com> On Tuesday 25 March 2003 12:07, bear wrote: > On Tue, 25 Mar 2003, Ian Grigg wrote: > >Which gets us to the next stage of the > >analysis (what did they cost!). > > > Wait. Time out. .... > I don't think mere monetary costs are even germane to > something like this. The costs, publicly and personally, > are of a different kind than money expresses. I'm sorry to disagree, but I'm sticking to my cost-benefit analysis: monetary costs are totally germane. You see, we need some way in which to measure the harm. It's either subjective as you describe above, which can't support an infrastructure decision, or its objective, which means, money. But, luckily, there is a way to turn the above subjective morass of harm into an objective hard number: civil suit. Presumably, (you mentioned America, right?) this injured party filed a civil suit against the person and sought damages. Now, even if the case did not get filed, I imagine that you would be able to find a few legal types to provide an upper and lower bound on the sort of damages that case would go for. And there's your number! From my ignorant position, I'd scratch in a figure of about a million dollars there, and wait for someone to refine it. > And we're going > to continue to have this problem for as long as we continue to > use unencrypted SMTP for mail transport. I would agree. Which is why we are having this discussion - how can we get this poor victim's traffic onto some form of crypto so she doesn't get her life ripped apart by some dirtbag? As far as SSL goes (switching from the context of her mail to the system we are discussing here), here's the answer: Make ADH / self-signed certs a respectable half-way house to CA-signed certs. Encourage all servers to accept them, by default. Encourage all browsers to switch up to ADH / self-signed secured traffic. Don't discourage it, encourage it. The problem is, it is just too darned hard & expensive for sites to get into SSL. That's what we are looking at, here, lowering the cost of entry into SSL. -- iang --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From marcnarc at rsasecurity.com Tue Mar 25 12:53:46 2003 From: marcnarc at rsasecurity.com (Marc Branchaud) Date: Tue, 25 Mar 2003 09:53:46 -0800 Subject: Brumley & Boneh timing attack on OpenSSL In-Reply-To: <001d01c2f28e$561a09a0$629f6395@p1038mobile> References: <279f7c15c754f6304687a90be549e267@dizum.com> <001d01c2f28e$561a09a0$629f6395@p1038mobile> Message-ID: <3E8097AA.7090401@rsasecurity.com> Anton Stiglic wrote: >> >> - Should it do blinding for RSA signatures as well as RSA >> decryption? > > If you are a client, and you manually control the signature > generation (like you use PGP to sign email messages), I wouldn't > implement blinding. But if you are a server (or a client that > automatically responds to requests) that signs message for some > reason, and you receive many requests, I would. The way I understand the attack, you have to throw a million specially-chosen guesses at the server, which it will blindly attempt to decrypt and use. Basically, you're getting the server to decrypt chosen ciphertext for you. I don't see how the attack can apply to signatures, where the server itself is formatting the data to be signed. Unless the server is just directly signing (RSA-encrypting) arbitrary client-supplied data, but that's a no-no anyway. This is slightly more than theoretical, as OCSP servers do nothing but emit signed responses. An OCSP client can only indirectly influence some of the data that a server signs, and so it seems very difficult to pull off the attack. M. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From jeroen at vangelderen.org Tue Mar 25 13:29:43 2003 From: jeroen at vangelderen.org (Jeroen C. van Gelderen) Date: Tue, 25 Mar 2003 13:29:43 -0500 Subject: Who's afraid of Mallory Wolf? In-Reply-To: Message-ID: On Tuesday, Mar 25, 2003, at 12:28 US/Eastern, bear wrote: > > > On Tue, 25 Mar 2003, Anne & Lynn Wheeler wrote: > >> the other scenario that has been raised before is that the browsers >> treat >> all certification authorities the same .... aka if the signature on >> the >> certificate can be verified with any of the public keys in a browser's >> public key table ... it is trusted. in effect, possibly 20-40 >> different >> manufactures of chubb vault locks .... with a wide range of business >> process controls ... and all having the same possible backdoor. >> Furthermore, the consumer doesn't get to choose which chubb lock is >> being >> chosen. > > Of course the consumer gets to make that choice. I can go into my > browser's > keyring and delete root certs that have been sold, ever. And I > routinely > do. A fair number of sites don't work for me anymore, but I'm okay > with > that. Go tell that to Joe Average. Or your mom. Or my sister. Or the average MSN user. You know, the insignificant group of people that make up the majority of the Internet population these days. "If the lock icon is displayed it is safe." Of course the consumer doesn't get to choose. Just like the consumer never, ever gets to use all of the features on his VCR[*]. This is an software agent deficiency. A UI issue: presently the UI doesn't facilitate the consumer in making that choice. Cheers, -J [*] I'm *not* talking about TiVo here, just about old-fashioned VCRs. -- Jeroen C. van Gelderen - jeroen at vangelderen.org "Be precise in the use of words and expect precision from others" -- Pierre Abelard --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From daw at mozart.cs.berkeley.edu Tue Mar 25 13:17:45 2003 From: daw at mozart.cs.berkeley.edu (David Wagner) Date: 25 Mar 2003 18:17:45 GMT Subject: Who's afraid of Mallory Wolf? References: <200303251242.38253.iang@systemics.com> Message-ID: Ian Grigg writes: >> I don't think mere monetary costs are even germane to >> something like this. The costs, publicly and personally, >> are of a different kind than money expresses. > >I'm sorry to disagree, but I'm sticking to my >cost-benefit analysis: monetary costs are totally >germane. You see, we need some way in which >to measure the harm. It's either subjective as >you describe above, which can't support an >infrastructure decision, or its objective, which >means, money. I'm skeptical. Just because the cost is subjective doesn't mean we should ignore the cost. >But, luckily, there is a way to turn the above >subjective morass of harm into an objective >hard number: civil suit. That's using a questionable measuring stick. The damages paid out in a civil suit may be very different (either higher, or lower) than the true cost of the misconduct. Remember, the courts are not intended to be a remedy for all harms, nor could they ever be. The courts shouldn't be a replacement for our independent judgement. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From egerck at nma.com Tue Mar 25 13:52:03 2003 From: egerck at nma.com (Ed Gerck) Date: Tue, 25 Mar 2003 10:52:03 -0800 Subject: Who's afraid of Mallory Wolf? References: <013F443A-5E8D-11D7-B5A0-000393754B1C@vangelderen.org> <3E800350.5908EAE8@nma.com> <3E8091CC.40808@algroup.co.uk> Message-ID: <3E80A553.85E5E3FE@nma.com> Ben Laurie wrote: > Ed Gerck wrote: > > ;-) If anyone comes across a way to explain it, that does not require study, > > please let me know and I'll post it. > > AFAICS, what it suggests, in a very roundabout way, is that you may be > able to verify the binding between a key and some kind of DN by being > given a list of signatures attesting to that binding. This is pretty > much PGP's Web of Trust, of course. I could be wrong, I only read it > quickly. This would still depend on what the paper calls "extrinsic references", that are outside the dialogue and create opportunity for faults (intentional or otherwise). The resulting problems for PGP are summarized in www.mcg.org.br/cert.htm#1.2. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From egerck at nma.com Tue Mar 25 13:55:08 2003 From: egerck at nma.com (Ed Gerck) Date: Tue, 25 Mar 2003 10:55:08 -0800 Subject: Who's afraid of Mallory Wolf? References: Message-ID: <3E80A60C.8D0489FA@nma.com> Jeroen van Gelderen wrote: > Heu? I am talking about HTTPS (1) vs HTTP (2). I don't see how the MSIE > bug has any effect on this. Maybe we're talking about different MSIE bugs, which is not hard to do ;-) I was referring to the MSIE bug that affects the SSL handshake in HTTPS, from the context in discussion. BTW, HTTP has no provision to prevent MITM in any case -- in fact, establishing a MITM is part of the HTTP tool box and used in reverse proxies for example. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From jeroen at vangelderen.org Tue Mar 25 14:19:03 2003 From: jeroen at vangelderen.org (Jeroen van Gelderen) Date: Tue, 25 Mar 2003 14:19:03 -0500 Subject: Who's afraid of Mallory Wolf? In-Reply-To: <3E80A60C.8D0489FA@nma.com> Message-ID: On Tuesday, Mar 25, 2003, at 13:55 US/Eastern, Ed Gerck wrote: > Jeroen van Gelderen wrote: > >> Heu? I am talking about HTTPS (1) vs HTTP (2). I don't see how the >> MSIE >> bug has any effect on this. > > Maybe we're talking about different MSIE bugs, which is not hard to do > ;-) I am NOT talking about MSIE bugs at all. I didn't mention them and I don't know where you pull the reference from. I am talking about HTTPS traffic (1%) vs. HTTP traffic (99%) on the Internet: 1. Presently 1% of Internet traffic is protected *by SSL* against MITM and eavesdropping. 2. 99% of Internet traffic is not protected at all (because it travels over plain HTTP). > I was referring to the MSIE bug that affects the SSL handshake in > HTTPS, > from the context in discussion. BTW, HTTP has no provision to prevent > MITM in any case -- in fact, establishing a MITM is part of the HTTP > tool box and used in reverse proxies for example. Well, that is *exactly* the point I made: 3. A significant portion of the 99% could benefit from protection against eavesdropping but has no need for MITM protection. (This is a priori a truth, or the traffic would be secured with SSL today or not exist.) Hence the a priori truth. 4. The SSL infrastructure (the combination of browsers, servers and the protocol) does not allow the use of SSL for privacy protection only. AnonDH is not supported by browsers and self-signed certificates as a workaround don't work well either. That is, we cannot add just privacy protection to HTTP by enabling SSL. That sucks because HTTP with just privacy protection is preferable over plain HTTP. But the present SSL infrastructure insists that I pay to defend against MITM even if I have no need for that. That is the problem I (and I suspect IanG) is talking about. 5. The reason for (4) is that the MITM attack is overrated. People refuse to provide the privacy protection because it doesn't protect against MITM. Even though MITM is not a realistic attack for (2), (3). (That is not to say that (1) can do without MITM protection. I suspect that IanG agrees with this even though his post seemed to indicate the contrary.) 6. What is needed is a system that allows hassle-free, incremental deployment of privacy-protecting crypto without people whining about MITM protection. Now, this is could be achieved by enabling AnonDH in the SSL infrastructure and making sure that the 'lock icon' is *not* displayed when AnonDH is in effect. Also, servers should enable and support AnonDH by default, unless disabled for performance reasons. Cheers, Jeroen -- Jeroen C. van Gelderen - jeroen at vangelderen.org "They accused us of suppressing freedom of expression. This was a lie and we could not let them publish it." -- Nelba Blandon, Nicaraguan Interior Ministry Director of Censorship --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From egerck at nma.com Tue Mar 25 14:38:31 2003 From: egerck at nma.com (Ed Gerck) Date: Tue, 25 Mar 2003 11:38:31 -0800 Subject: Who's afraid of Mallory Wolf? References: Message-ID: <3E80B037.42C1DB24@nma.com> Jeroen van Gelderen wrote: > 3. A significant portion of the 99% could benefit from > protection against eavesdropping but has no need for > MITM protection. (This is a priori a truth, or the > traffic would be secured with SSL today or not exist.) Let me summ up my earlier comments: Protection against eavesdropping without MITM protection is not protection against eavesdropping. In addition, when you talk about HTTPS traffic (1%) vs. HTTP traffic (99%) on the Internet you are not talking about user's choices -- where the user is the party at risk in terms of their credit card number. You're talking about web-admins failing to protect third-party information they request. Current D&O liability laws, making the officers of a corporation personally responsible for such irresponsible behavior, will probably help correct this much more efficiently than just a few of us decrying it. My personal view is that ALL traffic SHOULD be encrypted, MITM protected, and authenticated, with the possibility of anonymous authentication if so desired. Of course, this is not practical today -- yet. But we're working to get there. BTW, a source once told me that about 5% of all email traffic is encrypted. So, your 1% figure is also just a part of the picture. Cheers --/Ed Gerck --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From bear at sonic.net Tue Mar 25 15:09:24 2003 From: bear at sonic.net (bear) Date: Tue, 25 Mar 2003 12:09:24 -0800 (PST) Subject: Who's afraid of Mallory Wolf? In-Reply-To: <200303251242.38253.iang@systemics.com> Message-ID: On Tue, 25 Mar 2003, Ian Grigg wrote: >On Tuesday 25 March 2003 12:07, bear wrote: >But, luckily, there is a way to turn the above >subjective morass of harm into an objective >hard number: civil suit. Presumably, (you >mentioned America, right?) this injured party >filed a civil suit against the person and sought >damages. You honestly haven't heard of Fred Phelps? He has thirteen children and nine of them are lawyers. Estimated costs to sue the guy are in the hundreds of thousands of dollars. Estimated costs for him to defend are near zero. Plus the instant you file that civil suit you'll have his zombies loudly picketing your home (that's right, your private residence) 24/7 until you stop. >> And we're going >> to continue to have this problem for as long as we continue to >> use unencrypted SMTP for mail transport. > >I would agree. Which is why we are having >this discussion - how can we get this poor >victim's traffic onto some form of crypto so >she doesn't get her life ripped apart by some >dirtbag? ISP's don't want to support encrypted links because it raises their CPU costs. And mail clients generally aren't intelligently designed to handle encrypted email which the mail servers could just "pass through without decrypting and encrypting". I think a new protocol is needed. The fact that SMTP is unencrypted by default makes it impossible for an encrypted email form to be built on top of it. Bear --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From bill.stewart at pobox.com Tue Mar 25 15:22:40 2003 From: bill.stewart at pobox.com (Bill Stewart) Date: Tue, 25 Mar 2003 12:22:40 -0800 Subject: Who's afraid of Mallory Wolf? In-Reply-To: <200303241903.50570.iang@systemics.com> References: <1048533083.27535.40342.camel@banks> <200303232310.22334.iang@systemics.com> <1048533083.27535.40342.camel@banks> Message-ID: <5.1.1.6.2.20030325115133.02de7e78@idiom.com> I get the impression that we're talking at cross-purposes here, with at least two different discussions. Let's look at several cases: 1 - Sites that have SSL and Expensive Certs that need them and need MITM protection 1a - These sites, but with other security holes making it easy to break in. 1b - These sites, broken by SSL bugs or browser bugs 2 - Sites that have SSL and Expensive Certs that don't need them, as long as they've got some crypto like self-signed certs, which don't give MITM protection 3 - Sites that don't have SSL today because it's too annoying, for which crypto would be useful, and ADH or self-signed certs would be good enough, because MITM isn't a big threat for them. 4 - Sites that don't need crypto. Some people are arguing "Many Sites with SSL Certs are Type 2, Not Type 1" (No they're not! Yes, they are!) Some people are arguing "There are lots of Type 3, so we should support them better than we do today instead of requiring them to do Type 1" (I suspect that's what Ian was really trying to say, but most of the replies have been to the other question, e.g. "There are lots of Type 3! No, there aren't many Type 2! Yes there *are* lots of Type 3! No there ARENT'T many Type 2!" ........ "Yes, there are lots of 1a, but that doesn't imply 2!" "Type 1+2 is 1% and 3+4 is 99%! No, 1b was fixed" One of the big reasons for DNSSEC was MITM protection, at least before virtual hosting took over, because it gave you a way to trust that the IP address you used was the correct IP address for the domain name you wanted, so you were probably talking to the right machine. Of course that doesn't get you ARP-spoofing protection, or eavesdropping protection unless you also use it as a crypto key or at least a signature key for DH parts, and doesn't protect you against other users on your machine (but a shared machine doesn't have much protection anyway, at least from root, so that was already part of your threat model, and that's another 1-vs-1a variant, like the heavy-duty lock on your apartment building front door when your own apartment door has a wimpy lock.) --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From egerck at nma.com Tue Mar 25 15:48:08 2003 From: egerck at nma.com (Ed Gerck) Date: Tue, 25 Mar 2003 12:48:08 -0800 Subject: Who's afraid of Mallory Wolf? References: <56474454-5F00-11D7-B5A0-000393754B1C@vangelderen.org> Message-ID: <3E80C088.59F652A9@nma.com> Jeroen van Gelderen wrote: > On Tuesday, Mar 25, 2003, at 14:38 US/Eastern, Ed Gerck wrote: > > Let me summ up my earlier comments: Protection against > > eavesdropping without MITM protection is not protection > > against eavesdropping. > > You are saying that active attacks have the same cost as passive > attacks. That is ostensibly not correct. Cost is not the point even though cost is low and within the reach of script kiddies. > What we would like to do however is offer a little privacy protection > trough enabling AnonDH by flipping a switch. I do have CPU cycles to > burn. And so do the client browsers. I am not pretending to offer the > same level of security as SSL certs (see note [*]). I agree with this. This is helpful. However, supporting this by asking "Who's afraid of Mallory Wolf?" is IMO not helpful -- because we should all be afradi fo MITM attacks. It's not good for security to deny an attack that is rather easy to do today. > I'm proposing a slight, near-zero-cost improvement[*] in the status > quo. You are complaining that it doesn't achieve perfection. I do not > understand that. Your proposal is, possibly, a good option to have. However, it does not: provide a credible protection against eavesdropping. It is better than ROT13, for sure. Essentially, you're asking for encryption without an authenticated end-point. This is acceptable. But I suggest that advancing your idea should not be prefaced by denying or trying to hide the real problem of MITM attacks. Cheers, Ed Gerck --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From jeroen at vangelderen.org Tue Mar 25 15:28:28 2003 From: jeroen at vangelderen.org (Jeroen van Gelderen) Date: Tue, 25 Mar 2003 15:28:28 -0500 Subject: Who's afraid of Mallory Wolf? In-Reply-To: <3E80B037.42C1DB24@nma.com> Message-ID: <56474454-5F00-11D7-B5A0-000393754B1C@vangelderen.org> On Tuesday, Mar 25, 2003, at 14:38 US/Eastern, Ed Gerck wrote: > Jeroen van Gelderen wrote: > >> 3. A significant portion of the 99% could benefit from >> protection against eavesdropping but has no need for >> MITM protection. (This is a priori a truth, or the >> traffic would be secured with SSL today or not exist.) > > Let me summ up my earlier comments: Protection against > eavesdropping without MITM protection is not protection > against eavesdropping. You are saying that active attacks have the same cost as passive attacks. That is ostensibly not correct. > In addition, when you talk about HTTPS traffic (1%) vs. > HTTP traffic (99%) on the Internet you are not talking > about user's choices -- where the user is the party at risk > in terms of their credit card number. You're talking about > web-admins failing to protect third-party information they > request. Not at all. That assertion is nowhere to be found in my original post either. I am talking about a website like -say- Cryptix (or Dilbert, or The Onion, or whichever). Websites where we do not have any requirement of offering the user any privacy whatsoever. Where we do not collect CC numbers. Where we do in fact not collect much of anything. And where we definitely don't have money for an SSL certificate. Where in fact any effort spent on this stuff is an incredible waste of resources. What we would like to do however is offer a little privacy protection trough enabling AnonDH by flipping a switch. I do have CPU cycles to burn. And so do the client browsers. I am not pretending to offer the same level of security as SSL certs (see note [*]). Enabling AnonDH will eliminate passive attacks at near zero cost and thus *raise* *the* *cost* of eavesdropping. For one it will render mere recording of HTTP traffic useless, which, in my book is a plus. We obviously don't care to *eliminate* eavesdropping because we are happily putting up with that today. You seem to be asserting that increasing the cost of eavesdropping by a small amount is worthless. I'm sorry but I don't see how that makes sense. It is the difference between simply mirroring Google's OC48 to and NSA-owned port on the switch and redirecting the OC48 trough a real-time, low-latency NSA-owned MITM device. Without being detected. I'm proposing a slight, near-zero-cost improvement[*] in the status quo. You are complaining that it doesn't achieve perfection. I do not understand that. Cheers, Jeroen [*] "Now, this is could be achieved by enabling AnonDH in the SSL infrastructure and making sure that the 'lock icon' is *not* *displayed* when AnonDH is in effect. Also, servers should enable and support AnonDH by default, unless disabled for performance reasons." -- Jeroen C. van Gelderen - jeroen at vangelderen.org "They accused us of suppressing freedom of expression. This was a lie and we could not let them publish it." -- Nelba Blandon, Nicaraguan Interior Ministry Director of Censorship --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From iang at systemics.com Tue Mar 25 16:15:22 2003 From: iang at systemics.com (Ian Grigg) Date: Tue, 25 Mar 2003 16:15:22 -0500 Subject: Who's afraid of Mallory Wolf? In-Reply-To: References: <200303251242.38253.iang@systemics.com> Message-ID: <200303251615.22420.iang@systemics.com> On Tuesday 25 March 2003 13:17, David Wagner wrote: > I'm skeptical. Just because the cost is > subjective doesn't mean we should ignore the cost. I agree with that ... I was converting the subjective harm into an objective cost. I certainly wasn't intending to ignore it :-) > >But, luckily, there is a way to turn the above > >subjective morass of harm into an objective > >hard number: civil suit. > > That's using a questionable measuring stick. That being part and parcel of the problem. It's a subjective harm, there is no solid way to move subjective to objective, by definition. We can only make estimates. What is beneficial here is that - at least - we have one way to do this. And, it is a way that has lots of disinterested observers, lots of experience, and lots of interested parties. Much as I dislike courts, it is a "fair and auditable" way of dollarising a harm. Bear says: > You honestly haven't heard of Fred Phelps? Nope. But, all we want is an estimated cost of the attack. Ask some lawyers for a quote. Ignore the guy's family, we are only after an estimate of the cost. David says: > The damages paid out in a civil suit may be very > different (either higher, or lower) than the true > cost of the misconduct. Remember, the courts are > not intended to be a remedy for all harms, nor could > they ever be. The courts shouldn't be a replacement > for our independent judgement. This of course is true especially with the low level of MITM activity that we've found to date. If such a case were to happen once a year, I'd not be really confident of the accuracy of the numbers, especially if we were estimating based on lawyer's opinions rather than awarded damages. (But that wouldn't so much matter if the numbers came out as also too low to consider, as I suspect they will.) If however, we had such MITMs once per month, then costs could be averaged over the size of the activity. Something like this: There are 500 million email users in the world today (guess!). Cost of failures that could be rectified with proper crypto (amounts to 12 cases per year) is 12 million dollars. Some judgements less than a million, some more. [ if you like, you could add in a fudge factor for unreported harms and other "judgement" calls. ] Now, the cost of prevention: assume we pass a law to make every ISP sell every user a copy of OpenPGP to protect their privacy. Bulk discount gives us $1 each copy, annually updated to cover for the inevitable new release. So, cost to protect: 500 million x $1. Saved costs in cases: $12million. That law won't get passed :-) -- iang --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ben at algroup.co.uk Tue Mar 25 16:35:53 2003 From: ben at algroup.co.uk (Ben Laurie) Date: Tue, 25 Mar 2003 21:35:53 +0000 Subject: Who's afraid of Mallory Wolf? In-Reply-To: <3E80A553.85E5E3FE@nma.com> References: <013F443A-5E8D-11D7-B5A0-000393754B1C@vangelderen.org> <3E800350.5908EAE8@nma.com> <3E8091CC.40808@algroup.co.uk> <3E80A553.85E5E3FE@nma.com> Message-ID: <3E80CBB9.20100@algroup.co.uk> Ed Gerck wrote: > > Ben Laurie wrote: > > >>Ed Gerck wrote: >> >>>;-) If anyone comes across a way to explain it, that does not require study, >>>please let me know and I'll post it. >> >>AFAICS, what it suggests, in a very roundabout way, is that you may be >>able to verify the binding between a key and some kind of DN by being >>given a list of signatures attesting to that binding. This is pretty >>much PGP's Web of Trust, of course. I could be wrong, I only read it >>quickly. > > > This would still depend on what the paper calls "extrinsic references", > that are outside the dialogue and create opportunity for faults (intentional > or otherwise). The resulting problems for PGP are summarized in > www.mcg.org.br/cert.htm#1.2. It seems to me that the difference between PGP's WoT and what you are suggesting is that the entity which is attempting to prove the linkage between their DN and a private key is that they get to choose which signatures the relying party should refer to. Am I wrong? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From lynn at garlic.com Tue Mar 25 17:32:00 2003 From: lynn at garlic.com (Anne & Lynn Wheeler) Date: Tue, 25 Mar 2003 15:32:00 -0700 Subject: Who's afraid of Mallory Wolf? In-Reply-To: References: <200303251242.38253.iang@systemics.com> Message-ID: <4.2.2.20030325150724.00b70310@mail.earthlink.net> At 12:09 PM 3/25/2003 -0800, bear wrote: >ISP's don't want to support encrypted links >because it raises their CPU costs. And mail >clients generally aren't intelligently designed >to handle encrypted email which the mail servers >could just "pass through without decrypting and >encrypting". circa '95 .... there were comments that ISP's didn't want to verify from/spoofed packet addresses on DHCP modem connections because it increased their router cpu costs (actually one of the most common routers didn't have enuf processor power to implement even trivial packet filtering on modem lines). http://www.garlic.com/~lynn/2001m.html#27 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement http://www.garlic.com/~lynn/2001m.html#28 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement http://www.garlic.com/~lynn/2001m.html#29 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement http://www.garlic.com/~lynn/2001m.html#30 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement http://www.garlic.com/~lynn/2001m.html#31 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement now there is the observation in this thread (or the previous thread) that many websites use SSL very sparingly because it cuts their web traffic capacity by 80-90 percent (http vis-a-vis https given the same hardware). Typical sequence is that person clicks-on/types something and goes to a site with straight HTTP, they shop for a while ... until they are ready to check-out, they then click on the "check-out" button. That button supplies a URL that sends them off to a HTTPS site (aka the user didn't actually originated the HTTPS url) ... where all the payment information is provided. Now since the client/consumer never provided the actual HTTPS sequence .... but it was provided for them by a webpage at the HTTP site they were shopping at .... it is presumably trivial for the HTTP site that they are shopping at to make sure that the HTTPS URL domain that clients are sent to .... matches the certificate domain at that site (and a lot of shopping URLs have a lot of appended history so that it is relatively easily contrived that the consumer doesn't notice the domain name of the "check-out/payment" page). A lot of the requirement for encryption is end-to-end ... or at least VPN-like .... so encrypted packets should mostly be transparent to operations in their ISP roles. This isn't as true on the web-hosting side of the house ... where SSL or similar encryption activity can represent significant additional CPU processing load. -- Anne & Lynn Wheeler http://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From nop at trapped-under-ice.com Tue Mar 25 15:42:07 2003 From: nop at trapped-under-ice.com (NOP) Date: Tue, 25 Mar 2003 12:42:07 -0800 Subject: Who's afraid of Mallory Wolf? References: <013F443A-5E8D-11D7-B5A0-000393754B1C@vangelderen.org> <3E800350.5908EAE8@nma.com> Message-ID: <000d01c2f328$cc0d72b0$6f42420a@lanwan> ----- Original Message ----- From: "Ed Gerck" To: "Jeroen C. van Gelderen" Cc: "Ian Grigg" ; Sent: Monday, March 24, 2003 11:20 PM Subject: Re: Who's afraid of Mallory Wolf? > > > "Jeroen C. van Gelderen" wrote: > > > 1. Presently 1% of Internet traffic is protected by SSL against > > MITM and eavesdropping. > > > > 2. 99% of Internet traffic is not protected at all. > > I'm sorry, but no. The bug in MSIE, that prevented the correct > processing of cert path restraints and which led to easy MITM > attacks, has been fixed for some time now. Consulting browser > statistics sites will show that the MSIE update in question, > fueled by the need for other security updates, is making > good progress. > Their is another bug that has not been fixed by MS that allows signed but invalid certificates to be used to MITM the browser as well with no notification. > > 3. A significant portion of the 99% could benefit from > > protection against eavesdropping but has no need for > > MITM protection. (This is a priori a truth, or the > > traffic would be secured with SSL today or not exist.) > > I'm sorry but the "a priori truth" above is false . Ignorance about > the flaw, that is now fixed, and the need to do a LAN attack (if > you want not to mess with the DNS) have helped avert a major > public exploit. The hole is now fixed and the logic fails for this > reason as well. > > > 4. The SSL infrastructure (the combination of browsers, > > servers and the protocol) does not allow the use of > > SSL for privacy protection only. AnonDH is not supported > > by browsers and self-signed certificates as a workaround > > don't work well either. > > There is a good reason -- MITM. AnonDH and self-signed > certs cannot prevent MITM. > > > > > 5. The reason for (4) is that the MITM attack is overrated. > > People refuse to provide the privacy protection because > > it doesn't protect against MITM. Even though MITM is not > > a realistic attack (2), (3). > > But it is, please see the spoof/MITM method in my previous post. > Which, BTW, is rather old info in some circles (3 years?) and is > easy to do by script kiddies with no knowledge about anything we > are talking here -- they can simply do it. Anyone can do it. > > > (That is not to say that (1) can do without MITM > > protection. I suspect that IanG agrees with this > > even though his post seemed to indicate the contrary.) > > I think Ian's post, with all due respect to Ian, reflects a misconception > about cert validation. The misconception is that cert validation can > be provided as an absolute reference -- it cannot. The *mathematical* > reasons are explained in the paper I cited. This misconception > was discussed some 6 years in the ssl-talk list and other lists, and > clarified at the time -- please see the archives. It was good, however, > to post this again and, again, to allow this to be clarified. > > > > > 6. What is needed is a system that allows hassle-free, > > incremental deployment of privacy-protecting crypto > > without people whining about MITM protection. > > You are asking for the same thing that was asked, and answered, > 6 years ago in the ssl-talk and other lists. There is a way to do it > and the way is not self-signed certs or SSL AnonDH. > > > Now, this is could be achieved by enabling AnonDH in the SSL > > infrastructure and making sure that the 'lock icon' is *not* displayed > > when AnonDH is in effect. Also, servers should enable and support > > AnonDH by default, unless disabled for performance reasons. > > Problem -- SSL AnonDH cannot prevent MITM. The solution is > not to deny the problem and ask "who cares about MITM?" > > > Ed Gerck wrote: > > > BTW, this is NOT the way to make paying for CA certs go > > > away. A technically correct way to do away with CA certs > > > and yet avoid MITM has been demonstrated to *exist* > > > (not by construction) in 1997, in what was called intrinsic > > > certification -- please see www.mcg.org.br/cie.htm > > > > Phew, that is a lot of pages to read (40?). Its also rather though > > material for me to digest. Do you have something like an example > > approach written up? I couldn't find anything on the site that did not > > require study. > > > ;-) If anyone comes across a way to explain it, that does not require study, > please let me know and I'll post it. > > OTOH, some practical code is being developed, and has been sucessfully > tested in the past 3 years with up to 300,000 simultaneous users, which > may provide the example you ask for. Please write to me privately if you'd > like to use it. > > Cheers, > Ed Gerck > > > --------------------------------------------------------------------- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com > --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From rsalz at datapower.com Tue Mar 25 18:02:45 2003 From: rsalz at datapower.com (Rich Salz) Date: Tue, 25 Mar 2003 18:02:45 -0500 (EST) Subject: Who's afraid of Mallory Wolf? In-Reply-To: <5.1.1.6.2.20030325115133.02de7e78@idiom.com> Message-ID: > I get the impression that we're talking at cross-purposes here, > with at least two different discussions. I suspect that the discussion started from commercial motivations; cf www.systemics.com /r$ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From egerck at nma.com Tue Mar 25 19:24:54 2003 From: egerck at nma.com (Ed Gerck) Date: Tue, 25 Mar 2003 16:24:54 -0800 Subject: Who's afraid of Mallory Wolf? References: <013F443A-5E8D-11D7-B5A0-000393754B1C@vangelderen.org> <3E800350.5908EAE8@nma.com> <3E8091CC.40808@algroup.co.uk> <3E80A553.85E5E3FE@nma.com> <3E80CBB9.20100@algroup.co.uk> Message-ID: <3E80F356.E3DBF229@nma.com> Ben Laurie wrote: > It seems to me that the difference between PGP's WoT and what you are > suggesting is that the entity which is attempting to prove the linkage > between their DN and a private key is that they get to choose which > signatures the relying party should refer to. PGP's WoT already does that. To be clear, in PGP the entity that is attempting to prove the linkage between a DN and a public key chooses which signatures are acceptable, their "degree of trust", and how these signatures became acceptable in the first place. BTW, a similar facility also exists in X.509, where the entity that is attempting to prove the linkage may accept or reject a CA for that purpose (unfortunately, browsers make this decision "automatically" for the user but it does not need to be so). That said, the paper does not provide a way to implement the method I suggested. The paper only shows that such a method should exist. Cheers, Ed Gerck --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From dfc at anize.org Tue Mar 25 19:51:39 2003 From: dfc at anize.org (Douglas F. Calvert) Date: 25 Mar 2003 19:51:39 -0500 Subject: Keysigning @ CFP2003 In-Reply-To: References: Message-ID: <1048639898.25216.11.camel@liberate.anize.org> On Tue, 2003-03-25 at 07:52, Janusz A. Urbanowicz wrote: > > I must be out of touch - since when did > > PGP key signing require a photo id? > > It is an usual requirement for a keysigning party to bring a photo ID to > validate if theirs key ids are the same as their names (and to get class 3 > key signatures) I usually reserve class three signatures to people that I know very well. Casual photo ID and fingerprint verification usually produces a ersion 2 signature from me. Furthermore GPG also allows for the insertion of a signature policy URL in a signature. The policy URL is a description of what process you went through to verify an identity... -- + Douglas Calvert dfc at anize.org http://anize.org/dfc/ + | Key Id 0xC9541FB2 http://anize.org/dfc-keys.asc | | [X] User wants to receive encrypted mail | +| 0817 30D4 82B6 BB8D 5E66 06F6 B796 073D C954 1FB2 |+ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 193 bytes Desc: This is a digitally signed message part URL: From iang at systemics.com Wed Mar 26 01:34:07 2003 From: iang at systemics.com (Ian Grigg) Date: Wed, 26 Mar 2003 01:34:07 -0500 Subject: Who's afraid of Mallory Wolf? In-Reply-To: <5.1.1.6.2.20030325115133.02de7e78@idiom.com> References: <1048533083.27535.40342.camel@banks> <5.1.1.6.2.20030325115133.02de7e78@idiom.com> Message-ID: <200303260134.07355.iang@systemics.com> On Tuesday 25 March 2003 15:22, Bill Stewart wrote: > I get the impression that we're talking at cross-purposes here, > with at least two different discussions. Yep. I haven't counted them up yet, but the full discussion includes at least 6 disparate threads. The challenge is to not arbitrarily switch from one thread to another without losing the context of the first. The way I got where (I think) I am is this: Fact: The SSL cert that is required for the server is expensive. Question: Why do we have to pay that expense, and what happens if we use a self-signed cert? Answer: "the MITM!" "Spoofing!" OK, so now let's challenge the assumptions: Question: What is the MITM? And why should we care? And, when we've answered that question, let's plug that truth back into the 1st question. (And, the same for spoofing.) > Let's look at several cases: > > 1 - Sites that have SSL and Expensive Certs that need them and need MITM > protection > 1a - These sites, but with other security holes making it easy to break in. > 1b - These sites, broken by SSL bugs or browser bugs > 2 - Sites that have SSL and Expensive Certs that don't need them, > as long as they've got some crypto like self-signed certs, > which don't give MITM protection > 3 - Sites that don't have SSL today because it's too annoying, > for which crypto would be useful, > and ADH or self-signed certs would be good enough, > because MITM isn't a big threat for them. > 4 - Sites that don't need crypto. Fantastic! a 2 x 2: GOT HTTP SSL+ ONLY cert Want Crypto 1 Want (may have bugs) certs Want 2 3 Crypto (adh/ssc) Don't 4 want Crypto Totals: 1% 99% Hmm, it drew out as a 2 x 3 (only in fixed font). So, I wonder what the totals on the right would be? How many people want crypto/MITM, how many would be happy with crypto/no MITM protection, and how many don't want any crypto? -- iang --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From smb at research.att.com Tue Mar 25 22:34:09 2003 From: smb at research.att.com (Steven M. Bellovin) Date: Tue, 25 Mar 2003 22:34:09 -0500 Subject: Who's afraid of Mallory Wolf? In-Reply-To: Your message of "25 Mar 2003 18:17:45 GMT." Message-ID: <20030326033409.43C417B8B@berkshire.research.att.com> > >That's using a questionable measuring stick. >The damages paid out in a civil suit may be very >different (either higher, or lower) than the true >cost of the misconduct. Remember, the courts are >not intended to be a remedy for all harms, nor could >they ever be. The courts shouldn't be a replacement >for our independent judgement. > Let me quote what the (U.S.) 2nd Circuit Court of Appeals said in the T.J. Hooper case (60 F.2d 737, 1932): Indeed in most cases reasonable prudence is in face common prudence; but strictly it is never its measure; a whole calling may have unduly lagged in the adoption of new and available devices. It may never set its own tests, however persuasive be its usages. Courts must in the end say what is required; there are precautions so imperative that even their universal disregard will not excuse their omission.... But here there was no custom at all as to receiving sets; some had them, some did not; the most that can be urged is that they had not yet become general. Certainly in such a case we need not pause; when some have thought a device necessary, at least we may say that they were right, and the others too slack. Given that there were published warnings of *practical* MITM attacks (my papers, Radia Perlman's dissertation on secure routing, Lawrence Joncheray's paper on TCP hijacking, etc.), I have no doubt whatsoever what a (U.S.) court would have ruled if there had ever been a real attack. Given that MITM attacks have happened, I have just about as little doubt that they would have been used to steal credit card numbers if SSL had no protection. Look at it this way -- we've already had passowrd-eavesdropping (vintage 1993), off-the-shelf TCP hijacking code (Dug Song's package), and moderate-scale hacked machines for credit card number and account number theft (Internet cafes in Japan, about a month ago -- I'm on the train, and don't have the precise citation handy.) Given all that, do you doubt that the hackers would have combined the easily-available pieces into a MITM attack? I don't. The real issue in the original post seems to be the cost of a "trusted" certificate. I submit that there are other ways to solve that problem than abandoning a very necessary protection. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From kelm at secorvo.de Wed Mar 26 03:57:10 2003 From: kelm at secorvo.de (Stefan Kelm) Date: Wed, 26 Mar 2003 09:57:10 +0100 Subject: Keysigning @ CFP2003 In-Reply-To: <200303251555.h2PFtk2Y007710@gungnir.fnal.gov> References: Your message of Mon, 24 Mar 2003 19:24:55 EST. <3423551E-5E58-11D7-B5A0-000393754B1C@vangelderen.org> Message-ID: <3E817976.25034.29EE57@localhost> > Has anyone ever weighted a PGP key's certification value as a > function of how many keys it's know to have certified? The PGP keyserver folks perform a regular public keyring analysis: http://keyserver.kjsl.com/~jharris/ka/2003-03-23/ http://dtype.org/keyanalyze/ Cheers, Stefan. ------------------------------------------------------- Dipl.-Inform. Stefan Kelm Security Consultant Secorvo Security Consulting GmbH Albert-Nestler-Strasse 9, D-76131 Karlsruhe Tel. +49 721 6105-461, Fax +49 721 6105-455 E-Mail kelm at secorvo.de, http://www.secorvo.de ------------------------------------------------------- PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From iang at systemics.com Wed Mar 26 12:50:28 2003 From: iang at systemics.com (Ian Grigg) Date: Wed, 26 Mar 2003 12:50:28 -0500 Subject: Who's afraid of Mallory Wolf? In-Reply-To: <20030326033409.43C417B8B@berkshire.research.att.com> References: <20030326033409.43C417B8B@berkshire.research.att.com> Message-ID: <200303261250.29000.iang@systemics.com> On Tuesday 25 March 2003 22:34, Steven M. Bellovin wrote: > Let me quote what the (U.S.) 2nd Circuit Court of Appeals said in the > T.J. Hooper case (60 F.2d 737, 1932): > > Indeed in most cases reasonable prudence is in face common prudence; > but strictly it is never its measure; a whole calling may have unduly lagged > in the adoption of new and available devices. > It may never set its own tests, however persuasive be its usages. > Courts must in the end say what is required; there are precautions > so imperative that even their universal disregard will not > excuse their omission.... > > But here there was no custom at all as to receiving sets; some had > them, some did not; the most that can be urged is that they had > not yet become general. Certainly in such a case we need not > pause; when some have thought a device necessary, at least we may > say that they were right, and the others too slack. > > Given that there were published warnings of *practical* MITM attacks (my > papers, Radia Perlman's dissertation on secure routing, Lawrence > Joncheray's paper on TCP hijacking, etc.), I have no doubt whatsoever > what a (U.S.) court would have ruled if there had ever been a real attack. I'm sorry, I won't be able to do more than speculate on this, and I wasn't aware of your legal background, so please take the below as "not advice." I.e., IANAL and all that. Courts are notoriously difficult to predict. That's why they say "take legal advice" :-) And, it may very well be that Netscape took legal advice, and at that time, it did seem that MITM protection at the level of CA-certificates was a reasonable choice (c.f., David Wagner's post) amongst other reasonable choices, so I don't think there is any doubt that what was done back in '94 was reasonable in the circumstances. But, on the face of it, you appear to be saying that because the court saw warnings then it ruled that the warnings were sufficient. I don't read that at all. I see that interpretatation as a Chicken Little argument. This opens the way to Info-war style consultants saying that because you were warned, you are liable. That above snippet says "there are precautions so imperative" which implies the court had already reached its opinion on the merits of this protection, which is precisely what this discussion has aimed to address. In fact, the court said very clearly that it is the one to decide what the test is - not the industry. The court then went on to say that, as it found the precautions imperitive, and as the industry had warned, albeit contraversially, then, it concluded, relying on the lack of industry custom and agreement as a defence was insufficient. So, with respect, I would say that the above should be read as "do not rely on discordant others, be they so-called experts or Chicken Littles on either side, in applying your own prudential measures," which is quite the reverse of your reading. Now, the above is speculation; not having the full ruling and the full training, one can't do more. But, to take mere warnings as liabilities is to forgoe ones profession as an engineer, and hand ones responsibilities over on the one hand to the religious seers of doom, and on the other, to the lawyers. The ludicrousness of this approach is perhaps more crystallised when we consider that half of the world's web servers are shipped for free (c.f Apache). The crypto components are still, AFAIK, dealt with outside America for the most part. And, a growing share of browsers are now shipping for free or near-free. We've seen over the last year or so, Konqueror, Mozilla, and Safari rise to take back the forgotten gauntlet of "browser for the rest of us." These are not sold products. There are no contracts that imply security. The world of open source is not necessarily going to be treated in the courts the same as a purchased product with implicit liabilities of a consumer nature. I grant that America may be moving towards a world where Eric Y or Ben L will be norieged and hailed before a california court in some case for inadequate MITM protection, but, I personally don't see that as a world that I would accept on the face value of some legal handwaving. Is that really what we want for our Internet? -- iang PS: It is apropos that the CA industry uses the same approach in trying to define industry custom as sufficient; see Jane K Winn, _Courriers without Luggage_ for her expose of the fallacy in this. In contrast to your implied claim that SSL providers would be at risk if they didn't do the MITM approach, I'd suspect that CAs are on the hook, because of the very arguments that Winn and, now, Hooper advance. ) --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From perry at piermont.com Wed Mar 26 13:36:35 2003 From: perry at piermont.com (Perry E. Metzger) Date: 26 Mar 2003 13:36:35 -0500 Subject: meet in the middle attacks Message-ID: <87u1dqasb0.fsf@snark.piermont.com> I have to say I've watched this with a bit of puzzlement. Meet in the middle attacks are perfectly real. I've seen them myself, and toolkits to perform them are readily available out there. Ian's vague comments about a lack of evidence of the economic impact notwithstanding, it is unreasonable to leave one's protocols and systems open to such attacks. You do not need an elaborate CA infrastructure to prevent them, of course. SSH manages to prevent them simply by having both sides sign exchanges using naked (i.e. uncertified) keys that are pre-shared, for example. Even use of MACs over exchanged values and pre-shared conventional keys can prevent many such attacks. However, not attempting to prevent such attacks -- especially given that they are very effective -- seems foolish at best. -- Perry E. Metzger perry at piermont.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From perry at piermont.com Wed Mar 26 17:55:09 2003 From: perry at piermont.com (Perry E. Metzger) Date: 26 Mar 2003 17:55:09 -0500 Subject: yes, I know... Message-ID: <87llz17n76.fsf@snark.piermont.com> I meant Man in the Middle, not Meet in the Middle. Sigh. -- Perry E. Metzger perry at piermont.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From adam at homeport.org Wed Mar 26 16:43:06 2003 From: adam at homeport.org (Adam Shostack) Date: Wed, 26 Mar 2003 16:43:06 -0500 Subject: Keysigning @ CFP2003 In-Reply-To: <200303250036.20891.iang@systemics.com> References: <200303250036.20891.iang@systemics.com> Message-ID: <20030326214306.GA83092@lightship.internal.homeport.org> On Tue, Mar 25, 2003 at 12:36:20AM -0500, Ian Grigg wrote: | So, do we have two completely disjoint communities | here? One group that avoids "photo id" and another | that requires it? Or is one group or the other so | small that nobody really noticed? Yes. One group thinks that a bad trust chain is worse than no trust chains. This group tends to think that fake ID is easy, and that ID based signatures reduce trust in the web. Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From derek at ihtfp.com Wed Mar 26 17:50:47 2003 From: derek at ihtfp.com (Derek Atkins) Date: 26 Mar 2003 17:50:47 -0500 Subject: meet in the middle attacks In-Reply-To: <87u1dqasb0.fsf@snark.piermont.com> References: <87u1dqasb0.fsf@snark.piermont.com> Message-ID: Note that SSH is vulnerable to a Man in the Middle attack (not meet in the middle -- that is an attack on 2DES where you attack from the input and output and then "meet in the middle"). In particular SSH is vulnerable if you do NOT have the long-term server key cached on the client. That notwithstanding, I think that Ian is just upset about paying for an SSL Cert and wants a way to setup an SSL/TLS server without paying homage to one of the Big Three (or is it down to Big One at this point?). Ignore the fact that he could use self-signed certs and be as secure as SSH. -derek "Perry E. Metzger" writes: > I have to say I've watched this with a bit of puzzlement. > > Meet in the middle attacks are perfectly real. I've seen them myself, > and toolkits to perform them are readily available out there. Ian's > vague comments about a lack of evidence of the economic impact > notwithstanding, it is unreasonable to leave one's protocols and > systems open to such attacks. > > You do not need an elaborate CA infrastructure to prevent them, of > course. SSH manages to prevent them simply by having both sides sign > exchanges using naked (i.e. uncertified) keys that are pre-shared, for > example. Even use of MACs over exchanged values and pre-shared > conventional keys can prevent many such attacks. > > However, not attempting to prevent such attacks -- especially given > that they are very effective -- seems foolish at best. -- Derek Atkins Computer and Internet Security Consultant derek at ihtfp.com www.ihtfp.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From rabbi at abditum.com Wed Mar 26 18:12:14 2003 From: rabbi at abditum.com (Len Sassaman) Date: Wed, 26 Mar 2003 15:12:14 -0800 (PST) Subject: Keysigning @ CFP2003 In-Reply-To: <200303241100.01141.iang@systemics.com> Message-ID: On Mon, 24 Mar 2003, Ian Grigg wrote: > I must be out of touch - since when did > PGP key signing require a photo id? It does not. It is improper for a key-signing organizer to dictate signing policy to individuals. When I wrote the Efficient Group Key Signing Method paper[1], I specifically omitted identity verification steps, since it is no one's business but the holder of the key (and those who trust that key as an introducer) what information the holder requires before signing. Incidentally, the GnuPG FAQ perpetuates this fallacy, so Doug is probably not to blame for this mistake. There are better ways of determining identity, and one of the benefits of PGP is that we aren't locked in to a strict, rigid model of how trust is to be assigned. Convincing people that [easily forged] government IDs are sufficient to verify identity is a dangerous practice. A better thing to do is to announce in the key-signing notice that individuals may want to bring government ID in the case that someone attending will require it to satisfy his signing policy -- rather than dictating signing policy to your participants. --Len. [1] http://sion.quickie.net/keysigning.txt --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From rah at shipwright.com Wed Mar 26 17:52:44 2003 From: rah at shipwright.com (R. A. Hettinga) Date: Wed, 26 Mar 2003 17:52:44 -0500 Subject: Network Associates Plans Another Restatement of Results Message-ID: The Wall Street Journal March 26, 2003 4:46 p.m. EST ? Network Associates Plans Another Restatement of Results By MARK BOSLET and RIVA RICHMOND DOW JONES NEWSWIRES Network Associates Inc. said Wednesday it would again restate financial results for 1998, 1999 and 2000 and disclosed that the Department of Justice had opened an investigation into the company. It will be the second time Network Associates has had to restate results for those years. The Santa Clara, Calif., software company said the latest restatement would probably lead to a significant or "material" change to financial results for the period, which precedes the resignation of its former management team headed by Chief Executive William Larson. Network Associates' current chief executive, George Samenuk, said on a conference call Wednesday that the company learned of the Justice Department investigation during the first quarter. "We will not speculate on where it is headed or on what the potential outcome might be," Mr. Samenuk said. However, legal experts said the Justice Department likely wouldn't become involved unless there was a criminal aspect to the investigation, which up to now had been confined to an accounting probe by the Securities and Exchange Commission. While the Justice Department can indict corporations, history shows it tends to look upon them as victims of unscrupulous executives, said John Coffee, a legal expert at Columbia University Law School. "They're most likely to indict the person who has the evil motive," he said. "And that tends to be the managers who are dumping their stock" to benefit from practices that inflated financial results. The restatement is the result of new information that came up during the government investigations, Network Associates said. "We had lots of discussions with the government in recent weeks," said General Counsel Kent Roberts. He declined to elaborate on their content. The restatement that Network Associates announced Wednesday stems from a decision to change its revenue recognition policy made in 2001, the new results will reflect that policy, which recognizes sales when products reached users rather than when they were shipped to a distributor or reseller. The company suggested the restatement would take at least a couple weeks to complete and that it would delay its quarterly SEC filing for its 2002 financial report. The news sent Network Associates' shares modestly lower Wednesday, falling 53 cents, or 3.5%, to $14.85 on the New York Stock Exchange. In June, Network Associates restated 1998, 1999 and 2000 results after an internal probe of the company's accounting revealed "inaccuracies," which it traced to an unidentified member of the finance team who was no longer with the company. The bad accounting had the effect of overstating revenue and understating operating costs. None of Network Associates' current financial executives worked for the company during the years in question. The company's announcement marks the third time in four years it has had to restate financial results. It restated its financials in 1999 to reflect the cost of numerous acquisitions, which it accounted for as in-process research-and-development costs. -- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From jaltman at columbia.edu Wed Mar 26 19:20:53 2003 From: jaltman at columbia.edu (Jeffrey Altman) Date: Wed, 26 Mar 2003 19:20:53 -0500 Subject: meet in the middle attacks In-Reply-To: <87u1dqasb0.fsf@snark.piermont.com> References: <87u1dqasb0.fsf@snark.piermont.com> Message-ID: <3E8243E5.3010703@columbia.edu> I believe that most browsers and even some TELNET/FTP/SMTP clients that support START_TLS will allow the certificate to be saved as an authenticator of the host provided that the certificate is not a self-signed cert. If you do not want to use a commercial CA, then you should generate your own CA cert plus one End Entity cert signed by your CA cert. Use the End Entity cert for your service. This process could easily be added to the makefile for Apache or even OpenSSL. - Jeff Perry E. Metzger wrote: >I have to say I've watched this with a bit of puzzlement. > >Meet in the middle attacks are perfectly real. I've seen them myself, >and toolkits to perform them are readily available out there. Ian's >vague comments about a lack of evidence of the economic impact >notwithstanding, it is unreasonable to leave one's protocols and >systems open to such attacks. > >You do not need an elaborate CA infrastructure to prevent them, of >course. SSH manages to prevent them simply by having both sides sign >exchanges using naked (i.e. uncertified) keys that are pre-shared, for >example. Even use of MACs over exchanged values and pre-shared >conventional keys can prevent many such attacks. > >However, not attempting to prevent such attacks -- especially given >that they are very effective -- seems foolish at best. > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3427 bytes Desc: S/MIME Cryptographic Signature URL: From jam at wirerimmed.com Wed Mar 26 21:47:14 2003 From: jam at wirerimmed.com (James Moore) Date: Wed, 26 Mar 2003 18:47:14 -0800 Subject: Annoucement: Initial release of Poindexter is available Message-ID: <6AA9D59D-5FFE-11D7-8944-000393762B4A@wirerimmed.com> I'm pleased to announce the initial release of Poindexter. http://wirerimmed.com/poindexter Poindexter is a Java applet that provides the basic four functions of PGP plus: * It runs locally and does not require an internet connection * It (theoretically) runs on any platform with a working Java Plug-in * It's small enough to fit on a floppy disk along with your keys * In limited testing, it interoperates with GnuPG and PGP 8 * Available source code Poindexter has many weaknesses but the major ones are: * Relies on the Java Plug-in * Requires that Java security be crippled in order to run. * It uses the Cryptix OpenPGP [1] libraries. These libraries are not yet fully-baked * It doesn't run out of the box due to java policy restrictions * Passwords and keys can probably be harvested from memory on shared machines * Password input is not shielded * No Web of Trust functions With Poindexter I'm trying to fill a need that Tinfoil Hat Linux [2] doesn't quite cover. Namely, users who want/need portable crypto but are not technical enough to use Tinfoil. Please try out this software and let me know what your feelings are on it and it's purpose. -James [1] http://cryptix.org/products/openpgp/ [2] http://tinfoilhat.shmoo.com/ ___________________________________________________ WireRimmed - Small business and non-profit technology services http://wirerimmed.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From elaine.barker at nist.gov Thu Mar 27 09:19:24 2003 From: elaine.barker at nist.gov (Elaine Barker) Date: Thu, 27 Mar 2003 09:19:24 -0500 Subject: NIST Key Mgmt. Drafts Message-ID: <5.1.0.14.2.20030327090642.01d143b8@email.nist.gov> Reminder: NIST is requesting comments on three draft key management documents that were posted in January. The end of the comment period on two of those drafts is April 3 (next week). If you have not seen those drafts, they are available at http://csrc.nist.gov/CryptoToolkit/tkkeymgmt.html. 1. "Recommendation for Key Management, Part 1: General Guideline" provides general key management guidance for system developers and system administrators. This is a revision of a draft provided in June, 2002. Please submit comments to GuidelineComments at nist.gov by April 3, 2003. 2. "Recommendation on Key Establishment Schemes" provides specifications of key establishment schemes based on standards developed by the American National Standards Institute (ANSI) X9: ANSI X9.42, Agreement of Symmetric Keys Using Discrete Logarithm Cryptography, and ANSI X9.63, Key Agreement and Key Transport Using Elliptic Curve Cryptography. Inclusion of RSA techniques as specified in ANSI X9.44, Key Establishment Using Integer Factorization Cryptography, is planned for the future. This draft is a revision of a draft provided in October, 2001. Please submit comments to kmscomments at nist.gov by April 3, 2003. Elaine Barker National Institute of Standards and Technology 100 Bureau Dr., Stop 8930 Gaithersburg, MD 20899-8930 Phone: 301-975-2911 Fax: 301-948-1233 Email: ebarker at nist.gov --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ben at algroup.co.uk Fri Mar 28 03:13:46 2003 From: ben at algroup.co.uk (Ben Laurie) Date: Fri, 28 Mar 2003 08:13:46 +0000 Subject: Test Vectors? Message-ID: <3E84043A.7050204@algroup.co.uk> Does anyone have test vectors for the X19.7 PRNG (HAC p.173)? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From mads at opencs.com.br Fri Mar 28 12:24:36 2003 From: mads at opencs.com.br (Mads Rasmussen) Date: Fri, 28 Mar 2003 14:24:36 -0300 Subject: RES: Test Vectors? Message-ID: <23F980CFF4C45B4792FFF3CE015C541A02607D@olimpia.opencs.com.br> > -----Mensagem original----- > De: Ben Laurie [mailto:ben at algroup.co.uk] > Enviada em: sexta-feira, 28 de mar?o de 2003 05:14 > Para: Cryptography > Assunto: Test Vectors? > > Does anyone have test vectors for the X19.7 PRNG (HAC p.173)? The NIST STS PRNG test suite includes an implementation for X9.17 http://csrc.nist.gov/rng/sts-1.5.tar look in generators/generator3.c Mads --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From perry at piermont.com Fri Mar 28 13:10:56 2003 From: perry at piermont.com (Perry E. Metzger) Date: 28 Mar 2003 13:10:56 -0500 Subject: Run a remailer, go to jail? Message-ID: <87k7ejmken.fsf@snark.piermont.com> http://www.freedom-to-tinker.com/archives/000336.html Quoting: Here is one example of the far-reaching harmful effects of these bills. Both bills would flatly ban the possession, sale, or use of technologies that "conceal from a communication service provider ... the existence or place of origin or destination of any communication". -- Perry E. Metzger perry at piermont.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From fields at surgam.net Fri Mar 28 16:20:14 2003 From: fields at surgam.net (Adam Fields) Date: Fri, 28 Mar 2003 16:20:14 -0500 Subject: Run a remailer, go to jail? In-Reply-To: <87k7ejmken.fsf@snark.piermont.com> References: <87k7ejmken.fsf@snark.piermont.com> Message-ID: <20030328212014.GJ31168@eye.surgam.net> On Fri, Mar 28, 2003 at 01:10:56PM -0500, Perry E. Metzger wrote: > > http://www.freedom-to-tinker.com/archives/000336.html > > Quoting: > > Here is one example of the far-reaching harmful effects of > these bills. Both bills would flatly ban the possession, sale, > or use of technologies that "conceal from a communication > service provider ... the existence or place of origin or > destination of any communication". Not to mention that they pretty much put Linksys, D-Link, and Netgear out of business by outlawing NAT. -- - Adam ----- Adam Fields, Managing Partner, fields at surgam.net Surgam, Inc. is a technology consulting firm with strong background in delivering scalable and robust enterprise web and IT applications. http://www.adamfields.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From crawdad at fnal.gov Fri Mar 28 16:32:19 2003 From: crawdad at fnal.gov (Matt Crawford) Date: Fri, 28 Mar 2003 15:32:19 -0600 Subject: Run a remailer, go to jail? In-Reply-To: Your message of Fri, 28 Mar 2003 13:10:56 EST. <87k7ejmken.fsf@snark.piermont.com> Message-ID: <200303282132.h2SLWJ2Y013749@gungnir.fnal.gov> > http://www.freedom-to-tinker.com/archives/000336.html > > Quoting: > > Here is one example of the far-reaching harmful effects of > these bills. Both bills would flatly ban the possession, sale, > or use of technologies that "conceal from a communication > service provider ... the existence or place of origin or > destination of any communication". Let's not be hasty. On the upside, it would outlaw NAT! --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From mowen at costco.com Fri Mar 28 16:52:27 2003 From: mowen at costco.com (Michael Owen) Date: Fri, 28 Mar 2003 13:52:27 -0800 Subject: Run a remailer, go to jail? Message-ID: <7A08ACBD2F401A4196C29C55B819782A05214CFE@pof0099p06.corp.costco.com> While taking a look at the proposed Texas law, it appears that it only applies if you are trying to actually cause harm: QUOTE: SECTION 2. Sections 31.12(a), (b), and (e), Penal Code, are amended to read as follows: (a) A person commits an offense if, with the intent to harm or defraud a communication service It doesn't look as bad as it was made out to be, but it all depends on how they determine "intent". [Moderator's note: is using a NAT box "intent to defraud" a cable modem provider? --Perry] Mike --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From galvin at acm.org Fri Mar 28 16:54:10 2003 From: galvin at acm.org (James M Galvin) Date: Fri, 28 Mar 2003 16:54:10 -0500 (Eastern Standard Time) Subject: Run a remailer, go to jail? In-Reply-To: <87k7ejmken.fsf@snark.piermont.com> References: <87k7ejmken.fsf@snark.piermont.com> Message-ID: No way. The phrase "flatly ban" is overstating the words in the actual bills. They both require that the use of such technologies be for the purpose of committing a crime. Law enforcement would still have to show intent, which is as it should be. If take the point of view in the essay to its logical conclusion then mailing lists and in some configurations the use of PGP, S/MIME, or VPNs would be illegal also. Maybe states are colluding to outlaw encryption? Now that would be creative on the part of whoever started this bill process. Jim On Fri, 28 Mar 2003, Perry E. Metzger wrote: Date: Fri, 28 Mar 2003 13:10:56 -0500 From: Perry E. Metzger To: cryptography at wasabisystems.com Subject: Run a remailer, go to jail? http://www.freedom-to-tinker.com/archives/000336.html Quoting: Here is one example of the far-reaching harmful effects of these bills. Both bills would flatly ban the possession, sale, or use of technologies that "conceal from a communication service provider ... the existence or place of origin or destination of any communication". -- Perry E. Metzger perry at piermont.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ji at research.att.com Fri Mar 28 16:56:01 2003 From: ji at research.att.com (ji at research.att.com) Date: Fri, 28 Mar 2003 16:56:01 -0500 (EST) Subject: Run a remailer, go to jail? Message-ID: <200303282156.h2SLu1h00169@bual.research.att.com> > out of business by outlawing NAT. I'll drink to that (and the the universal deployment of IPv6)! /ji --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From sidney at sidney.com Fri Mar 28 17:49:59 2003 From: sidney at sidney.com (Sidney Markowitz) Date: Sat, 29 Mar 2003 10:49:59 +1200 Subject: Run a remailer, go to jail? References: <87k7ejmken.fsf@snark.piermont.com> Message-ID: <010801c2f57c$5fd5eb80$7901a8c0@sidora> > They both require that the use of such technologies be for > the purpose of committing a crime. The Massachusetts law defines as a crime: (b) Offense defined.--Any person commits an offense if he knowingly (1) possesses, uses, manufactures, develops, assembles, distributes, transfers, imports into this state, licenses, leases, sells or offers, promotes or advertises for sale, use or distribution any communication device: [ ... ] or; (ii) to conceal or to assist another to conceal from any communication service provider, or from any lawful authority, the existence or place of origin or destination of any communication; [...] (5) Assist others in committing any of the acts prohibited by this section. And it also says under civil actions: (1) Any person aggrieved by a violation of this section may bring a civil action in any court of competent jurisdiction. "Any person aggrieved" shall include any communication service provider -------------- This does seem broad enough to be used in situations other than outright fraud against an ISP or communications company. There is language about "intent to defraud" in Section 1 but the language in Section 2 (b)(1) about possession, use, manufacture, etc., would seem to have the same kind of broadness we have seen misused in the DMCA, covering people who sell NAT and encryption tools that might be used by someone who sends email while attempting to defraud a communications service provider. -- sidney markowitz sidney at sidney.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From smb at research.att.com Fri Mar 28 18:06:26 2003 From: smb at research.att.com (Steven M. Bellovin) Date: Fri, 28 Mar 2003 18:06:26 -0500 Subject: Run a remailer, go to jail? In-Reply-To: Your message of "Fri, 28 Mar 2003 16:54:10 EST." Message-ID: <20030328230626.6830C7B4D@berkshire.research.att.com> In message , James M Galvin writes: >No way. The phrase "flatly ban" is overstating the words in the actual >bills. > >They both require that the use of such technologies be for the purpose >of committing a crime. Law enforcement would still have to show intent, >which is as it should be. > ... >Maybe states are colluding to outlaw encryption? Now that would be >creative on the part of whoever started this bill process. > The question is more complicated than that. The full text of the Texas bill is at http://www.capitol.state.tx.us/data/docmodel/78r/billtext/pdf/HB02121I.PDF (I haven't found the Mass. version). It is far from clear to me that intent to commit a crime is needed. Section 2 of the billl, which does contain the phrase "with the intent to harm or defraud a communication service", bars theft of service. (I'm speaking loosely here; read it for yourself.) Section 3 and 4 also contain that phrase; they bar possession of devices for defrauding providers. (The language is rather broad, and seems to bar possession even a computer or modem if you have evil intent.) The ban on concealing origin or destination is in Sections 5 and 6. That section does *not* have the "intent to harm" phrase. Given that the bill is amending three consecutive sections of the state penal code (31.12, 31.13, and 31.14), and given that the first two sections have that language but the third doesn't, it's hard for me to see that evil intent is required by the proposed statute. But it's worse than that: the bill bars concealment of "existence or place of origin or destination of any communication" from "any lawful authority". In other words, it would appear to outlaw many forms of cryptography or steganography. What's unclear to me is who is behind this. Felten thinks it's content providers trying for state-level DMCA; I think it's broadband ISPs who are afraid of 802.11 hotspots. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From bill.stewart at pobox.com Fri Mar 28 19:09:12 2003 From: bill.stewart at pobox.com (Bill Stewart) Date: Fri, 28 Mar 2003 16:09:12 -0800 Subject: Run a remailer, go to jail? In-Reply-To: <20030328230626.6830C7B4D@berkshire.research.att.com> References: Message-ID: <5.1.1.6.2.20030328160619.02ea8760@idiom.com> At 06:06 PM 03/28/2003 -0500, Steven M. Bellovin wrote: >What's unclear to me is who is behind this. Felten thinks it's content >providers trying for state-level DMCA; I think it's broadband ISPs who >are afraid of 802.11 hotspots. It looked to me like it was the cable TV industry trying to ban possession or sale of illegal cable descramblers as well as connection-sharing things like NAT, but it was a bit hard to tell how much of the language was new as opposed to older, so this may have been extending existing cable descrambler laws to also cover 802.11 or Napsterizing your Tivo. I don't think that banning remailers or crypto was the intent, but the cable industry has never been above using nuclear weaponry to discourage cable service theft, regardless of collateral damage. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From egerck at nma.com Fri Mar 28 18:38:54 2003 From: egerck at nma.com (Ed Gerck) Date: Fri, 28 Mar 2003 15:38:54 -0800 Subject: Run a remailer, go to jail? References: <87k7ejmken.fsf@snark.piermont.com> Message-ID: <3E84DD0E.CB40EE00@nma.com> It would also outlaw pre-paid cell phones, that are anonymous if you pay in cash and can be untraceable after a call. Not to mention proxy servers. On the upside, it would ban spam ;-) Cheers, Ed Gerck "Perry E. Metzger" wrote: > http://www.freedom-to-tinker.com/archives/000336.html > > Quoting: > > Here is one example of the far-reaching harmful effects of > these bills. Both bills would flatly ban the possession, sale, > or use of technologies that "conceal from a communication > service provider ... the existence or place of origin or > destination of any communication". > > -- > Perry E. Metzger perry at piermont.com > > --------------------------------------------------------------------- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From rah at shipwright.com Fri Mar 28 21:08:14 2003 From: rah at shipwright.com (R. A. Hettinga) Date: Fri, 28 Mar 2003 21:08:14 -0500 Subject: New Voting Systems Assailed Message-ID: washingtonpost .com New Voting Systems Assailed Computer Experts Cite Fraud Potential By Dan Keating Washington Post Staff Writer Friday, March 28, 2003; Page A12 As election officials rush to spend billions to update the country's voting machines with electronic systems, computer scientists are mounting a challenge to the new devices, saying they are less reliable and less secure from fraud than the equipment they are replacing. Prompted by the demands of state and federal election reforms, officials in Maryland, Georgia, Florida and Texas installed the high-tech voting systems last fall. Officials in those states, and other proponents of electronic voting, said the computer scientists' concerns are far-fetched. "These systems, because of the level of testing they go through, are the most reliable systems available," said Michael Barnes, who oversaw Georgia's statewide upgrade. "People were happy with how they operated." In Maryland, "the system performed flawlessly in the two statewide elections last year," said Joseph Torre, the official overseeing the purchase of the state's new systems. "The public has a lot of confidence in it, and they love it." But the scientists' campaign, which began in California's Silicon Valley in January, has gathered signatures from more than 300 experts, and the pressure has induced the industry to begin changing course. Electronic terminals eliminate hanging chads, pencil erasure marks and the chance that a voter might accidentally select too many candidates. Under the new systems, voters touch the screen or turn a dial to make their choices and see a confirmation of those choices before casting their votes, which are tallied right in the terminal. Recounts are just a matter of retrieving the data from the computer again. The only record of the vote is what is stored there. Critics of such systems say that they are vulnerable to tampering, to human error and to computer malfunctions -- and that they lack the most obvious protection, a separate, paper receipt that a voter can confirm after voting and that can be recounted if problems are suspected. Officials who have worked with touch-screen systems say these concerns are unfounded and, in certain cases, somewhat paranoid. David Dill, the Stanford University professor of computer science who launched the petition drive, said, "What people have learned repeatedly, the hard way, is that the prudent practice -- if you want to escape with your data intact -- is what other people would perceive as paranoia." Other computer scientists, including Rebecca Mercuri of Bryn Mawr College, say that problems are so likely that they are virtually guaranteed to occur -- and already have. Lost and Found Mercuri, who has studied voting security for more than a decade, points to a November 2000 election in South Brunswick, N.J., in which touch-screen equipment manufactured by Sequoia Voting Systems was used. In a race in which voters could pick two candidates from a pair of Republicans and a pair of Democrats, one machine recorded a vote pattern that was out of sync with the pattern recorded elsewhere -- no votes whatsoever for one Republican and one Democrat. Sequoia said at the time that no votes were lost -- they were just never registered. Local officials said it didn't matter whether the fault was the voters' or the machine's, the expected votes were gone. In October, election officials in Raleigh, N.C., discovered that early voters had to try several times to record their votes on iVotronic touch screens from Election Systems and Software. Told of the problems, officials compared the number of voters to the number of votes counted and realized that 294 votes had apparently been lost. When Georgia debuted 22,000 Diebold touch screens last fall, some people touched one candidate's name on the screen and saw another candidate's name appear as their choice. Voters who were paying attention had a chance to correct the error before finalizing their vote, but those who weren't did not. Chris Rigall, spokesman for the secretary of state's office, said that the machines were quickly replaced, but that there was no way of knowing how many votes were incorrectly counted. In September in Florida, Miami-Dade and Broward counties had a different kind of vote loss with ES&S touch-screen equipment: At the end of the day, precincts that reported hundreds of voters also listed virtually no votes counted. In that case, technicians were able to retrieve the votes from the machines. "If the only way you know that it's working incorrectly is when there's four votes instead of 1,200 votes, then how do you know that if it's 1,100 votes instead of 1,200 votes? You'll never know," said Mercuri. Because humans are imperfect and computers are complicated, said Ben Bederson, a professor of computer science at the University of Maryland, mistakes will always be made. With no backup to test, the scientists say, mistakes will go undetected. "I'm not concerned about elections that are a mess," Dill said. "I'm concerned about elections that appear to go smoothly, and no one knows that it was all messed up inside the machine." "We're not paranoid," said Mercuri. "They're avoiding computational realities. That's the computer science part of it. We can't avoid it any more than physical scientists can avoid gravity." The Miami-Dade and Georgia terminals were reprogrammed right up until the eve of the fall elections. The last-minute patches don't go through sufficient review, Mercuri said, and any computer that can be reprogrammed simply by inserting an update cartridge cannot be considered secure or reliable. Dill said hackers constantly defeat sophisticated protections for electronic transactions, bank records, credit reports and software. "Someone sufficiently unscrupulous, with an investment of $50,000, could put together a team of people who could very easily subvert all of the security mechanisms that we've heard about on these [voting] machines," he said. People who have sold or administered electronic voting systems, however, say the scenarios of fraud or widespread, election-changing error were not of the real world. 'We'd Detect It' Howard Cramer, vice president for sales at Sequoia, one of the nation's largest suppliers of electronic voting systems, noted that his company has been supplying the systems for a decade and a half. "Our existing approach is verifiably accurate, 100 percent," he said. "Some of the things they're saying are flat-out wrong. Some are conceivable, but outside the likelihood of possibility." The designer of Georgia's security system, for example, said nobody could insert a secret program to steal an election when the machines are created, because no one even knows at that time who the candidates will be, and the only people with access to the machines at the last minute are local officials. "They're talking about what they could do if they had access to the [computer program] code, if we had no procedures in place and no physical security in place," said Brit Williams, a computer scientist at Kennesaw State University. "I'm not arguing with that. But they're not going to get access to that code. Even if they did, we'd detect it." He also said that Georgia's patch was checked before it was installed and did not affect the tallying of votes. And no one, he said, could reprogram Georgia's terminals by inserting a cartridge. "On our machine, the port is in a locked compartment. The only person in the precinct who has a key to that locked compartment is the precinct manager. [Critics are] looking at it from a purely computer science point of view, saying the system is vulnerable, and it would be vulnerable if we let anyone walk up and stick a card into it, but that doesn't happen." After Dill launched his campaign, officials in the Silicon Valley county of Santa Clara delayed a purchase of 5,000 touch-screen voting machines. Despite insisting that their systems are reliable and secure, the nation's leading vendors all immediately agreed to provide paper receipts, and the California secretary of state announced a task force to review the security concerns. A month ago, Santa Clara went ahead with its $20 million purchase, insisting that receipts be provided once the state approves the new equipment. Georgia and Maryland officials said that providing paper receipts may create more problems than it solves -- that paper would have to be transported and monitored with security, and printers could jam. Cramer of Sequoia said paper is unnecessary, costly and may pose a problem for blind voters. But if customers want receipts, he said, his company will supply them. And Williams said receipts may have a place in the system. "The advantage of a hard piece of paper -- one that a voter would hold in his hand and say, 'That is who I voted for' -- that is psychological, and there certainly is value to that. We need public confidence in our elections," he said. Similarly, the official overseeing Maryland's program would accept paper if it were available. "I've been doing voting systems for 15 years," Torre said. "I don't care if they give voters a piece of paper or not. If they come out with a receipt, that's fine. Maybe with the momentum out of California, we'll have receipts before too long." ? 2003 The Washington Post Company -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ptrei at rsasecurity.com Fri Mar 28 23:54:41 2003 From: ptrei at rsasecurity.com (Trei, Peter) Date: Fri, 28 Mar 2003 23:54:41 -0500 Subject: Run a remailer, go to jail? Message-ID: Sidney Markowitz writes: >> They both require that the use of such technologies be for >> the purpose of committing a crime. >The Massachusetts law defines as a crime: >(b) Offense defined.--Any person commits an offense if he knowingly >(1) possesses, uses, manufactures, develops, assembles, distributes, >transfers, imports into this state, licenses, leases, sells or offers, >promotes or advertises for sale, use or distribution any communication >device: >[ ... ] or; >(ii) to conceal or to assist another to conceal from any communication >service provider, or from any lawful authority, the existence or place >of origin or destination of any communication; >[...] >(5) Assist others in committing any of the acts prohibited by this >section. To heck with remailers, anonymizing proxies, etal. As I read this, the USPO is liable if it accepts a letter without a correct return address. Peter Trei --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From mab at research.att.com Sat Mar 29 01:48:13 2003 From: mab at research.att.com (Matt Blaze) Date: Sat, 29 Mar 2003 01:48:13 -0500 Subject: How useful is www.crypto.com/exports/mail.txt? Message-ID: <200303290648.h2T6mHX21785@fbi.crypto.com> For the last three years, I've operated a mail alias, "exports at crypto.com", that publicly archives and forwards to the government authorities announcements of the public availability of cryptographic software. The idea was that since current US export regulations require notifying the government any time such software is made available, it might be useful to have a mechanism that lets the rest of us know at the same time. It was started on a whim, at the suggestion of someone on this list, if I recall correctly. The alias forwards messages sent to it to crypt at bis.doc.gov and enc at ncsc.mil and archives the mail at http://www.crypto.com/exports/mail.txt. According to my server logs, that (large) file gets a few hits an hour. As of today, 128 announcements of crypto software availability have been forwarded through it. Lately, the flow of announcement messages has been dwarfed by the bombardment of spam that you'd expect a relatively long-lived, widely-published email address to receive. The alias gets about 100 spam messages a day (I don't keep track any more, I just delete them from the archive every now and then). By contrast, the last message actually announcing crypto software was sent at the beginning of February. Deleting the spam has gotten to be a real chore, and I have a sense that perhaps the alias may have run its course and outlived any useful purpose it may have once served. There are now other ways to advertise open-source software and other archived mailing lists to which messages to the government can be openly cc'd. I'm considering shutting the exports at crypto.com alias down, or perhaps I might leave it up but not maintain the archive web page. Would this be a terrible inconvenience for anyone? Does anyone actually depend on this service at this point? If so, I'll be happy to keep it running, but if not, I think it may be time to pull the plug. -matt m --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From wsimpson at greendragon.com Sat Mar 29 13:31:50 2003 From: wsimpson at greendragon.com (William Allen Simpson) Date: Sat, 29 Mar 2003 13:31:50 -0500 Subject: Run a remailer, go to jail? References: <20030328230626.6830C7B4D@berkshire.research.att.com> Message-ID: <3E85E660.65487FD1@greendragon.com> I've just read Declan's politech article sent out this morning, referencing his full report at: http://news.com.com/2100-1028-994667.html I was shocked to see that Michigan has *already* passed such a law! I've found the new law(s), and they basically outlaw my living in Michigan starting March 31st: http://www.michiganlegislature.org/printDocument.asp?objName=mcl-750-219a-amended&version=txt http://www.michiganlegislature.org/printDocument.asp?objName=mcl-750-540c-amended&version=txt This was passed in a lame duck session (December 11, 2002) as part of a big omnibus crime act that covered everything from "adulteration of butter and cream", to "trick or acrobatic flying" to "false weights and measures", mostly increasing fines and/or jail for existing offenses. Michigan is a leader in overcrowding its prisons. There was other lame duck legislation passed, before a new Governor took office, almost all of it bad for civil liberties! The Bill analysis basically quotes the MPAA website! http://michiganlegislature.org/documents/2001-2002/billanalysis/house/htm/2001-HLA-6079-b.htm "Steven M. Bellovin" wrote: > > The question is more complicated than that. The full text of the Texas > bill is at http://www.capitol.state.tx.us/data/docmodel/78r/billtext/pdf/HB02121I.PDF > (I haven't found the Mass. version). It is far from clear to me that > intent to commit a crime is needed. > > Section 2 of the billl, which does contain the phrase "with the intent to > harm or defraud a communication service", bars theft of service. (I'm > speaking loosely here; read it for yourself.) > > Section 3 and 4 also contain that phrase; they bar possession of devices > for defrauding providers. (The language is rather broad, and seems to > bar possession even a computer or modem if you have evil intent.) > Michigan's version was done by modifying existing statute concerning "cable or satellite television" service providers, and drastically broadening it to "TELECOMMUNICATIONS". Michigan 750.219a outlaws avoiding a communication charge. Period. No defraud. "avoid or attempt to avoid ... by using any of the following: "(a) A telecommunications access device. "(b) An unlawful telecommunications access device. "(c)..." Configuring your ISDN to be a voice device, and then sending data over the device, would be a violation (SBC/Ameritech charges more for data than voice). Most folks around here are willing to settle for 56Kbps + 56Kbps (fixed fee) instead of 64Kbps + 64Kbps (per minute). Configuring a wire pair purchased as a "burglar alarm circuit" (lower fee) and then using it as DSL (avoid high fee) would be a violation. I run an ISP using this technique. Note that the equipment can equally be "a" device, *OR* an "unlawful" device. This was a major change from previous law, which required that the device be (a) stolen or (b) counterfeit. Note that an "unlawful" device would be, among many things listed, a "wireless scanning device". Also, reprogramming or modifying anything. > The ban on concealing origin or destination is in Sections 5 and 6. > That section does *not* have the "intent to harm" phrase. Given that > the bill is amending three consecutive sections of the state penal code > (31.12, 31.13, and 31.14), and given that the first two sections have > that language but the third doesn't, it's hard for me to see that evil > intent is required by the proposed statute. > > But it's worse than that: the bill bars concealment of "existence or > place of origin or destination of any communication" from "any lawful > authority". In other words, it would appear to outlaw many forms of > cryptography or steganography. > In Michigan, 750.540c(1): "(b) Conceal the existence or place of origin or destination of any telecommunications service." Subsection (2) is against programmers. Subsection (3) is against documentation writers. Subsection (4) is "A person who violates subsection (1), (2), or (3) is guilty of a felony punishable by imprisonment for not more than 4 years or a fine of not more than $2,000.00, or both. ... Each unlawful telecommunications access device or telecommunications access device is considered a separate violation. " Writing documentation used by many persons who write programs for many more persons could land me in gaol for a very long time. > What's unclear to me is who is behind this. Felten thinks it's content > providers trying for state-level DMCA; I think it's broadband ISPs who > are afraid of 802.11 hotspots. > Michigan included both. Also, using any device "without the express authority of the telecommunications service provider", which pretty clearly covers NAT. (Some cable companies try to charge per machine, and record the machine address of the devices connected.) Also, reprogramming a device (and software and computer chips are explicitly included) "that is capable of facilitating the interception, transmission, retransmission, decryption, acquisition, or reception of any telecommunications, transmissions, signals, or services" would seem to prohibit mod'ing of M$ Xboxen. Linux/*BSD users reading DVDs (or just about anything else) are outlaws. This is a breathtakingly broad Act. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From jurgen at botz.org Sun Mar 30 17:33:11 2003 From: jurgen at botz.org (Jurgen Botz) Date: Sun, 30 Mar 2003 14:33:11 -0800 Subject: Run a remailer, go to jail? In-Reply-To: <7A08ACBD2F401A4196C29C55B819782A05214CFE@pof0099p06.corp.costco.com> References: <7A08ACBD2F401A4196C29C55B819782A05214CFE@pof0099p06.corp.costco.com> Message-ID: <3E8770A7.5020900@botz.org> > [Moderator's note: is using a NAT box "intent to defraud" a cable > modem provider? --Perry] The cable modem provider and the DSL provider at their consumer service level in my area both have explicit clauses in their AUP prohibiting "sharing" of the connection by multiple machines (I've seen various wordings, some explicitly mentioning NAT, others explicitly mentioning 802.11). So in that case, yes, using NAT would seem to be "intent to defraud." I'm with Steve Bellovin, I think it's the broadband providers who are behind this. But the people saying glibly "good riddance NAT" (it's tempting, I know) are missing the real point here... this is a much greater threat to the end-to-end model of the Internet than NAT ever was. This proposed law would give the broadband provider absolute power over the last mile, letting them separate the edge from the core more than ever before. Because now they'll do it with the force of criminal law. No longer can you ignore their AUPs by just tunneling through a VPN. You'll have to use the pipe exactly the way your provider says you can use it. If you don't they'll cut you off, but if you try to trick them and just hide how you're really using their pipe, by means of NAT, encrypted tunnels, or other outlawed technologies... then they'll send you to jail. :j -- J?rgen Botz | While differing widely in the various jurgen at botz.org | little bits we know, in our infinite | ignorance we are all equal. -Karl Popper --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From reusch at comcast.net Sun Mar 30 19:38:29 2003 From: reusch at comcast.net (reusch) Date: Sun, 30 Mar 2003 19:38:29 -0500 Subject: Russia Intercepts US Military Communications? Message-ID: <3.0.6.32.20030330193829.0096a100@mail.comcast.net> Via the Cryptome, http://www.cryptome.org/, "RU sure", look at http://www.aeronautics.ru/news/news002/news082.htm. I'm amazed at their claims of radio interception. One would expect that all US military communications, even trivial ones, are strongly encrypted, given the ease of doing this. Someone, more well informed, please reassure me that this is the case. Otherwise, yet another thing is very wrong about this war and the infrastructure that supports it. -MFR --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From adam at homeport.org Mon Mar 31 12:51:18 2003 From: adam at homeport.org (Adam Shostack) Date: Mon, 31 Mar 2003 12:51:18 -0500 Subject: Russia Intercepts US Military Communications? In-Reply-To: <3.0.6.32.20030330193829.0096a100@mail.comcast.net> References: <3.0.6.32.20030330193829.0096a100@mail.comcast.net> Message-ID: <20030331175118.GA28084@lightship.internal.homeport.org> On Sun, Mar 30, 2003 at 07:38:29PM -0500, reusch wrote: | Via the Cryptome, http://www.cryptome.org/, "RU sure", look | at http://www.aeronautics.ru/news/news002/news082.htm. | | I'm amazed at their claims of radio interception. One would | expect that all US military communications, even trivial ones, | are strongly encrypted, given the ease of doing this. Someone, | more well informed, please reassure me that this is the case. The ease of doing what? Applying DES with a known key? Key management is hard. Doing key lookups, cert chain management, etc, to NSA level stadards is expensive. Etc. The non-availability of good, cheap, easy to use crypto in a COTS package is the legacy of the ITAR and EAR. That there is a lack of deployed crypto in the US military should be unsuprising. Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From rgb at conscoop.ottawa.on.ca Mon Mar 31 13:06:25 2003 From: rgb at conscoop.ottawa.on.ca (Richard Guy Briggs) Date: Mon, 31 Mar 2003 13:06:25 -0500 Subject: Fw:Fraud & voting machines Message-ID: <20030331130625.A31959@grendel.conscoop.ottawa.on.ca> On the thread of voting machines, matters of trust and fraud come up, never mind bugs and other errors... There are other references on the web which I am sure some of our viewers have seen... http://www.blackboxvoting.com/ http://www.ecotalk.org/VotingSecurity.htm Date: Sat, 1 Feb 2003 19:34:13 -0800 "If You Want To Win An Election, Just Control The Voting Machines" by Thom Hartmann Maybe Nebraska Republican Chuck Hagel honestly won two US Senate elections. Maybe it's true that the citizens of Georgia simply decided that incumbent Democratic Senator Max Cleland, a wildly popular war veteran who lost three limbs in Vietnam, was, as his successful Republican challenger suggested in his campaign ads, too unpatriotic to remain in the Senate. Maybe George W. Bush, Alabama's new Republican governor Bob Riley, and a small but congressionally decisive handful of other long-shot Republican candidates really did win those states where conventional wisdom and straw polls showed them losing in the last few election cycles. Perhaps, after a half-century of fine-tuning exit polling to such a science that it's now sometimes used to verify how clean elections are in Third World countries, it really did suddenly become inaccurate in the United States in the past six years and just won't work here anymore. Perhaps it's just a coincidence that the sudden rise of inaccurate exit polls happened around the same time corporate-programmed, computer-controlled, modem-capable voting machines began recording and tabulating ballots. But if any of this is true, there's not much of a paper trail from the voters' hand to prove it. You'd think in an open democracy that the government - answerable to all its citizens rather than a handful of corporate officers and stockholders - would program, repair, and control the voting machines. You'd think the computers that handle our cherished ballots would be open and their software and programming available for public scrutiny. You'd think there would be a paper trail of the vote, which could be followed and audited if a there was evidence of voting fraud or if exit polls disagreed with computerized vote counts. You'd be wrong. The respected Washington, DC publication The Hill (www.thehill.com/news/012903/hagel.aspx) has confirmed that former conservative radio talk-show host and now Republican U.S. Senator Chuck Hagel was the head of, and continues to own part interest in, the company that owns the company that installed, programmed, and largely ran the voting machines that were used by most of the citizens of Nebraska. Back when Hagel first ran there for the U.S. Senate in 1996, his company's computer-controlled voting machines showed he'd won stunning upsets in both the primaries and the general election. The Washington Post (1/13/1997) said Hagel's "Senate victory against an incumbent Democratic governor was the major Republican upset in the November election." According to Bev Harris of www.blackboxvoting.com, Hagel won virtually every demographic group, including many largely Black communities that had never before voted Republican. Hagel was the first Republican in 24 years to win a Senate seat in Nebraska. Six years later Hagel ran again, this time against Democrat Charlie Matulka in 2002, and won in a landslide. As his hagel.senate.gov website says, Hagel "was re-elected to his second term in the United States Senate on November 5, 2002 with 83% of the vote. That represents the biggest political victory in the history of Nebraska." What Hagel's website fails to disclose is that about 80 percent of those votes were counted by computer-controlled voting machines put in place by the company affiliated with Hagel. Built by that company. Programmed by that company. "This is a big story, bigger than Watergate ever was," said Hagel's Democratic opponent in the 2002 Senate race, Charlie Matulka (www.lancastercountydemocrats.org/matulka.htm). "They say Hagel shocked the world, but he didn't shock me." Is Matulka the sore loser the Hagel campaign paints him as, or is he democracy's proverbial canary in the mineshaft? In Georgia, Democratic incumbent and war-hero Max Cleland was defeated by Saxby Chambliss, who'd avoided service in Vietnam with a "medical deferment" but ran his campaign on the theme that he was more patriotic than Cleland. While many in Georgia expected a big win by Cleland, the computerized voting machines said that Chambliss had won. The BBC summed up Georgia voters' reaction in a 6 November 2002 headline: "GEORGIA UPSET STUNS DEMOCRATS." The BBC echoed the confusion of many Georgia voters when they wrote, "Mr. Cleland - an army veteran who lost three limbs in a grenade explosion during the Vietnam War - had long been considered 'untouchable' on questions of defense and national security." Between them, Hagel and Chambliss' victories sealed Republican control of the Senate. Odds are both won fair and square, the American way, using huge piles of corporate money to carpet-bomb voters with television advertising. But either the appearance or the possibility of impropriety in an election casts a shadow over American democracy. "The right of voting for representatives is the primary right by which all other rights are protected," wrote Thomas Paine over 200 years ago. "To take away this right is to reduce a man to slavery.." That slavery, according to Hagel's last opponent Charlie Matulka, is at our doorstep. "They can take over our country without firing a shot," Matulka said, "just by taking over our election systems." Taking over our election systems? Is that really possible in the USA? Bev Harris of www.talion.com and www.blackboxvoting.com has looked into the situation in depth and thinks Matulka may be on to something. The company tied to Hagel even threatened her with legal action when she went public about his company having built the machines that counted his landslide votes. (Her response was to put the law firm's threat letter on her website and send a press release to 4000 editors, inviting them to check it out. www.blackboxvoting.com/election-systems-software.html) "I suspect they're getting ready to do this all across all the states," Matulka said in a January 30, 2003 interview. "God help us if Bush gets his touch screens all across the country," he added, "because they leave no paper trail. These corporations are taking over America, and they just about have control of our voting machines." In the meantime, exit-polling organizations have quietly gone out of business, and the news arms of the huge multinational corporations that own our networks are suggesting the days of exit polls are over. Virtually none were reported in 2002, creating an odd and unsettling silence that caused unease for the many American voters who had come to view exit polls as proof of the integrity of their election systems. As all this comes to light, many citizens and even a few politicians are wondering if it's a good idea for corporations to be so involved in the guts of our voting systems. The whole idea of a democratic republic was to create a common institution (the government itself) owned by its citizens, answerable to its citizens, and authorized to exist and continue existing solely "by the consent of the governed." Prior to 1886 - when, law schools incorrectly tell law students, the U.S. Supreme Court ruled that corporations are "persons" with equal protection and other "human rights" - it was illegal in most states for corporations to involve themselves in politics at all, much less to service the core mechanism of politics. And during the era of Teddy Roosevelt, who said, "There can be no effective control of corporations while their political activity remains," numerous additional laws were passed to restrain corporations from involvement in politics. Wisconsin, for example, had a law that explicitly stated: "No corporation doing business in this state shall pay or contribute, or offer consent or agree to pay or contribute, directly or indirectly, any money, property, free service of its officers or employees or thing of value to any political party, organization, committee or individual for any political purpose whatsoever, or for the purpose of influencing legislation of any kind, or to promote or defeat the candidacy of any person for nomination, appointment or election to any political office." The penalty for violating that law was dissolution of the corporation, and "any officer, employee, agent or attorney or other representative of any corporation, acting for and in behalf of such corporation" would be subject to "imprisonment in the state prison for a period of not less than one nor more than five years" and a substantial fine. However, the recent political trend has moved us in the opposite direction, with governments answerable to "We, The People" turning over administration of our commons to corporations answerable only to CEOs, boards, and stockholders. The result is the enrichment of corporations and the appearance that democracy in America has started to resemble its parody in banana republics. But if America still is a democratic republic, then We, The People still own our government. And the way our ownership and management of our common government (and its assets) is asserted is through the vote. On most levels, privatization is only a "small sin" against democracy. Turning a nation's or community's water, septic, roadway, prisons, airwaves, or health care commons over to private corporations has so far demonstrably degraded the quality of life for average citizens and enriched a few of the most powerful campaign contributors. But it hasn't been the end of democracy (although some wonder about what the FCC is preparing to do - but that's a separate story). Many citizens believe, however, that turning the programming and maintenance of voting over to private, for-profit corporations, answerable only to their owners, officers, and stockholders, puts democracy itself at peril. And, argues Charlie Matulka, for a former officer of one of those corporations to then place himself into an election without disclosing such an apparent conflict of interest is to create a parody of democracy. Perhaps Matulka's been reading too many conspiracy theory tracts. Or maybe he's on to something. We won't know until a truly independent government agency looks into the matter. When Bev Harris and The Hill's Alexander Bolton pressed the Chief Counsel and Director of the Senate Ethics Committee, the man responsible for ensuring that FEC disclosures are complete, asking him why he'd not questioned Hagel's 1995, 1996, and 2001 failures to disclose the details of his ownership in the company that owned the voting machine company when he ran for the Senate, the Director reportedly met with Hagel's office on Friday, January 25, 2003 and Monday, January 27, 2003. After the second meeting, on the afternoon of January 27th, the Director of the Senate Ethics Committee resigned his job. Meanwhile, back in Nebraska, Charlie Matulka had requested a hand count of the vote in the election he lost to Hagel. He just learned his request was denied because, he said, Nebraska has a just-passed law that prohibits government-employee election workers from looking at the ballots, even in a recount. The only machines permitted to count votes in Nebraska, he said, are those made and programmed by the corporation formerly run by Hagel. Matulka shared his news with me, then sighed loud and long on the phone, as if he were watching his children's future evaporate. "If you want to win the election," he finally said, "just control the machines." Thom Hartmann is the author of "Unequal Protection: The Rise of Corporate Dominance and the Theft of Human Rights." www.unequalprotection.com This article is copyright by Thom Hartmann, but permission is granted for reprint in print, email, or web media so long as this credit is attached. http://www.commondreams.org/views03/0131-01.htm ---------- slainte mhath, RGB -- Richard Guy Briggs -- ~\ Auto-Free Ottawa! Canada -- \@ @ No Internet Wiretapping! -- _\\/\%___\\/\% Vote! -- _______GTVS6#790__(*)_______(*)(*)_______ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ptrei at rsasecurity.com Mon Mar 31 13:07:54 2003 From: ptrei at rsasecurity.com (Trei, Peter) Date: Mon, 31 Mar 2003 13:07:54 -0500 Subject: Russia Intercepts US Military Communications? Message-ID: > reusch[SMTP:reusch at comcast.net] wrote: > > > Via the Cryptome, http://www.cryptome.org/, "RU sure", look > at http://www.aeronautics.ru/news/news002/news082.htm. > > I'm amazed at their claims of radio interception. One would > expect that all US military communications, even trivial ones, > are strongly encrypted, given the ease of doing this. Someone, > more well informed, please reassure me that this is the case. > > Otherwise, yet another thing is very wrong about this war and > the infrastructure that supports it. -MFR ---------------------------- There are a lot of people who don't consider this source credible. After the site was cited on the Interesting People list, the following appeared. I'll leave it up to the reader as to who to believe. Peter From: "Stephen D. Poe" Subject: Venik & iraqwar.ru Follow-Ups To: dave at farber.net Date: Thu, 27 Mar 2003 21:42:48 -0600 Organization: Nautilus Solutions Reply-To: sdpoe at acm.org Dave - There's currently several newsgroup threads discussing iraqwar.ru (see sci.military.naval:"The credibility of Iraqwar.ru or lack thereof" and smn:"Intel evaluation 2003.03.25", in rec.aviation.military:"The Noted Waterhead: Venik" and even in alt.engr.exploisves:"Russian analysis of the ongoing battles in Iraq"). Regarding Venik and his site at http://www.aeronautics.ru; I suggest a few minutes spent on Google will be informative. He's well know to both sci.military.naval and rec.aviation.military posters and lurkers. Historically he's not known for his accuracy. He's probably best known for his heated assertions during the Yugoslavia conflict as to how many planes NATO lost, NATO's "deliberate targeting of civilian targets", and NATO's "use of chemical weapons". His claims of multiple shoot-downs of everything from F-16s to B-2s and B-52s were somewhat quickly quashed given the hobby of tail spotters worldwide. Many of his other claims, such as "A NATO pilot admits that civilian targets were deliberately attacked during the operation "Allied Force" and that NATO aviation used chemical weapons" were likewise not later confirmed. See: http://www.aeronautics.ru/natodown.htm and a Google search for "Venick B-2 Shoot Down" as examples. I would have to view anything with his name associated with it with suspicion. ---------- Archives at: http://www.interesting-people.org/archives/interesting-people/ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From eugen at leitl.org Mon Mar 31 13:16:46 2003 From: eugen at leitl.org (Eugen Leitl) Date: Mon, 31 Mar 2003 20:16:46 +0200 (CEST) Subject: Russia Intercepts US Military Communications? In-Reply-To: <3.0.6.32.20030330193829.0096a100@mail.comcast.net> Message-ID: On Sun, 30 Mar 2003, reusch wrote: > I'm amazed at their claims of radio interception. One would > expect that all US military communications, even trivial ones, Trivial ones are voice radio. Nontrivially to encrypt (mil people tend to be conservative), unlike teletype (I've used NEMP-proof perforated tape, teletypes and electromechanical rotor crypto keyed by a wire plug box in 1988's Bundeswehr). > are strongly encrypted, given the ease of doing this. Someone, > more well informed, please reassure me that this is the case. While there's no doubt comm is being intercepted the www.aeronautics.ru main analyst (forgot his name) is purported to be not very credible. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From rsalz at datapower.com Mon Mar 31 13:13:09 2003 From: rsalz at datapower.com (Rich Salz) Date: Mon, 31 Mar 2003 13:13:09 -0500 Subject: How useful is www.crypto.com/exports/mail.txt? In-Reply-To: <200303290648.h2T6mHX21785@fbi.crypto.com> References: <200303290648.h2T6mHX21785@fbi.crypto.com> Message-ID: <3E888535.3050906@datapower.com> > For the last three years, I've operated a mail alias, > "exports at crypto.com" ... It was > started on a whim, at the suggestion of someone on this > list, if I recall correctly. That was me. I think the openssl folks mention it and use it, so sending your posting there is good idea. Thanks for all the years of service! /r$ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From pcw2 at flyzone.com Mon Mar 31 13:17:43 2003 From: pcw2 at flyzone.com (Peter Wayner) Date: Mon, 31 Mar 2003 13:17:43 -0500 Subject: Russia Intercepts US Military Communications? In-Reply-To: <3.0.6.32.20030330193829.0096a100@mail.comcast.net> References: <3.0.6.32.20030330193829.0096a100@mail.comcast.net> Message-ID: At 7:38 PM -0500 3/30/03, reusch wrote: >Via the Cryptome, http://www.cryptome.org/, "RU sure", look >at http://www.aeronautics.ru/news/news002/news082.htm. I showed this link to a friend who fixes helicopters for the Army/Marines. He was incredulous at first, but then said, "Oh, they probably just turned off the crypto. There's a switch to do that. Sometimes you have to do that if things screw up." He went on to talk about "crypto" as if it was something like fuel or food. He said, "They probably loaded up 4 or 5 days of crypto at the beginning, but then they had to turn it off after the supply lines got muddled." So this would be consistent with some key management structures but not with others. If you give a unit a good random number source and diffie-hellman, they should be able to go the entire war without running out of "crypto." But I don't know if the US military embraces the kind of hierarchy-free key management imagined by cypherpunks. Of course, many of the details from the Russian could be gathered from raw traffic analysis. It's easy to count messages and triangulate to figure out where US troops are massing. It's also easy to tell that an absence of messages from the interior of the city means that the US troops haven't entered yet. The crypto may cloak the details of the messages, but those details may not be too important. (I wouldn't be surprised if they carried some news of the NCAA basketball tournament, for instance.) -Peter --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From lrkn at earthlink.net Mon Mar 31 13:20:22 2003 From: lrkn at earthlink.net ((Mr) Lyn R. Kennedy) Date: Mon, 31 Mar 2003 12:20:22 -0600 Subject: Russia Intercepts US Military Communications? In-Reply-To: <3.0.6.32.20030330193829.0096a100@mail.comcast.net> References: <3.0.6.32.20030330193829.0096a100@mail.comcast.net> Message-ID: <20030331182022.GE243@workstn.my.domain> On Sun, Mar 30, 2003 at 07:38:29PM -0500, reusch wrote: > > I'm amazed at their claims of radio interception. One would > expect that all US military communications, even trivial ones, > are strongly encrypted, given the ease of doing this. Someone, > more well informed, please reassure me that this is the case. It's not the case. I routinely listen in on communications. Most of the planes have either KY-57 or Have Quick. The KY is digital and probably better than DES encryption. Adequate except for stupidly using AM (Amplidude Modulation, aka ancient modulation) which along with poor maintenance makes it often unusable. Have Quick is actually anti-jam and often mistaken for encryption. Likely the Russians can read it. The real problem is that flaky encrypted comms are a tactical problem so it is often better to use clear comms when time is the issue. Not too helpful to know what's about to happen if you can't do anything about it anyway. > Otherwise, yet another thing is very wrong about this war and > the infrastructure that supports it. -MFR It's amazing to me to listen to engineers try a test 15 times and then when it finally works, declare victory and go on to the next one. The military industrial complex is about money, not reliable high-tech systems. I was more impressed with American expertise 40 years ago than I am now. -- ------------------------------------------------------------------------- | 73, E-mail | lrkn at earthlink.net | | Lyn Kennedy webpage | http://home.earthlink.net/~lrkn | | K5QWB ICBM | 32.5 North 96.9 West | ---Livin' on an information dirt road a few miles off the superhighway--- --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From cox-work at djehuti.com Mon Mar 31 13:31:53 2003 From: cox-work at djehuti.com (Ben Cox) Date: 31 Mar 2003 13:31:53 -0500 Subject: Run a remailer, go to jail? In-Reply-To: <3E8770A7.5020900@botz.org> References: <7A08ACBD2F401A4196C29C55B819782A05214CFE@pof0099p06.corp.costco.com> <3E8770A7.5020900@botz.org> Message-ID: <1049135513.8377.20.camel@cox-pc.spinnakernet.com> On Sun, 2003-03-30 at 17:33, Jurgen Botz wrote: > > [Moderator's note: is using a NAT box "intent to defraud" a cable > > modem provider? --Perry] > > The cable modem provider and the DSL provider at their consumer > service level in my area both have explicit clauses in their AUP > prohibiting "sharing" of the connection by multiple machines > (I've seen various wordings, some explicitly mentioning NAT, > others explicitly mentioning 802.11). I seem to remember Verizon running DSL TV ads a while back for an equipment and installation deal that included a low-end NAT router. At least in my area (Pittsburgh), they really don't seem to care how many machines I have behind the router in my house. Indeed, when Verizon DSL switched me from a static IP to a PPPoE connection last week (without telling me; gee thanks), and I called their tech support line to find out why my connection was down, the first question the tech asked was whether I was using a router. I said yes, and he gave me the PPPoE info I needed to configure my router while he waited on the line. The only concern he seemed to have about the router was pure personal curiosity as to what model it was. -- Ben --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From rah at shipwright.com Mon Mar 31 10:49:05 2003 From: rah at shipwright.com (R. A. Hettinga) Date: Mon, 31 Mar 2003 10:49:05 -0500 Subject: GPS phones confiscated from reporters in Iraq Message-ID: http://www.newscientist.com/news/print.jsp?id=ns99993567 New Scientist GPS phones confiscated from reporters in Iraq 15:26 31 March 03 Will Knight Satellite phones with built-in Global Positioning System (GPS) capabilities have been confiscated from journalists travelling with US troops inside Iraq, due to fears that they could inadvertently reveal their positions. Reporters "embedded" with the troops have been asked to hand over satellite telephones operated by Thuraya Satellite Telecommunications, a communications company based in Abu Dhabi. The restriction is limited to units near the war's front-line and is expected to be temporary, a spokesman for US central command in Qatar told New Scientist . A spokeswoman for the US Department of Defense added that reporters with unaffected satellite phones would be asked to share them and that military communications equipment would be made available when possible. Replacement phones could also be sent to the front line. Richard Langley, a GPS expert at the University of New Brunswick, Canada, says US military commanders may be concerned that positioning information embedded in signals sent by the Thuraya phones could be intercepted and used by Iraqi forces to locate and attack US troops. "It's not impossible, although it would be rather difficult," Langley told New Scientist . "The signals are line-of-sight [from handset to satellite] so very little would leak out and be interceptable on the ground." Ground station intercept It would be easier to intercept the signal as it arrives from the satellite at the network operator's ground station, he says. But even in this case, any interceptor would still have to crack the encryption protecting the signal. An alternative concern is that the US military are worried that computers used to store call information are vulnerable to cyber attack. "Perhaps the concern was that there would be a log of these positions kept on a computer somewhere," Langley says. Positional information captured by any means would only be useful for as long as the caller remained in the same place, he notes: "Anyone wanting to use the information would have to work quickly." Thuraya telephones can connect to GSM mobile phone networks when they are available, and a satellite network when in more remote areas. The phones can also be used as a GPS receiver, determining its position by communicating with satellites in the GPS constellation. If the GPS functionality is switched on, the caller's co-ordinates are automatically embedded in the voice signal sent to the communications satellites. -- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From gnu at toad.com Mon Mar 31 13:44:35 2003 From: gnu at toad.com (John Gilmore) Date: Mon, 31 Mar 2003 10:44:35 -0800 Subject: Russia Intercepts US Military Communications? In-Reply-To: <20030331175118.GA28084@lightship.internal.homeport.org> Message-ID: <200303311844.h2VIiZdd021188@new.toad.com> > I'm amazed at their claims of radio interception. 1. "Look for plaintext." This was rule #1 stated by Robert Morris Sr. in his lecture to the annual Crypto conference after retiring as NSA's chief scientist. You'd be amazed how much of it is floating around out there, even in military communications. 2. Wars are great opportunities to learn what other folks are doing for communications security. Whether or not you are a belligerant in the war, you clearly want to be focusing your interception capabilities on that battlefield and its supply and command trails. Besides operational errors made under stress, which can compromise whole systems, you just learn what works and what doesn't work among the fielded systems. And what works or not in your own interception facilities. Wars are much better than sending probe jets a few miles into an opponent's territory, to show you how their electronics work. > One would > expect that all US military communications, even trivial ones, > are strongly encrypted, given the ease of doing this. Given the ease of writing strong encryption applications, I'm amazed that civilian communications are seldom -- very seldom -- encrypted. Deployment and interoperability without introducing major vulnerabilities is much harder than just designing algorithms and writing code. It involves changing peoples' habits, patterns, and practices. Remember, the cypherpunks cracked Clipper and DES, deployed the world's most widely used email encryption, secured any Web traffic that chooses to be secure, built a lot of the most popular network encryption. We beat back NSA's controlling hand, and encouraged a global spread of encryption expertise. We secured most of the Internet's control traffic (using ssh - thanks Tatu) to make it harder to break into the infrastructure. We're the A-team. But our cellphones are still trivial to track and intercept; the vast majority of email, web, and IM traffic is totally unencrypted; ordinary phone calls are totally wiretap prone; our own new technologies like 802.11 have no decent encryption and no likelihood of a real fix that works everywhere by default; we know the government IS TODAY wiretapping tons of innocents in a feeding frenzy of corruption; the US government has mandated Stasi-like wiretap capabilities in every form of new communication (even where the law gives them no power, they arrogate it and largely succeed); the wiretappers have largely built an international consensus of cops to track and wiretap anybody anywhere; practical anonymity has significantly shrunken in the last decade; and even more traffic is moving onto wireless where legal or illegal interception is undetectable. We still fight endless intra-community battles that delay or derail deployment of existing encryption. The most widespread large-scale hard-to-crack systems are being deployed AGAINST the public interest -- by the copyright mafia. If *we*, the victors in the crypto wars, couldn't get decent encryption deployed, even among ourselves, why would you expect that a government bureacracy could do it among itself and its clients? John --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From reusch at comcast.net Mon Mar 31 14:10:20 2003 From: reusch at comcast.net (reusch) Date: Mon, 31 Mar 2003 14:10:20 -0500 Subject: Russia Intercepts US Military Communications? In-Reply-To: <20030331175118.GA28084@lightship.internal.homeport.org> References: <3.0.6.32.20030330193829.0096a100@mail.comcast.net> <3.0.6.32.20030330193829.0096a100@mail.comcast.net> Message-ID: <3.0.6.32.20030331141020.0096ee10@mail.comcast.net> At 12:51 PM 3/31/03 -0500, Adam Shostack wrote: >On Sun, Mar 30, 2003 at 07:38:29PM -0500, reusch wrote: >| Via the Cryptome, http://www.cryptome.org/, "RU sure", look >| at http://www.aeronautics.ru/news/news002/news082.htm. >| >| I'm amazed at their claims of radio interception. One would >| expect that all US military communications, even trivial ones, >| are strongly encrypted, given the ease of doing this. Someone, >| more well informed, please reassure me that this is the case. > >The ease of doing what? Applying DES with a known key? Key >management is hard. Doing key lookups, cert chain management, etc, to >NSA level stadards is expensive. Etc. > >The non-availability of good, cheap, easy to use crypto in a COTS >package is the legacy of the ITAR and EAR. That there is a lack of >deployed crypto in the US military should be unsuprising. > >Adam > > >-- >"It is seldom that liberty of any kind is lost all at once." > -Hume Nosing around on the same site, one finds "How military radio communications are intercepted" http://www.aeronautics.ru/news/news002/news071.htm Searching for SINCGARS indicates that all US military radios have encryption capabilities, which can be turned off. Several, in use, key distribution systems are mentioned. Perhaps these systems or even encryption, with infrequently changed keys are, as you suggest, too inconvenient to use under the conditions. -MFR --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From Chazzchezz at aol.com Mon Mar 31 14:59:11 2003 From: Chazzchezz at aol.com (Chazzchezz at aol.com) Date: Mon, 31 Mar 2003 14:59:11 -0500 Subject: Russia Intercepts US Military Communications? Message-ID: <20DE149F.46E77ED4.0AD05FA4@aol.com> lrkn at earthlink.net writes: The real problem is that flaky encrypted comms are a tactical problem so it is often better to use clear comms when time is the issue. Not too helpful to know what's about to happen if you can't do anything about it anyway. ---------------------------------- This is a very important point! I am sure that most of what is being intercepted is tactical voice, and has very limited shelf-life. I am much more concerned about the apparent lack of good IFF (missile batteries lighting up the RAF plane that they then shot down; the USAF plane that reacted to being lit up by firing at and destroying the ground radar; stories about our close air-support firing on our tanks and other ground units)! This sounds like it is very close to criminal negligence! Do these units NOT have IFF or are they not using it or does it just not work all of the time ? Geraldo wants to know!! - chazzchezz --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From gnu at toad.com Mon Mar 31 15:13:49 2003 From: gnu at toad.com (John Gilmore) Date: Mon, 31 Mar 2003 12:13:49 -0800 Subject: GPS phones confiscated from reporters in Iraq In-Reply-To: Message-ID: <200303312013.h2VKDndd022012@new.toad.com> > http://www.newscientist.com/news/print.jsp?id=ns99993567 It's nice to see that the US military realizes the terrible possibilities from tracking the movements of ordinary people (who happen to be soldiers or with soldiers). When will they get on the bandwagon demanding that person-tracking phones be banned -- rather than required -- by the FCC? John --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From adam at homeport.org Mon Mar 31 15:56:39 2003 From: adam at homeport.org (Adam Shostack) Date: Mon, 31 Mar 2003 15:56:39 -0500 Subject: Russia Intercepts US Military Communications? In-Reply-To: References: <3.0.6.32.20030330193829.0096a100@mail.comcast.net> Message-ID: <20030331205638.GA31414@lightship.internal.homeport.org> On Mon, Mar 31, 2003 at 01:17:43PM -0500, Peter Wayner wrote: | He went on to talk about "crypto" as if it was something like fuel or | food. He said, "They probably loaded up 4 or 5 days of crypto at the | beginning, but then they had to turn it off after the supply lines | got muddled." | | So this would be consistent with some key management structures but | not with others. If you give a unit a good random number source and | diffie-hellman, they should be able to go the entire war without | running out of "crypto." But I don't know if the US military embraces | the kind of hierarchy-free key management imagined by cypherpunks. Heh. They certainly tend not to. And really, when you have a hierarchy, you may not even want to. The ease of jumping into an encrypted net with a MITM attack would be pretty scary, or everyone needs copies of a few dozen to thousands of authentication keys, which is going to be tricky. (Of course, if they just put the crypto on smartcards, or key fobs, you could likely carry a month or three worth of crypto with you, but then they wouldn't know what had happened to every key out there. Clearly, its better to have unencrypted comms where you know they're insecure, rather than low assurance secure comms. For some threat models that I disagree with, anyway. Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From DaveHowe at gmx.co.uk Mon Mar 31 16:04:49 2003 From: DaveHowe at gmx.co.uk (Dave Howe) Date: Mon, 31 Mar 2003 22:04:49 +0100 Subject: Russia Intercepts US Military Communications? References: <3.0.6.32.20030330193829.0096a100@mail.comcast.net> Message-ID: <006b01c2f7c9$2cd15a40$01c8a8c0@DaveHowe> reusch wrote: > Via the Cryptome, http://www.cryptome.org/, "RU sure", look > at http://www.aeronautics.ru/news/news002/news082.htm. > I'm amazed at their claims of radio interception. One would > expect that all US military communications, even trivial ones, > are strongly encrypted, given the ease of doing this. Someone, > more well informed, please reassure me that this is the case. Possibly someone was bribable - presumably the CoW need to share the same frequencies and keys, so.... --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From ekr at rtfm.com Mon Mar 31 16:41:31 2003 From: ekr at rtfm.com (Eric Rescorla) Date: 31 Mar 2003 13:41:31 -0800 Subject: Russia Intercepts US Military Communications? In-Reply-To: <200303311844.h2VIiZdd021188@new.toad.com> References: <200303311844.h2VIiZdd021188@new.toad.com> Message-ID: John Gilmore writes: > Remember, the cypherpunks ... secured any Web traffic Credit where it's due. Netscape was responsible for this. -Ekr -- [Eric Rescorla ekr at rtfm.com] http://www.rtfm.com/ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From daw at mozart.cs.berkeley.edu Mon Mar 31 16:26:41 2003 From: daw at mozart.cs.berkeley.edu (David Wagner) Date: 31 Mar 2003 21:26:41 GMT Subject: Fw:Fraud & voting machines References: <20030331130625.A31959@grendel.conscoop.ottawa.on.ca> Message-ID: Richard Guy Briggs wrote: >"If You Want To Win An Election, Just Control The Voting Machines" >by Thom Hartmann [...] >Six years later Hagel ran again, this time against Democrat Charlie Matulka >in 2002, and won in a landslide. As his hagel.senate.gov website says, Hagel >"was re-elected to his second term in the United States Senate on November >5, 2002 with 83% of the vote. That represents the biggest political victory >in the history of Nebraska." > >What Hagel's website fails to disclose is that about 80 percent of those >votes were counted by computer-controlled voting machines put in place by >the company affiliated with Hagel. Built by that company. Programmed by that >company. Breathless speculation aside, it oughtn't be that hard to test whether Hagel's victory was credible. Surely there were some polls of the voters. You would think that if there was significant fraud through compromised voting machines, then this fact would be very noticeable in the polls. Does anyone know whether there is any evidence to back up these allegations that Hagel's election results were fraudulent, or is this article just blowing smoke? I agree that we ought to take voting fraud seriously, and I'm very critical of e-voting. However, we also ought to get the facts, all the facts, and to get them right. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From lrkn at earthlink.net Mon Mar 31 17:21:37 2003 From: lrkn at earthlink.net ((Mr) Lyn R. Kennedy) Date: Mon, 31 Mar 2003 16:21:37 -0600 Subject: Russia Intercepts US Military Communications? In-Reply-To: <20DE149F.46E77ED4.0AD05FA4@aol.com> References: <20DE149F.46E77ED4.0AD05FA4@aol.com> Message-ID: <20030331222137.GF243@workstn.my.domain> On Mon, Mar 31, 2003 at 02:59:11PM -0500, Chazzchezz at aol.com wrote: > > I am much more concerned about the > apparent lack of good IFF (missile batteries lighting up > the RAF plane that they then shot down; the USAF plane that > reacted to being lit up by firing at and destroying the > ground radar; stories about our close air-support firing > on our tanks and other ground units)! This sounds like it > is very close to criminal negligence! Do these units NOT > have IFF or are they not using it or does it just not work > all of the time ? Geraldo wants to know!! - chazzchezz IFF is no longer limited to 6x8-foot Union Jacks flown by British vehicles but it's obvious there are still problems. Considering how much effort I know about in the last ten years, one would think they have every plane, vehicle, and ship tagged with something. My father fought WWII in Dallas, installing IFF in airplanes. Plenty of time to perfect these concepts. One needs to keep in mind that the problem is often simple failure to communicate. The Combat Air Patrols over the US in the last year give some insight: Fighters in Texas taking direction from Florida rather than talking to the Air Traffic Controllers below. I listen to private pilots near Dubya's ranch complaining about being "attacked" by F-16s while following directions from ATC. The F-16s chase scheduled airliners into Waco. Perhaps they don't have weapons and that is all that has saved planes from being shot down in Texas. -- ------------------------------------------------------------------------- | 73, E-mail | lrkn at earthlink.net | | Lyn Kennedy webpage | http://home.earthlink.net/~lrkn | | K5QWB ICBM | 32.5 North 96.9 West | ---Livin' on an information dirt road a few miles off the superhighway--- --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From reinhold at world.std.com Mon Mar 31 17:46:44 2003 From: reinhold at world.std.com (Arnold G. Reinhold) Date: Mon, 31 Mar 2003 17:46:44 -0500 Subject: Russia Intercepts US Military Communications? In-Reply-To: <3.0.6.32.20030331141020.0096ee10@mail.comcast.net> References: <3.0.6.32.20030330193829.0096a100@mail.comcast.net> <3.0.6.32.20030330193829.0096a100@mail.comcast.net> <3.0.6.32.20030331141020.0096ee10@mail.comcast.net> Message-ID: >At 2:10 PM -0500 3/31/03, reusch wrote: ... > >Nosing around on the same site, one finds >"How military radio communications are intercepted" >http://www.aeronautics.ru/news/news002/news071.htm > >Searching for SINCGARS indicates that all US military radios have >encryption capabilities, which can be turned off. Several, in use, >key distribution systems are mentioned. Perhaps these systems or even >encryption, with infrequently changed keys are, as you suggest, too >inconvenient to use under the conditions. -MFR > There is a lot of material on SINCGARS available on line via Google. This is a low-VHF system used primarily by U.S. ground forces and those who want to talk to them. It offers both frequency hopping and Type-1 encryption (at least the newer models) and can also be used in single channel, unsecured mode to talk to older VHF-FM radios. According to one source, about 164,000 SINCGARS radios have been fielded and all older VRC-12 radios should have been replaced by 2001. The key management systems (nightmare may be a better term) are described in considerable detail in http://www.fas.org/man/dod-101/sys/land/sincgars.htm . It's from 1996 and makes very interesting reading. For example, radios have to have their time set to within 0.4 sec of GMT. It's easy to believe that units switch to un-encrypted modes under the stress of battle. Even tho the radios seem quite versatile, the usage is extremely hierarchical. News reports have stated that one advance in this war is that the daily "tasking order" can now be distributed electronically. This probably includes all the material needed to set up the SINCGARS (frequency hop list, frequency hopping keys, communications security keys, call sign lists, network IDs, etc.). That may make things a little better than in 1996. I went to a lecture at MIT by someone for the US Army talking about the "soldier of the future," an integrated body armor/backpack/electronics system. I asked about encryption and he said it was Army doctrine not to use it at the intra-squad level. Key management is one of the issues. That is consistent with the number of SINCGARs radios produced. So there should be plenty of open voice traffic to analyze. Arnold Reinhold --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From reinhold at world.std.com Mon Mar 31 17:50:35 2003 From: reinhold at world.std.com (Arnold G. Reinhold) Date: Mon, 31 Mar 2003 17:50:35 -0500 Subject: Kashmir crypto Message-ID: While Googling for material on SINCGARS, I found an article about crypto in the India/Pakistan conflict. Old style cryptanalysis isn't dead yet: http://www.tactical-link.com/india_pakistan.htm Arnold Reinhold --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From shamrock at cypherpunks.to Mon Mar 31 18:30:27 2003 From: shamrock at cypherpunks.to (Lucky Green) Date: Tue, 1 Apr 2003 01:30:27 +0200 (CEST) Subject: Russia Intercepts US Military Communications? Message-ID: <20030401012839.A79329@pakastelohi.cypherpunks.to> Eric Rescorla wrote: > Sent: Monday, March 31, 2003 23:42 > To: John Gilmore > Cc: cryptography at wasabisystems.com; gnu at new.toad.com > Subject: Re: Russia Intercepts US Military Communications? > > > John Gilmore writes: > > Remember, the cypherpunks ... secured any Web traffic > Credit where it's due. Netscape was responsible for this. Just for the record, SSLv1 first saw significant review, if it was not first posted to, the Cypherpunks mailing list. Those who participated in the list at the time may remember Mark Andreessen, a Cypherpunks newbie in those days, proudly posting his new crypto protocol. The protocol received the customary reception security protocols designed by crypto newbies tend to receive: it was torn to shreds immediately. SSLv2 rapidly superceded SSLv1. SSLv2 in turn was implemented throughout Netscape's products by the Weinstein brothers, which during those days were very active participants in both the Cypherpunks mailing list and Cypherpunks meetings. --Lucky Green --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From dave at netmedic.net Mon Mar 31 20:42:38 2003 From: dave at netmedic.net (dave) Date: Mon, 31 Mar 2003 20:42:38 -0500 Subject: Russia Intercepts US Military Communications? In-Reply-To: Message-ID: Well I am sure most of you would be amazed and/or flabbergasted with how the "crypto" keys are handed out for the different avionics/communication devices on a daily basis. You will know if you forgot one of them like when you pass over a hawk missile sight at the edge of base, and they lock on and start tracking you. Notice I said "daily" basis. Might give a hint to how they "ran out". Dave _____________________ Dave Kleiman dave at netmedic.net www.netmedic.net -----Original Message----- From: owner-cryptography at wasabisystems.com [mailto:owner-cryptography at wasabisystems.com] On Behalf Of Peter Wayner Sent: Monday, March 31, 2003 13:18 To: reusch; cryptography at wasabisystems.com Subject: Re: Russia Intercepts US Military Communications? At 7:38 PM -0500 3/30/03, reusch wrote: >Via the Cryptome, http://www.cryptome.org/, "RU sure", look >at http://www.aeronautics.ru/news/news002/news082.htm. I showed this link to a friend who fixes helicopters for the Army/Marines. He was incredulous at first, but then said, "Oh, they probably just turned off the crypto. There's a switch to do that. Sometimes you have to do that if things screw up." He went on to talk about "crypto" as if it was something like fuel or food. He said, "They probably loaded up 4 or 5 days of crypto at the beginning, but then they had to turn it off after the supply lines got muddled." So this would be consistent with some key management structures but not with others. If you give a unit a good random number source and diffie-hellman, they should be able to go the entire war without running out of "crypto." But I don't know if the US military embraces the kind of hierarchy-free key management imagined by cypherpunks. Of course, many of the details from the Russian could be gathered from raw traffic analysis. It's easy to count messages and triangulate to figure out where US troops are massing. It's also easy to tell that an absence of messages from the interior of the city means that the US troops haven't entered yet. The crypto may cloak the details of the messages, but those details may not be too important. (I wouldn't be surprised if they carried some news of the NCAA basketball tournament, for instance.) -Peter --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From dave at netmedic.net Mon Mar 31 21:09:18 2003 From: dave at netmedic.net (dave) Date: Mon, 31 Mar 2003 21:09:18 -0500 Subject: Run a remailer, go to jail? In-Reply-To: Message-ID: "to conceal or to assist another to conceal from any communication service provider, or from any lawful authority, the existence or place of """origin""" or """destination"""" of any communication. I agree with Peter. Now what are they going to with all that Postal mail without return addresses? Who is liable if you receive it? The Post Office? Will FedEx now require an ID before sending packages? Little electronic "ATM" like card readers for your ID card at the drop boxes and US mail boxes? If you send it electronically through your ISP and they let it get by, are they now liable if the receiver of the e-mail reports it. They did "assist another to conceal". Did they not? If you live in Mass but your ISP is in NY does the law apply? I am thinking if this is one of those laws passes because of ignorant voters and politicians. It will: A) Make a lot of attorneys rich. B) Get torn apart by case law, after making said attorneys rich. But that is just my opinion :) Dave _____________________ Dave Kleiman dave at netmedic.net www.netmedic.net -----Original Message----- From: owner-cryptography at wasabisystems.com [mailto:owner-cryptography at wasabisystems.com] On Behalf Of Trei, Peter Sent: Friday, March 28, 2003 23:55 To: 'Sidney Markowitz '; 'cryptography at wasabisystems.com ' Subject: RE: Run a remailer, go to jail? Sidney Markowitz writes: >> They both require that the use of such technologies be for >> the purpose of committing a crime. >The Massachusetts law defines as a crime: >(b) Offense defined.--Any person commits an offense if he knowingly >(1) possesses, uses, manufactures, develops, assembles, distributes, >transfers, imports into this state, licenses, leases, sells or offers, >promotes or advertises for sale, use or distribution any communication >device: >[ ... ] or; >(ii) to conceal or to assist another to conceal from any communication >service provider, or from any lawful authority, the existence or place >of origin or destination of any communication; >[...] >(5) Assist others in committing any of the acts prohibited by this >section. To heck with remailers, anonymizing proxies, etal. As I read this, the USPO is liable if it accepts a letter without a correct return address. Peter Trei --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From die at die.com Mon Mar 31 21:27:20 2003 From: die at die.com (Dave Emery) Date: Mon, 31 Mar 2003 21:27:20 -0500 Subject: Run a remailer, go to jail? In-Reply-To: <87k7ejmken.fsf@snark.piermont.com> References: <87k7ejmken.fsf@snark.piermont.com> Message-ID: <20030401022719.GO13933@pig.die.com> On Fri, Mar 28, 2003 at 01:10:56PM -0500, Perry E. Metzger wrote: > > http://www.freedom-to-tinker.com/archives/000336.html > > Quoting: > > Here is one example of the far-reaching harmful effects of > these bills. Both bills would flatly ban the possession, sale, > or use of technologies that "conceal from a communication > service provider ... the existence or place of origin or > destination of any communication". > > -- > Perry E. Metzger perry at piermont.com > I find another thread of concern to some of us who are hams and radio and satellite TVRO hobbyists. Quoting from the Mass version of the bill... (b) Offense defined.--Any person commits an offense if he knowingly: (1) possesses, uses, manufactures, develops, assembles, distributes, transfers, imports into this state, licenses, leases, sells or offers, promotes or advertises for sale, use or distribution any communication device: (i) for the commission of a theft of a communication service or to receive, intercept, disrupt, transmit, re-transmits, decrypt, acquire or  facilitate the receipt, interception, disruption, transmission,  re-transmission, decryption or acquisition of any communication service without the express consent or express authorization of the  communication service provider; or (2) "Communication service. " Any service lawfully provided for a charge or compensation to facilitate the lawful origination, transmission, emission or reception of signs, signals, data, writings, images and sounds or intelligence of any nature by telephone, including cellular or other wireless telephones, wire, wireless, radio, electromagnetic, photoelectronic or photo- optical systems, networks or facilities; and any service lawfully provided by any radio, telephone, fiber optic, photo-optical, electromagnetic, photoelectric, cable television, satellite, microwave, data transmission, wireless or Internet-based distribution system, network or facility, including, but not limited to, any and all electronic, data, video, audio, Internet access, telephonic, microwave and radio communications, transmissions, signals and services, and any such communications, transmissions, signals and services ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ lawfully provided directly or indirectly by or through any of the aforementioned systems, networks or facilities. ------- end of quote -------- Whilst I am no lawyer, this would seem to possibly render illegal radio and satellite TV receivers that could be used or are used to lawfully receive those radio communications the public is explicitly permitted to listen to under the ECPA (18 USC 2510 and 2511) if the originator of the communication does not provide explicit permission to listen and the transmission involves use of facilities for which a fee is paid (such as space on a leased tower). Included in this category are unencrypted public safety communications such as police and fire calls, aircraft, ships, trains and the like all of which can be picked up on the ubiquitous police scanners (and more sophisticated radios that some of us own as well). And obtaining explicit permission from all the parties involved in such communications is not always easy, nor in many cases do local agencies want to grant it. And also much more likely to be included under the rubric of at at least this very broad Mass language are unencrypted non-scrambled back hauls, news feeds, and free to air MPFG and analog services available from TVRO satellite dishes. These are pretty clearly communications services and watching them in the privacy of one's home for private non-commercial purposes has been legal under the provisions of the late 80s Satellite Viewers Rights Act (provided they weren't scrambled). Of course compared to the larger issues raised by the DMCA language and the apparent prohibition of NAT and anonymous mailers this may seem minor... But it is worrisome to some of us working on software defined radio code in Mass... which might or could be used in ways that might be found illegal under this bill. -- Dave Emery N1PRE, die at die.com DIE Consulting, Weston, Mass 02493 PGP fingerprint 1024D/8074C7AB 094B E58B 4F74 00C2 D8A6 B987 FB7D F8BA 8074 C7AB --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From frantz at pwpconsult.com Mon Mar 31 21:31:56 2003 From: frantz at pwpconsult.com (Bill Frantz) Date: Mon, 31 Mar 2003 18:31:56 -0800 Subject: Run a remailer, go to jail? In-Reply-To: References: Message-ID: At 6:09 PM -0800 3/31/03, dave wrote: >"to conceal or to assist another to conceal from any communication >service provider, or from any lawful authority, the existence or place >of """origin""" or """destination"""" of any communication. However, this provision shouldn't interfere with NAT on a home network. All the machines are at the same address, the origin of the communication. (The actual source of email communication is the keyboard processor, not the computer with the IP address and email client.) OTOH, the sections dealing with "theft of service" may apply. Moral is to get your service from a provider that allows NAT. Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | Due process for all | Periwinkle -- Consulting (408)356-8506 | used to be the | 16345 Englewood Ave. frantz at pwpconsult.com | American way. | Los Gatos, CA 95032, USA --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com From die at die.com Mon Mar 31 23:17:42 2003 From: die at die.com (Dave Emery) Date: Mon, 31 Mar 2003 23:17:42 -0500 Subject: Run a remailer, go to jail? In-Reply-To: <87k7ejmken.fsf@snark.piermont.com> References: <87k7ejmken.fsf@snark.piermont.com> Message-ID: <20030401041741.GS13933@pig.die.com> On Fri, Mar 28, 2003 at 01:10:56PM -0500, Perry E. Metzger wrote: > > http://www.freedom-to-tinker.com/archives/000336.html > > Quoting: > > Here is one example of the far-reaching harmful effects of > these bills. Both bills would flatly ban the possession, sale, > or use of technologies that "conceal from a communication > service provider ... the existence or place of origin or > destination of any communication". > > -- > Perry E. Metzger perry at piermont.com For those on this list in the Boston area there is a hearing scheduled on the Mass Bill at 10 Am in Room 222 of the Mass State House in Boston. It was introduced in Mass by a Rep Stephen Tobin of Boston and listed on the state website as "legislation to establish a crime of illegal internet and broadband access" -- Dave Emery N1PRE, die at die.com DIE Consulting, Weston, Mass 02493 PGP fingerprint 1024D/8074C7AB 094B E58B 4F74 00C2 D8A6 B987 FB7D F8BA 8074 C7AB --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com