Re: dual-use digital signature [EMAIL PROTECTED]
Anne Lynn Wheeler [EMAIL PROTECTED] write: the assertion here is possible threat model confusion when the same exact technology is used for two significantly different business purposes. I don't think there's any confusion about the threat model, which is Users find it too difficult to generate keys/obtain certs, so if the CA doesn't do it for them the users will complain, or not become users at all. Having the CA generate the key addresses this threat model. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: dual-use digital signature [EMAIL PROTECTED]
Richard Levitte - VMS Whacker [EMAIL PROTECTED] writes: Peter, are you talking about generic CAs or in-corporation ones? Both. Typically what happens is that the CA generates the key and cert and mails it to the user as a PKCS #12 file, either in plaintext, with the password in the same email, or occasionally with the password in separate email. See How to build a PKI that works on my home page (direct link at http://www.cs.auckland.ac.nz/~pgut001/pubs/howto.pdf, Challenge #2 starting on p.25) for details, including a few sample quotes from users. I can definitely see different needs between those. Actually they both seem to have the same need, it's the least effort to do it this way. Occasionally you see it dressed up as something else, e.g. We don't trust our users to generate the keys properly themselves (one of those was from a CA that's distinguished itself through the bugginess of its software, which makes the comment rather amusing coming from them), but it almost always boils down to the same thing. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: dual-use digital signature vulnerability
For what it's worth, last week, I had the chance to eat dinner with Carlisle Adams (author of the PoP RFC), and he commented that he didn't know of any CA that did PoP any other way than have the client sign part of a CRM. Clearly, this seems to contradict Peter's experience. I'd REALLY love to see some real numbers here---how many CAs (over how many users) do PoP a sane way; how many do it a silly way; what applications people use their keys for, etc. --Sean - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Using crypto against Phishing, Spoofing and Spamming...
At 03:20 AM 7/18/2004, Enzo Michelangeli wrote: Can someone explain me how the phishermen escape identification and prosecution? Gaining online access to someone's account allows, at most, to execute wire transfers to other bank accounts: but in these days anonymous accounts are not exactly easy to get in any country, and anyway any bank large enough to be part of the SWIFT network would cooperate in the resolution of obviously criminal cases. At least until a few years ago, and probably still today, it was easy to get a non-anonymous account in the US using fake ID. The Know Your Customer laws and other anti-terrorism fallout may have encouraged banks to check SSNs a bit more carefully, but as long as the person whose identity you're stealing doesn't have horrendously bad or good credit, it's probably still not hard. If it costs you $100 in fake ID to get the account set up, and you can burn the phish for $1000, then you win. But credit cards are probably more common and certainly easier to use. Buy laptops or other fungible goods, and sell them on eBay. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: dual-use digital signature [EMAIL PROTECTED]
Peter Gutmann wrote: A depressing number of CAs generate the private key themselves and mail out to the client. This is another type of PoP, the CA knows the client has the private key because they've generated it for them. It's also cost-effective. The CA model as presented is too expensive. If a group makes the decision to utilise the infrastructure for signing or encryption, then it can significantly reduce costs by rolling out from the centre. I see this choice as smart. They either don't do it at all, or they do it cheaply. This way they have a benefit. (Then, there is still the option for upgrading to self- created keys later on, if the project proves successful, and the need can be shown.) As a landmark, I received my first ever correctly signed x.509 message the other day. I've yet to find the button on my mailer to generate a cert, so I could not send a signed reply. Another landmark for the future, of course. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Humorous anti-SSL PR
Eric: On 2004, Jul 15, , at 17:55, Eric Rescorla wrote: There are advantages to message-oriented security (cf. S-HTTP) but this doesn't seem like a very convincing one. Could you please elaborate on this, or refer me to a document which expresses your views? I just read [1] in search of such ideas, but I have not yet read your book on TLS. Thanks, Zooko [1] http://www.terisa.com/shttp/current.txt - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
DES: Now 'really most sincerely dead'
Back in late 1996, I wrote to Jim Bidzos, proposing an RSA Challenge to break single DES by brute force computation. Later in 1997, the first DES Challenge was successfully completed. Its taken another 7 years, but NIST has finally pulled single DES as a supported mode. Favorite line: DES is now vulnerable to key exhaustion using massive, parallel computations. Triple DES is still a supported mode, as it should be. So, if a product claims to use DES for protection, you can now officially diss them for it. Peter Trei -- http://edocket.access.gpo.gov/2004/04-16894.htm [Federal Register: July 26, 2004 (Volume 69, Number 142)] [Notices] [Page 44509-44510] From the Federal Register Online via GPO Access [wais.access.gpo.gov] [DOCID:fr26jy04-31] --- DEPARTMENT OF COMMERCE National Institute of Standards and Technology [Docket No. 040602169-4169-01] Announcing Proposed Withdrawal of Federal Information Processing Standard (FIPS) for the Data Encryption Standard (DES) and Request for Comments AGENCY: National Institute of Standards and Technology (NIST), Commerce. ACTION: Notice; request for comments. --- SUMMARY: The Data Encryption Standard (DES), currently specified in Federal Information Processing Standard (FIPS) 46-3, was evaluated pursuant to its scheduled review. At the conclusion of this review, NIST determined that the strength of the DES algorithm is no longer sufficient to adequately protect Federal government information. As a result, NIST proposes to withdraw FIPS 46-3, and the associated FIPS 74 and FIPS 81. Future use of DES by Federal agencies is to be permitted only as a component function of the Triple Data Encryption Algorithm (TDEA). TDEA may be used for the protection of Federal information; however, NIST encourages agencies to implement the faster and stronger algorithm specified by FIPS 197, Advanced Encryption Standard (AES) instead. NIST proposes issuing TDEA implementation guidance as a NIST Recommendation via its ``Special Publication'' series (rather than as a FIPS) as Special Publication 800-67, Recommendation for Implementation of the Triple Data Encryption Algorithm (TDEA). DATES: Comments on the proposed withdrawal of DES must be received on or before September 9, 2004. ADDRESSES: Official comments on the proposed withdrawal of DES may either be sent electronically to [EMAIL PROTECTED] or by regular mail to: Chief, Computer Security Division, Information Technology Laboratory, ATTN: Comments on Proposed Withdrawal of DES, 100 Bureau Drive, Stop 8930, National Institute of Standards and Technology, Gaithersburg, MD 20899-8930. FOR FURTHER INFORMATION CONTACT: Mr. William Barker (301) 975-8443, [EMAIL PROTECTED], National Institute of Standards and Technology, 100 Bureau Drive, STOP 8930, Gaithersburg, MD 20899-8930. SUPPLEMENTARY INFORMATION: In 1977, the Federal government determined that, while the DES algorithm was adequate to protect against any practical attack for the anticipated 15-year life of the standard, DES would be reviewed for adequacy every five years. DES is now vulnerable to key exhaustion using massive, parallel computations. The current Data Encryption Standard (FIPS 46-3) still permits the use of DES to protect Federal government information. Since the strength of the original DES algorithm is no longer sufficient to adequately protect Federal government information, it is necessary to withdraw the standard. In addition, NIST proposes the simultaneous withdrawal of FIPS 74, Guidelines for Implementing and Using the NBS Data Encryption Standard and FIPS 81, DES Modes of Operation. FIPS 74 is an implementation guideline specific to the DES. An updated NIST Special Publication 800- 21, Guideline for Implementing Cryptography in the Federal Government, will provide generic implementation and use guidance for NIST-approved block cipher algorithms (e.g., TDEA and AES). Because it is DES- specific, and DES is being withdrawn, the simultaneous withdrawal of FIPS 74 is proposed. FIPS 81 defines four modes of operation for the DES that have been used in a wide variety of applications. The modes specify how data is to be encrypted (cryptographically protected) [[Page 44510]] and decrypted (returned to original form) using DES. The modes included in FIPS 81 are the Electronic Codebook (ECB) mode, the Cipher Block Chaining (CBC) mode, the Cipher Feedback (CFB) mode, and the Output Feedback (OFB) mode. NIST Special Publication 800-38A, Recommendation for Block Cipher Modes of Operation, specifies modes of operation for generic block ciphers. Together with an upcoming message authentication code recommendation, SP 800-38B, SP 800-38A is a functional replacement for FIPS
DIMACS Workshop on Mobile and Wireless Security
***CALL FOR PAPERS* * DIMACS Workshop on Mobile and Wireless Security November 3 - 5, 2004 DIMACS Center, Rutgers University, Piscataway, NJ Organizers: Bill Arbaugh, University of Maryland, [EMAIL PROTECTED] Presented under the auspices of the Special Focus on Communication Security and Information Privacy. CALL FOR PAPERS DEADLINE: September 1, 2004 The rapid growth of both voice and data wireless communications has resulted in several serious security problems in both the voice and data spaces. Unfortunately, many of the early security mistakes made with wireless voice communications were repeated with data communications, i.e. the use of flawed authentication and confidentiality algorithms. For example, the standards committee for 802.11 left many of the difficult security issues such as key management and a robust authentication mechanism as open problems. This has led many organizations to use either a permanent fixed cryptographic variable or no encryption with their wireless networks. Since wireless networks provide an adversary a network access point that is beyond the physical security controls of the organization, security can be a problem. Similarly, attacks against WEP, the link-layer security protocol for 802.11 networks can exploit design failures to successfully attack such networks. This workshop will focus on addressing the many outstanding issues that remain in wireless cellular and WLAN networking such as (but not limited to): Management and monitoring; ad-hoc trust establishment; secure roaming between overlay networks; availability and denial of service mitigation; and network and link layer security protocols. We will seek to extend work on ad hoc networking from a non-adversarial setting, assuming a trusted environment, to a more realistic setting in which an adversary may attempt to disrupt communication. We will investigate a variety of approaches to securing ad hoc networks, in particular ways to take advantage of their inherent redundancy (multiple routes between nodes), replication, and new cryptographic schemes such as threshold cryptography. ** Call for Participation: Advances in wireless technology as well as several other areas are changing the way the world does business and as a result computing is becoming more mobile, and users are demanding continuous access to the Internet. At the same time, the number of devices with embedded networking technology is growing exponentially--from boxes with RFID tags to Wi-Fi capable refrigerators since they destroy the notion of a static defensive perimeter. Furthermore, these trends make the ease of use and management of wireless based networks more important since naive consumers in the future will be establishing and using wireless networks on a scale significantly larger than today. This workshop will focus on identifying the current and future problems in wireless security and privacy and discuss possible solutions. The three day workshop will be organized around a series of talks on subjects related to mobility, wireless, and security and privacy technologies. There will be a mix between invited talks and talks selected from extended abstracts with plenty of discussion time between talks. Authors are encouraged to submit an extended abstract on any topic related to wireless and mobile security. Example topics of interest are Interworking security, mesh network security, sensor network security, the privacy of RFID networks, and the security of community networks. These topics are examples only and authors are encouraged to submit extended abstracts on other topics related to the workshop as long as the abstract is of a technical and research nature. Authors are also encouraged to submit early work, and new or outlandish ideas as the primary goal of the workshop is to allow researchers from the networking and security communities to meet in a workshop environment where ideas can be exchanged and discussed in an inter-disciplinary environment. Authors should submit a two page extended abstract in a font no less than 11pt with reasonable margins by midnight (Eastern time) September 1, 2004. Submission instructions will be posted at http://www.missl.cs.umd.edu/dimacs-workshop. ** Registration: Pre-registration deadline: October 27, 2004 Please see website for registration information. * Information on participation, registration, accomodations, and travel can be found at: http://dimacs.rutgers.edu/Workshops/MobileWireless/ **PLEASE BE SURE TO PRE-REGISTER EARLY**
DIMACS Workshop on Bounded Rationality
* DIMACS Workshop on Bounded Rationality January 31 - February 1, 2005 DIMACS Center, Rutgers University, Piscataway, NJ Organizers: Lance Fortnow, University of Chicago, [EMAIL PROTECTED] Richard McLean, Rutgers University, [EMAIL PROTECTED] Daijiro Okada, Rutgers University, [EMAIL PROTECTED] Presented under the auspices of the Special Focus on Computation and the Socio-Economic Sciences. Traditionally, economists and game theorists have assumed that strategic agents are fully rational in the sense that all players can completely reason about the consequences of their actions. In the last few decades, a number of game theorists have argued, in part motivated by experimental results, that human players do not behave in a way consistent with theoretical predictions. Questions have been raised regarding the postulate of full rationality and some have attempted formalization of partially or boundedly rational players and games played by such players. This research falls under the rubric of bounded rationality. If one takes the view that a process of decision making in economic or other social situations constitutes a computation in a formal sense of theoretical computer science, then one is naturally led to some notion of bounded computational power as a formal expression of bounded rationality. Two important and complementary questions in this line of inquiry are: (1) What is the computational power required in order to play a game in a way consistent with full rationality? (2) If players are limited in their computational power, how different will equilibrium outcomes be from the fully rational case? With regard to the first question, some researchers have examined the computational complexity of finding best responses in games. As to the second question, a number of researchers have focused on repeated games played by various types of computing machines with an emphasis on their role in facilitating cooperative behavior. In one branch of this work, bounded rationality is interpreted as bounded recall where a player's strategic options are limited by constraints that are placed on memories of past actions. A larger literature models bounded rationality in terms of finite automata. In particular, the strategies of players are limited to those that are implementable by finite state automata. Further work that studies strategies implementable by Turing machines may be found. Most of the aforementioned work has been carried out by game theorists and, with the exception of a short burst of activity in the mid-1990's, there has not been a significant amount of activity in bounded rationality from the computer science point of view. This workshop will bring together economists and game theorists interested in bounded rationality, as well as theoretical computer scientists with experience in limited computational models. It will explore previous interactions between computer scientists and economists concerning this topic. It will then address such issues as: What are the desiderata of a model of bounded rationality? How do models of bounded rationality affect conclusions of standard models? What aspects of human behavior have no compelling model of bounded rationality to explain them? Are there computational models that properly estimate the computational power of bounded players while allowing for an analysis that yields useful results? ** Registration Fees: (Pre-registration deadline: January 24, 2005) Please see website for additional registration information. * Information on participation, registration, accomodations, and travel can be found at: http://dimacs.rutgers.edu/Workshops/Bounded/ **PLEASE BE SURE TO PRE-REGISTER EARLY** *** - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
[Meetingpunks] SF Bay Area Cypherpunks August 2004 Physical Meeting Announcement
--- begin forwarded text Date: Tue, 27 Jul 2004 09:10:21 -0700 To: [EMAIL PROTECTED] From: Bill Stewart [EMAIL PROTECTED] Old-Subject: [Meetingpunks] SF Bay Area Cypherpunks August 2004 Physical Meeting Announcement Subject: [Meetingpunks] SF Bay Area Cypherpunks August 2004 Physical Meeting Announcement Approved: LISTMEMBER CPUNK Sender: [EMAIL PROTECTED] Rick Moen suggested we have a Cypherpunks meeting in August, so: SF Bay Area Cypherpunks August 2004 Physical Meeting Announcement General Info: DATE: Saturday 14 August 2004 TIME: 12:00 - 5:00 PM (Pacific Time) PLACE: Stanford University Campus - Tressider Union courtyard Agenda: Our agenda is a widely-held secret. (This will be our first meeting since April 2003, so the agenda is somewhat up for grabs. Among upcoming events to note is the 7th annual Information Security Conference, aka ISC04, Sept. 27-29 at Xerox PARC, http://isc04.uncc.edu/ . Also of note: Our friendly Federalistas seem to be imposing unprecedented visa restrictions on visiting foreign cryptographers. Is it time for all international cryptography conferences to move off-shore? See: http://www.schneier.com/crypto-gram-0407.html#3 ) As usual, this is an Open Meeting on US Soil, and the public is invited. Location Info: The meeting location will be familiar to those who've been to our outdoor meetings before, but for those who haven't been, it's on the Stanford University campus, at the tables outside Tressider Union, at the end of Santa Theresa, just west of Dinkelspiel Auditorium. We meet at the tables on the west side of the building, inside the horseshoe U formed by Tresidder. Ask anyone on campus where Tressider is and they'll help you find it. Food and beverages are available at the cafe inside Tresidder. Location Maps: Stanford Campus (overview; Tressider is dead-center). http://campus-map.stanford.edu/campus_map/bldg.jsp?cx=344cy=471zoomto=50zoomfrom=30bldgID=02-300 Tressider Union (zoomed detail view). http://campus-map.stanford.edu/campus_map/results.jsp?bldg=Tresidder Printable Stanford Map (407k). http://www.stanford.edu/home/visitors/campus_map.pdf [ This announcement sent to the following mailing lists: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Mailing list complaints or address corrections to [EMAIL PROTECTED] ] Bill Stewart [EMAIL PROTECTED] ___ Meetingpunks mailing list [EMAIL PROTECTED] http://lists.cryptorights.org/mailman/listinfo/meetingpunks Bill Stewart [EMAIL PROTECTED] --- end forwarded text -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 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 [EMAIL PROTECTED]
RE: dual-use digital signature [EMAIL PROTECTED]
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Gutmann Sent: Saturday, July 24, 2004 9:07 PM [SNIP] A depressing number of CAs generate the private key themselves and mail out to the client. Replies to this talked about business cases to have control of the private key not only under the identity upheld by the certificate. I would like to point out that whether or not a CA actually has the private key is largely immaterial because it always _can_ have the private key - a CA can always create a certificate for Alice whether or not Alice provided a public key. Whether or not Alice has complete control over her private key makes no difference to Bob. If the CA works properly, Bob and Alice can have a authenticated and private communications. If the CA is compromised (or inherently malicious), Bob will think he is having authenticated and private communications with Alice but will actually have it with an agent of the CA's choosing. This is the way the system was designed. Bob trusts the CA to provide for authenticated and private communications with Alice. 2 centsIn the business cases pointed out where it is good that the multiple parties hold the private key, I feel the certificate should indicate that there are multiple parties so that Bob can realize he is having authenticated and private communications with Alice _and_ Alice's employer. X.509 does not provide a standard way to encode multiple subjects./2 cents -Michael Heyman - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
should you trust CAs? (Re: dual-use digital signature vulnerability)
The difference is if the CA does not generate private keys, there should be only one certificate per email address, so if two are discovered in the wild the user has a transferable proof that the CA is up-to-no-good. Ie the difference is it is detectable and provable. If the CA in normal operation generates and keeps (or claims to delete) the user private key, then CA misbehavior is _undetectable_. Anyway if you take the WoT view, anyone who may have a conflict of interest with the CA, or if the CA or it's employees or CPS is of dubious quality; or who may be a target of CA cooperation with law enforcement, secrete service etc would be crazy to rely on a CA. WoT is the answer so that the trust maps directly to the real world trust. (Outsourcing trust management seems like a dubious practice, which in my view is for example why banks do their own security, thank-you-very-much, and don't use 3rd party CA services). In this view you use the CA as another link in the WoT but if you have high security requirements you do not rely much on the CA link. Adam On Wed, Jul 28, 2004 at 11:15:16AM -0400, [EMAIL PROTECTED] wrote: I would like to point out that whether or not a CA actually has the private key is largely immaterial because it always _can_ have the private key - a CA can always create a certificate for Alice whether or not Alice provided a public key. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The future of security
According to Ed Gerck: But encryption and authentication are a hassle today, with less than 2% of all email encrypted (sorry, can't cite the source I know). Are these 2% 'only' S/MIME and PGP-encrypted email messages or is SSL-encrypted email communication included? ciao... -- Lars Eilebrecht [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Feds and Yahoo Muzzle DNC Security Whistleblower
--- begin forwarded text Date: Sun, 25 Jul 2004 14:39:14 -0700 To: [EMAIL PROTECTED] From: John Young [EMAIL PROTECTED] Subject: Feds and Yahoo Muzzle DNC Security Whistleblower Sender: [EMAIL PROTECTED] It appears that the Feds and LEA at the DNC Convention have ordered Yahoo to axe the mail list TSCM-L run by James Atkinson for his blistering attack on security at the convention. http://cryptome.org/dncsec-yahoo.htm Jim's reports on the inferior security: http://cryptome.org/dnc-insec.htm http://cryptome.org/dnc-dauphine.htm The mail list had nothing to do with these reports, and the gag appears to be spite against Atkinson for whistleblowing. However, the mail list purpose is likely to have scared them more than his insecurity reports: http://finance.groups.yahoo.com/group/TSCM-L/ TSCM-L Technical Security Mailing List Dedicated to TSCM specialists engaging in expert technical and analytical research for the detection, nullification, and isolation of eavesdropping devices, wiretaps, bugging devices, technical surveillance penetrations, technical surveillance hazards, and physical security weaknesses. This also includes bug detection, bug sweep, and wiretap detection services. Special emphasis is given to detecting and countering espionage and other threats and activities directed by foreign intelligence services against the United States Government, United States corporations, establishments, and citizens. The list includes technical discussion regarding the design and construction of SCIF facilities, Black Chambers, and Screen Rooms. This list is also for discussing DIAM 50-3, NSA-65, and DCID 1/21, 1/22 compliance. The primary goal and mission of this list is to raise the bar and increase the level of professionalism present within the TSCM business. The secondary goal of this list is and increase the quality and effectiveness of our efforts so that we give spies and eavesdroppers no quarter, and to neutralize all of their espionage efforts. This mailing list is moderated by James M. Atkinson and sponsored by Granite Island Group as a public service to the TSCM, Counter Intelligence, and technical security community. -- --- end forwarded text -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 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 [EMAIL PROTECTED]
Re: should you trust CAs? (Re: dual-use digital signature vulnerability)
At 12:09 PM 7/28/2004, Adam Back wrote: The difference is if the CA does not generate private keys, there should be only one certificate per email address, so if two are discovered in the wild the user has a transferable proof that the CA is up-to-no-good. Ie the difference is it is detectable and provable. If the CA in normal operation generates and keeps (or claims to delete) the user private key, then CA misbehavior is _undetectable_. Anyway if you take the WoT view, anyone who may have a conflict of interest with the CA, or if the CA or it's employees or CPS is of dubious quality; or who may be a target of CA cooperation with law enforcement, secrete service etc would be crazy to rely on a CA. WoT is the answer so that the trust maps directly to the real world trust. (Outsourcing trust management seems like a dubious practice, which in my view is for example why banks do their own security, thank-you-very-much, and don't use 3rd party CA services). In this view you use the CA as another link in the WoT but if you have high security requirements you do not rely much on the CA link. in the case of SSL domain name certificates ... it may just mean that somebody has been able to hijack the domain name ... and produce enuf material that convinces the CA to issue a certificate for that domain name. recent thread in sci.crypt http://www.garlic.com/~lynn/2004h.html#28 Convince me that SSL certificates are not a big scam the common verification used for email address certificates (by certification authorities) ... is to send something to that email address with some sort of secret instructions. so the threat model is some sort of attack on email from the CA ... snarf the user's ISP/webmail password and intercept the CA verification email. (it simply falls within all the various forms of identity theft ... and probably significantly simpler than getting a fraudulent driver's license). with the defense that it is possibly another form of identity theft say you ever actually stumbled across such a fraudulently issued certificate it would probably be difficult to prove whether or not the certification authority was actually involved in any collusion. even discounting that there is no inter-CA certificate duplicate issuing verification there are enuf failure scenarios for public/private keys that somebody could even convince the same CA to issue a new certificate for the same email address (even assuming that they bothered to check) - Anne Lynn Wheelerhttp://www.garlic.com/~lynn/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Lost Record '02 Florida Vote Raises '04 Concern
http://www.nytimes.com/2004/07/28/politics/campaign/28vote.final.html?ei=5006en=b992e2c2cfb441c3ex=1091592000partner=ALTAVISTA1pagewanted=printposition= The New York Times July 28, 2004 Lost Record '02 Florida Vote Raises '04 Concern By ABBY GOODNOUGH IAMI, July 27 - Almost all the electronic records from the first widespread use of touch-screen voting in Miami-Dade County have been lost, stoking concerns that the machines are unreliable as the presidential election draws near. The records disappeared after two computer system crashes last year, county elections officials said, leaving no audit trail for the 2002 gubernatorial primary. A citizens group uncovered the loss this month after requesting all audit data from that election. A county official said a new backup system would prevent electronic voting data from being lost in the future. But members of the citizens group, the Miami-Dade Election Reform Coalition, said the malfunction underscored the vulnerability of electronic voting records and wiped out data that might have shed light on what problems, if any, still existed with touch-screen machines here. The group supplied the results of its request to The New York Times. This shows that unless we do something now - or it may very well be too late - Florida is headed toward being the next Florida, said Lida Rodriguez-Taseff, a lawyer who is the chairwoman of the coalition. After the disputed 2000 presidential election eroded confidence in voting machines nationwide, and in South Florida in particular, the state moved quickly to adopt new technology, and in many places touch-screen machines. Voters in 15 Florida counties - covering more than half the state's electorate - will use the machines in November, but reports of mishaps and lost votes in smaller elections over the last two years have cast doubt on their reliability. Like black boxes on airplanes, the electronic voting records on touch-screen machines list everything that happens from boot-up to shutdown, documenting in an event log when every ballot was cast. The records also include vote image reports that show for whom each ballot was cast. Elections officials have said that using this data for recounts is unnecessary because touch-screen machines do not allow human error. But several studies have suggested the machines themselves might err - for instance, by failing to record some votes. After the 2002 primary, between Democratic candidates Janet Reno and Bill McBride, the American Civil Liberties Union of Florida conducted a study that found that 8 percent of votes, or 1,544, were lost on touch-screen machines in 31 precincts in Miami-Dade County. The group considered that rate of what it called lost votes unusually high. Voting problems plagued Miami-Dade and Broward Counties on that day, when touch-screen machines took much longer than expected to boot up, dozens of polling places opened late and poorly trained poll workers turned on and shut down the machines incorrectly. A final vote tally - which narrowed the margin first reported between the two candidates by more than 3,000 votes - was delayed for a week. Ms. Reno, who ultimately lost to Mr. McBride by just 4,794 votes statewide, considered requesting a recount at the time but decided against it. Seth Kaplan, a spokesman for the Miami-Dade elections division, said on Tuesday that the office had put in place a daily backup procedure so that computer crashes would not wipe out audit records in the future. The news of the lost data comes two months after Miami-Dade elections officials acknowledged a malfunction in the audit logs of touch-screen machines. The elections office first noticed the problem in spring 2003, but did not publicly discuss it until this past May. The company that makes Miami-Dade's machines, Election Systems and Software of Omaha, Neb., has provided corrective software to all nine Florida counties that use its machines. One flaw occurred when the machines' batteries ran low and an error in the program that reported the problem caused corruption in the machine's event log, said Douglas W. Jones, a computer science professor at the University of Iowa whom Miami-Dade County hired to help solve the problem. In a second flaw, the county's election system software was misreading the serial numbers of the voting machines whose batteries had run low, he said. The flaws would not have affected vote counts, he said - only the backup data used for audits after an election. And because a new state rule prohibits manual recounts in counties that use touch-screen voting machines except in the event of a natural disaster, there would likely be no use for the data anyway. State officials have said that they created the rule because under state law, the only reason for a manual recount is to determine voter intent in close races when, for example, a voter appears to choose two presidential candidates or none. Touch-screen machines, officials say, are
