Re: entropy depletion
Let me raise a different issue: a PRNG might be better *in practice* because of higher assurance that it's actually working as designed at any given time. Hardware random number generators are subject to all sorts of environmental issues, including stuck bits, independent oscillators that aren't independent, contamination by power line frequency noise, etc. By contrast, a correct implementation of a cryptographic algorithm will always function correctly. (Yes, there could be an undetected hardware fault. Run it three times, on different chips) To me, the interesting question about, say, Yarrow is not how well it mixes in entropy, but how well it performs when there's essentially no new entropy added. Clearly, we need something to see a PRNG, but what are the guarantees we have against what sorts of threats if there are never any new true-random inputs? (Remember the purported escrow key generation algorithm for Clipper? See http://www.eff.org/Privacy/Newin/Cypherpunks/930419.denning.protocol for details. The algorithm was later disavowed, but I've never been convinced that the disavowal was genuine.) --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Simson Garfinkel analyses Skype - Open Society Institute
On Mon, Jan 10, 2005 at 08:33:41PM -0800, David Wagner wrote: | In article [EMAIL PROTECTED] you write: | Voice Over Internet Protocol and Skype Security | Simson L. Garfinkel | http://www.soros.org/initiatives/information/articles_publications/articles/security_20050107/OSI_Skype5.pdf | | Is Skype secure? | | The answer appears to be, no one knows. The report accurately reports | that because the security mechanisms in Skype are secret, it is impossible | to analyze meaningfully its security. Most of the discussion of the | potential risks and questions seems quite good to me. | | But in one or two places the report says things like A conversation on | Skype is vastly more private than a traditional analog or ISDN telephone | and Skype is more secure than today's VoIP systems. I don't see any | basis for statements like this. Unfortunately, I guess these sorts of | statements have to be viewed as blind guesswork. Those claims probably | should have been omitted from the report, in my opinion -- there is | really no evidence either way. Fortunately, these statements are the | exception and only appear in one or two places in the report. The basis for these statements is what the other systems don't do. My Vonage VOIP phone has exactly zero security. It uses the SIP-TLS port, without encryption. It doesn't encrypt anything. So, its easy to be more secure than that. So, while it may be bad cryptography, it is still better than the alternatives. Unfortunately. Adam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: entropy depletion
Ben Laurie wrote: William Allen Simpson wrote: Why then restrict it to non-communications usages? Because we are starting from the postulate that observation of the output could (however remotely) give away information about the underlying state of the entropy generator(s). Surely observation of /dev/urandom's output also gives away information? Right. So what we are looking at here is a requirement such that we don't leak any internal state. Traditionally, the Unix people would do this by a) limiting access to the resource to root and b) auditing the user of the resource carefully. But that's a bit OTT, IMHO. Another way of doing this is to put in a requirement that each read is separate and unlinked. That is, if you do a read of 1024 bits for some key operation, the contract with the random device is that entropy might be mixed between those bits, *but* it isn't mixed with any other read that might be done. Trivially, this could be met by throwing away all existing entropy, locking the entropy for syncronised read, and waiting until enough fresh stuff was built up. That might take a while, but hey, that's the contract that the coder asked for. And there are plenty of variants imaginable. Either way, it seems that restriction is not the only way to deal with the leakage problem, once we understand that avoiding the leakage is the requirement. -- News and views on what matters in finance+crypto: http://financialcryptography.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Entropy and PRNGs
Ed Gerck wrote: Let me comment, John, that thermal noise is not random When did you figure that out? If you'd been paying attention, you'd know that I figured that out a long time ago. First of all, the phrase not random is ambiguous. I said Some people think random should denote 100% entropy density, and anything less than that is non-random even if it contains a great deal of unpredictability. Other folks think that random refers to anything with an entropy density greater than zero, and non-random means completely predictable. Reference: http://www.av8n.com/turbid/paper/turbid.htm#sec-s-density Thermal noise, as it comes off the hardware, has an entropy density greater than zero and less than 100%, as I said at http://www.av8n.com/turbid/paper/turbid.htm#sec-hesg and elsewhere. There are several quantities that can be estimated in thermal noise, reducing its entropy according to what you seem to expect today. See photon bunching, as an example that is usually ignored. Another, even though trivial, example is due to the observation that thermal noise is not white noise. Yet another observation is that no noise is really white, because of causality (in other words, it's duration must be finite). The noise that is due to photon fluctuations in thermal background radiation, for another example, depends also on the number of detectors used to measure it, as well as single- or multiple-mode illumination, and both internal and external noise sources. Stop wasting our time. All that doesn't change the fact that thermal noise, as it comes off the hardware, has a nonzero entropy density. And it is easy to arrange situations where I can calculate a very useful lower bound on the entropy density. Yes, it's entirely possible that someone in the future will know more about your entropy source than you do today! Even thermal noise. That's tantamount to saying the second law of thermodynamics will be repealed. By that standard, it's entirely possible that the sun will rise in the west tomorrow morning. But I wouldn't bet on it. OTOH, why are nuclear decay processes considered safe as a source of entropy? Because the range of energies preclude knowing or tampering with the internal state. These processes are, however, not free from correlations either. Nuclear decay processes are not in any practical sense safer than thermal noise. As I discuss at http://www.av8n.com/turbid/paper/turbid.htm#sec-hesg-attack nuclear is in the same category as thermal: entropy density greater than zero and less than 100%. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: entropy depletion
Ben Laurie wrote: William Allen Simpson wrote: Why then restrict it to non-communications usages? Because we are starting from the postulate that observation of the output could (however remotely) give away information about the underlying state of the entropy generator(s). Surely observation of /dev/urandom's output also gives away information? Right. I'd suggest the original statement of the issue at hand might be better rephrased as: The *requirement* is that the generator not leak information. This requirement applies equally well to an entropy collector as to a PRNG. For an entropy collector there are a number of ways of meeting the requirement. 1. Constrain access to the device and audit all users of the device. 2. set the contract in the read() call such that the bits returned may be internally entangled, but must not be entangled with any other read(). This can trivially be met by locking the device for single read access, and resetting the pool after every read. Slow, but it's what the caller wanted! Better variants can be experimented on... We are still left with the notion as Bill suggested that no entropy collector is truly clean, in that the bits collected will have some small element of leakage across the bits. But I suggest we just cop that one on the chin, and stick in the random(5) page the description of how reliable the device meets the requirement. (This might be a resend, my net was dropping all sorts of stuff today and I lost the original.) iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Simson Garfinkel analyses Skype - Open Society Institute
People may already have seen this, but maybe not. Another Skype analysis: http://www.cs.columbia.edu/~library/TR-repository/reports/reports-2004/cucs-039-04.pdf -- Chris Palmer Technology Manager, Electronic Frontier Foundation 415 436 9333 x124 (desk), 415 305 5842 (cell) 81C0 E11D CE73 4390 B6C7 3415 B286 CD8F 68E4 09CD pgpikIGZhSbq4.pgp Description: PGP signature
Re: entropy depletion
Ian G wrote: The *requirement* is that the generator not leak information. This requirement applies equally well to an entropy collector as to a PRNG. Now here we disagree. It was long my understanding that the reason the entropy device (/dev/random) could be used for both output and input, and blocked awaiting more entropy collection, was the desire to be able to quantify the result. Otherwise, there's no need to block. For an entropy collector there are a number of ways of meeting the requirement. 1. Constrain access to the device and audit all users of the device. 2. set the contract in the read() call such that the bits returned may be internally entangled, but must not be entangled with any other read(). This can trivially be met by locking the device for single read access, and resetting the pool after every read. Slow, but it's what the caller wanted! Better variants can be experimented on... Now I don't remember anybody suggesting that before! Perfect, except that an attacker knows when to begin watching, and is assured that anything before s/he began watching was tossed. In my various key generation designs using MD5, I've always used MD-strengthening to minimize the entanglement between keys. There was MD5 code floating around for many many years that I wrote with a NULL argument to force the MD-strengthening phase between uses. I never liked designs with bits for multiple keys extracted from the same digest iteration output. And of course, my IPsec authentication RFCs all did the same. See my IP-MAC design at RFC-1852 and RFC-2841. We are still left with the notion as Bill suggested that no entropy collector is truly clean, in that the bits collected will have some small element of leakage across the bits. But I suggest we just cop that one on the chin, and stick in the random(5) page the description of how reliable the device meets the requirement. (This might be a resend, my net was dropping all sorts of stuff today and I lost the original.) That's OK, the writing was clearer the second time around. -- 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 [EMAIL PROTECTED]
Re: OpenVPN and SSL VPNs
* Stefan Mink: a) It would be good to hear from this community if there are any negative aspects of OpenVPN (vs. IPsec VPNs). It's not standardized, and it only interoperates with itself (but this is true for many IPsec implementations as well). This is more than compensated by its portability. OpenVPN has a very interesting feature set, including hybrid authentication and a HMAC-based integrity check before TLS processing for the paranoid. (Static key mode is also possible and doesn't require TLS at all.) While it's true that OpenVPN's protocol is not yet standardized, I would argue that an important niche in network security, namely the forwarding of entire virtual network interfaces (and not merely ports), and doing this all from userspace, was not being addressed by existing protocols. SSL/TLS does a good job of tunneling reliable transport protocols such as TCP from userspace. IPSec does a good job of tunneling protocols which use unreliable semantics, such as IP, from kernel space. ssh is great for forwarding TCP ports. But no protocol existed at the time of OpenVPN's inception to tunnel unreliable protocols from user space (because VPNs tunnel protocols which are designed to operate at the physical layer, it is important for VPNs to use a security layer which operates at the datagram semantics level -- this means you want something like a TLS protocol which can tunnel UDP). This void has been recognized by others, and led to the development of Datagram TLS (DTLS) by Negendra Modadugu and Eric Rescorla. http://crypto.stanford.edu/~nagendra/papers/dtls.pdf This approach of developing a variant of TLS for securing a UDP stream is similar to that taken by OpenVPN. DTLS can be implemented inside the OpenSSL library as a variation to TLS. OpenVPN takes a different approach and uses standard TLS, but encapsulates it inside a reliability layer, not unlike the way that TLS over TCP accomplishes the same objective. I expect that future versions of OpenVPN will gravitate towards using DTLS as the security layer, as this is in line with OpenVPN's modular approach to security where as much as possible, encryption and authentication functions are offloaded to an independently developed crypto library such as OpenSSL. Another reason why OpenVPN was forced to implement its own TLS-based VPN protocol is that it uses a user-space daemon execution model. Why tunnel from user-space? For the same reason that ssh or apache + modssl runs in userspace: portability and security. Portability: Why write a complex piece of code only to have to reimplement it for every OS in existence? A major reason why OSes exist in the first place is to provide a platform for the development of portable code. Unless code requires the special execution environment of kernel mode, i.e. access to privileged CPU instructions, direct hardware I/O, extreme performance requirements, or the ability to disable preemption, why not implement in user-space and get all of the advantages of portability and stability? Security: Implementing network security code in the kernel disobeys a cardinal rule of security: never design a security model so that a single failure causes a catastrophic security breach. Kernel mode code is never further than one buffer overflow away from root compromise. Implementing security in userspace provides the additional security buffer that exists between user and kernel space: a daemon can setuid/gid to nobody and chroot to an empty jail. Now a buffer overflow in the userspace daemon doesn't mean an automatic root compromise. It makes a root exploit much more challenging to develop because you first must compromise the daemon, then install a secondary exploit which takes advantage of a local root exploit in the OS. Essentially you need to simultaneously exploit two vulnerabilities in unrelated code in order to gain root access. Flexibility: I think about OpenVPN as being a kind of ssh which allows a more flexible port forwarding model: a very useful feature of ssh is that it can do secure TCP port forwarding. But that's just a special case of the more general problem of securely forwarding an entire virtual network interface. OpenVPN tries to solve this problem by letting you create a virtual ethernet or point-to-point IP interface on system A and securely connect it with a similar interface on system B. You could think of ssh as being a TCP port forwarder while OpenVPN can forward an entire virtual network interface. Forwarding a virtual interface means that all TCP and UDP ports are forwarded, all IP protocols are forwarded, etc. The routing table and firewall config are used to decide which applications get routed over the VPN or blocked. Unfortunately, the protocol would have to be reverse-engineered from the source code before it can be reviewed. You've already mentioned important aspects of the protocl (TSL on the control plane, ESP for the payload). Writing a comprehensive
Re: Simson Garfinkel analyses Skype - Open Society Institute
- Original Message - From: David Wagner [EMAIL PROTECTED] Subject: Simson Garfinkel analyses Skype - Open Society Institute In article [EMAIL PROTECTED] you write: Is Skype secure? The answer appears to be, no one knows. The report accurately reports that because the security mechanisms in Skype are secret, it is impossible to analyze meaningfully its security. Actually that is not entirely true. While Skype has been getting more than it's fair share of publicity lately surrounding it's security the truth is that shortly after it's first release I personally had a discussion in their forums (should still be there if you find something by holomntn that's the correct one, I haven't discussed anything since). In that discussion it was shown that they clearly did not have a solid grasp on security, nor apparently had anyone of them read the SIP specification. During that conversation, and some future private ones, it has been revealed to me that Skype's security is questionable at best, and that they are in fact basically relying on security through obscurity. It is likely that this will work for quite some time simply because most IM conversations, and most phone conversations for that matter are simply not worth listening to. With that said, in their favor they do have substantial qualities. Because they effectively form a routed network an intermediate evesdropping attempt will have to sort through a substantial amount of undesired traffic (see Rivest on Wheat and Chaff for explaination of the security offered), this is possible because although there are security holes, the end stream is difficult to determine from random (AES/CBC). This creates a substantial boost in the amount of effort required to acquire a stream of significance unless the endpoints are known. The other big thing in their favor is that apparently very few people want to be bothered by analysing the security, basically if no one is looking it is secure. Additionally, in version 1.1 Skype appears to have begun providing a moving target for a break, between version 1.0 and 1.1 Skype performed some changes to the protocol, while I do not know the exact nature of these, even a simple investigation of the GUI shows some changes (IM someone with a different version you will be cautioned about protocol changes even though security is not listed), this moving target creates the possibility to generate some security through obscurity, and the ability to upgrade the security at a moments notice. Working against them. The biggest thing working against them is that a growing number of teenagers are using Skype (a significant portion of Gunderson High School in San Jose, Ca actually uses Skype during class, and has been busted by me for it). This poses a substantial risk for common hacking to occur. This is something that I am unclear on whether or not Skype has prepared. As the general populus begins to use Skype more the security question becomes of greater importance (reference the attacks on Windows that go on every day). With all that said it is important to note that I have no access to the current Skype protocol and I only briefly had limited access to an early one, so my analysis may be substantially off. Joe - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
DIMACS Workshop on Security of Web Services and E-Commerce
Call for Participation Deadline January 17, 2005 *** DIMACS Workshop on Security of Web Services and E-Commerce May 5 - 6, 2005 DIMACS Center, Rutgers University, Piscataway, NJ Organizer: Brian LaMacchia, Microsoft, [EMAIL PROTECTED] Presented under the auspices of the Special Focus on Communication Security and Information Privacy. The growth of Web Services, and in particular electronic commerce activities based on them, is quickly being followed by work on Web Services security protocols. While core XML security standards like XMLDSIG, XMLENC and WS-Security have been completed, they only provide the basic building blocks of authentication, integrity protection and confidentiality for Web Services. Additional Web Services standards and protocols are required to provide higher-order operations such as trust management, delegation, and federation. At the same time, the sharp rise in phishing attacks and other forms of on-line fraud simply confirms that all our work on security protocols is for naught if we cannot make it both possible and easy for the average user to discover when a security property has failed during a transaction. This workshop aims to explore these areas as well as other current and future security and privacy challenges for Web Services applications and e-commerce. ** Participation: The workshop will be open to the public (no submission is necessary to attend). If you'd like to give a presentation please send a title and abstract to: [EMAIL PROTECTED] by January 17, 2005. Submissions may describe ongoing or planned work related to the security of Web Services and electronic commerce, or they may discuss important research problems or propose a research agenda in this area. Also, we intend this to be a participatory and interactive meeting so we hope you will be able to contribute to the meeting even without giving an announced talk. * Registration: Pre-registration deadline: April 28, 2005 Please see website for complete registration information: http://dimacs.rutgers.edu/Workshops/Commerce/ * Information on participation, registration, accomodations, and travel can be found at: http://dimacs.rutgers.edu/Workshops/Commerce/ **PLEASE BE SURE TO PRE-REGISTER EARLY** - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Effort to Speed Airport Security Is Going Private
http://online.wsj.com/article_print/0,,SB110549106703823542,00.html The Wall Street Journal January 12, 2005 Effort to Speed Airport Security Is Going Private Move Aims to Expand Program That Preregisters People Who Travel Frequently By AMY SCHATZ Staff Reporter of THE WALL STREET JOURNAL January 12, 2005; Page D1 The Homeland Security Department, under pressure to jump-start a program allowing select preregistered travelers to speed through airport security, is turning to the private sector for help. The Registered Traveler program gives frequent air passengers access to special security lines, provided they first voluntarily undergo criminal and terrorist background checks. In exchange, they get a biometric identification card -- containing a fingerprint and other personal data -- and access to the shorter lines. The program has generally received favorable reviews from volunteers and the three-month trial has been extended indefinitely. There is just one problem: The pilot program, currently administered by the department's Transportation Security Administration, is offered at only five airports for just 10,000 volunteers. This means that Registered Travelers can use their cards only at their home airports and nowhere else. TSA's pace at expanding the test into a national program has, so far, been the biggest complaint. The slow introduction has prompted interest from some businesses, who believe that travelers would be willing to pay to participate in the program. Interested entrepreneurs include Steven Brill, who started American Lawyer magazine and Court TV and, after writing a book on Sept. 11, decided to get into the homeland-security business. In a plan set to be unveiled in coming weeks, TSA officials will lay out some details of a privately operated Registered Traveler pilot program at Orlando International Airport. The success of the pilot, expected to begin by the end of March, could determine the future of the Registered Traveler program and be a model for expanding it nationally. Mr. Brill and others have been pushing for TSA to privatize the program, saying that businesses are better equipped than the government to market and expand it, especially because some travelers have indicated that they would pay annual fees -- as much as $100 -- for faster screening. TSA officials agree, believing that passengers, not taxpayers, should fund Registered Traveler, because it is likely to be used by business people rather than leisure travelers. Homeland Security officials are eager to see it move forward. TSA has had some false starts in other initiatives, and it has taken knocks for long lines and intrusive pat-down searches. But privacy advocates, who have already voiced concern about the government-run pilot programs, are even more worried now that TSA is turning to the private sector. EXPRESS LINE How expedited security works in five pilot programs: Who's eligible: 10,000 frequent- flier club members; enrollment closed What they provide: Fingerprint, iris scan, personal data What they get: Biometric ID card What they have to do at airport: Open laptop, remove keys, coins. What they don't have to do: Join leisure travelers for random screening. They complain that Homeland Security officials routinely publish privacy guidelines too vague to give the public a real understanding of how personal data are handled. A privatized system could exacerbate the problem, says Marcia Hoffman, staff counsel of the Electronic Privacy Information Center, a Washington nonprofit organization. TSA sees private-sector involvement as a route to faster growth. We're trying to encourage as much private sector participation as possible, says Justin Oberman, a TSA official in charge of both Registered Traveler and its more controversial sister-project, Secure Flight, a computerized prescreening system that will replace a system currently run by the airlines. Plans to run the privatized pilot in Orlando were publicly disclosed in October, when AirTran Airways, a unit of Orlando-based AirTran Holdings Inc., said it would participate in the program. But efforts between TSA and the airport to reach terms on the pilot have dragged on. One reason: TSA officials haven't decided whether to compile a master list of Registered Travelers, which could be used to check passengers at all participating airports, or allow private companies to maintain passenger data in a universal format easily accessed by competitors. The Orlando airport hasn't yet chosen a vendor to run its test, although airport officials say they are in talks with Mr. Brill's New York-based company, Verified Identity Pass Inc. Verified Identity would essentially assume marketing responsibilities while its partners -- possibly including Lockheed Martin Corp. -- would install scanners, process applications and manufacture ID cards. TSA screeners, who are government employees, would continue to staff the security lines. Orlando
Re: entropy depletion
William Allen Simpson wrote: Ben Laurie wrote: William Allen Simpson wrote: Why then restrict it to non-communications usages? Because we are starting from the postulate that observation of the output could (however remotely) give away information about the underlying state of the entropy generator(s). Surely observation of /dev/urandom's output also gives away information? ummm, no, not by definition. /dev/random blocks on insufficient estimate of stored entropy useful for indirect measurement of system characteristics (assumes no PRNG) /dev/urandom blocks only when insufficient entropy for initialization of state computationally infeasible to determine underlying state (assumes robust PRNG) These are the definitions we've been using around here for many years. It does help when everybody is talking about the same things. Around where? I've never heard of a /dev/random that doesn't include a PRNG. But I'll admit its entirely possible I just haven't been paying attention. Can you give examples? In any case, if the postulate is that observing the output could give away information about the underlying state, then I cannot see how /dev/urandom gets around this problem. 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 [EMAIL PROTECTED]
[EMAIL PROTECTED]: [fc-announce] FC'05 - Registration Now Open]
From: Stuart E. Schechter [EMAIL PROTECTED] Subject: [fc-announce] FC'05 - Registration Now Open To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Wed, 12 Jan 2005 21:29:22 -0500 Registration now open at http://www.ifca.ai/fc05/registration.html Call for Participation Financial Cryptography and Data Security February 28 - March 3, 2005 Roseau, Dominica http://www.ifca.ai/fc05 * Registration is now open * Financial Cryptography and Data Security (FC'05) is the premier international forum for research, advanced development, education, exploration, and debate regarding security in the context of finance and commerce. We have augmented our conference title and expanded our scope to cover all aspects of securing transactions and systems. These aspects include a range of technical areas such as: cryptography, payment systems, secure transaction architectures, software systems and tools, user and operator interfaces, fraud prevention, secure IT infrastructure, and analysis methodologies. FC'05 brings together top cryptographers, data-security specialists, and scientists with economists, bankers, implementers, and policy makers. Intimate and colorful by tradition, the FC'05 program will features invited talks (to be announced), academic presentations, technical demonstrations, and panel discussions. This conference is organized annually by the International Financial Cryptography Association (IFCA). Keynote Speakers Lynne Coventry (NCR) Usable Security: A conundrum? Bezalel Gavish (Southern Methodist University) Trust and Swindling on the Internet Panel Sessions == Financial Technology in the Developing World Allan Friedman (Harvard) - Organizer Alessandro Acquisti (CMU) H William Burdett, Jr. (Foley Lardner, LLP) Jon Peha (CMU) Phishing Steve Myers (Indiana University) - Organizer Drew Dean (SRI) Stuart Stubblebine (Stubblebine Research Labs) Richard Clayton (Cambridge, UK) Markus Jakobsson (Indiana University CACR) Research Papers === Fraud within Asymmetric Multi-Hop Cellular Networks Gildas Avoine (EPFL, Lausanne, Switzerland) Information-Theoretic Security Analysis of Physical Uncloneable Functions P. Tuyls B. Skoric S. Stallinga A.H. Akkermans W. Ophey (Philips Research Laboratories, The Netherlands) Views, Reactions and Impact of Digitally-Signed Mail in e-Commerce. Simson L. Garfinkel Jeffrey I. Schiller Erik Nordlander (MIT) David Margrave (Amazon.com) Robert C. Miller (MIT) Identity-based Partial Message Recovery Signatures (or How to Shorten ID-based Signatures) Fangguo Zhang (Sun Yat Sen University, P.R.China) Yi Mu Willy Susilo (University of Wollongong, Australia) How to Non-Interactively Update a Secret Eujin Goh (Stanford University) Philippe Golle (Palo Alto Research Center) Interactive Diffie-Hellman Assumptions with Applications to Password-Based Authentication Michel Abdalla David Pointcheval (Ecole Normale Superieure) Achieving Fairness in Private Contract Negotiation Keith Frikken Mikhail Atallah (Purdue University) Protecting Secret Data from Insider Attacks David Dagon Wenke Lee Richard Lipton (Georgia Tech) RFID Traceability A Multilayer Problem Gildas Avoine Philippe Oechslin (EPFL Lausanne Switzerland) A User-Friendly Approach to Human Authentication of Messages Jeff King Andre dos Santos (Georgia Tech) Countering Identity Theft through Digital Uniqueness, Location Cross-Checking, and Funneling P.C. van Oorschot (Carleton University) S. Stubblebine (Stubblebine Research Labs) Policy-Based Cryptography and Applications Walid Bagga Refik Molva (Eurecom) A Privacy Protecting Coupon System Liqun Chen (HP Laboratories) Matthias Enzmann (Fraunhofer SIT) Ahmad-Reza Sadeghi (University of Bochum) Markus Schneider (Fraunhofer SIT) Michael Steiner (IBM T.J. Watson) Analysis of a Multi-Party Fair Exchange Protocol and Formal Proof of Correctness in the Strand Space model Steve Kremer Aybek Mukhamedov Eike Ritter (University of Birmingham, UK) Secure Biometric Authentication for Weak Computational Devices Mikhail J. Atallah Keith B. Frikken (Purdue) Michael T. Goodrich (UC Irvine) Roberto Tamassia (Brown) Small Coalitions Cannot Manipulate Voting Edith Elkind (Princeton University) Helger Lipmaa (Helsinki University of Technology) Efficient Privacy-Preserving Protocols for Multi-Unit Auctions Felix Brandt (Stanford) Tuomas Sandholm (Carnegie Mellon University) Risk Assurance for Hedge Funds using Zero Knowledge Proofs Michael Szydlo (RSA
Network World: NIST dubious about 802.11 TKIP; wants AES
NIST mulls new WLAN security guidelines By Ellen Messmer The National Institute of Standards and Technology, the federal agency responsible for defining security standards and practices for the government, plans to issue new guidelines pertaining to wireless LANs in the near future. The decisions NIST reaches, possibly as early as this month, will broadly affect federal agency purchases of WLAN equipment, because federal agencies are required to follow NIST recommendations. According to William Burr, manager of NIST's security technology group, the agency is focusing on whether to approve the IEEE's 802.11i WLAN security standard for encryption and authentication as a government standard. The IEEE approved 802.11i last July, but Burr says NIST is not keen on some aspects of it. Specifically, NIST has reservations about the so-called Temporal Key Integrity Protocol (TKIP), which is the key management protocol in 802.11i that uses the same encryption engine and RC4 algorithm that was defined for the Wired Equivalent Privacy protocol (WEP). The 40-bit WEP, used in many early WLAN products, was criticized widely in the past two years as having too short a key length and a poor key management scheme for encryption. TKIP is a wrapper that goes around WEP encryption and ensures that TKIP encryption is 128 bits long. TKIP was designed to ensure it could operate on WLAN hardware that used WEP. In contrast, the 128-bit Advanced Encryption Standard (AES), which NIST already has approved, requires a hardware change for most older WLAN equipment. We just don't feel that the TKIP protocol cuts the grade for government encryption, Burr says. He adds that the RC4 encryption algorithm is not a Federal Information Processing (FIPS) standard and probably won't ever be because network professionals see RC4 as rather weak in terms of message authentication and integrity. NIST is more inclined to approve AES for WLAN security, and in fact Burr pointed to the NIST document 800-38C, published last summer, for encryption that includes the AES algorithm. As far as the key management scheme for key exchange and setup is concerned, NIST might introduce a new key-management technology that's been jointly developed with the National Security Agency. ___ Senior Editor Ellen Messmer covers security for Network World. Contact her at mailto:[EMAIL PROTECTED]. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: entropy depletion
William Allen Simpson wrote: Ian G wrote: The *requirement* is that the generator not leak information. This requirement applies equally well to an entropy collector as to a PRNG. Now here we disagree. It was long my understanding that the reason the entropy device (/dev/random) could be used for both output and input, and blocked awaiting more entropy collection, was the desire to be able to quantify the result. Otherwise, there's no need to block. I'm sorry, I don't see the relationship between the requirement to not leak, and the requirement to deliver a quantifiable result. For an entropy collector there are a number of ways of meeting the requirement. 1. Constrain access to the device and audit all users of the device. 2. set the contract in the read() call such that the bits returned may be internally entangled, but must not be entangled with any other read(). This can trivially be met by locking the device for single read access, and resetting the pool after every read. Slow, but it's what the caller wanted! Better variants can be experimented on... Now I don't remember anybody suggesting that before! Perfect, except that an attacker knows when to begin watching, and is assured that anything before s/he began watching was tossed. That seems to address the trivial implementation rather than the requirement? (In practice, I'd be inclined to not so much reset the pool after every read, but flush or discard a certain amount that is calculated to reduce any cross read leakage. But yes, the requirement may prove to present some interesting challenges to the implementor.) In my various key generation designs using MD5, I've always used MD-strengthening to minimize the entanglement between keys. There was MD5 code floating around for many many years that I wrote with a NULL argument to force the MD-strengthening phase between uses. I never liked designs with bits for multiple keys extracted from the same digest iteration output. And of course, my IPsec authentication RFCs all did the same. See my IP-MAC design at RFC-1852 and RFC-2841. Zooko and I struck this issue in our recent SDP1. As a datagram secret key layout, it uses a lot of secret keying material. The way we resolved it was to set a requirement for quality in the key exchange phase, which derived from a requirement to reduce the complexities of the datagram encryption phase (for programming reasons, not crypto reasons); in effect we punted the problem upstairs and put all the load on the key exchange phase. iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Sun creates worlds smallest SSL Web server
http://www.cbronline.com/article_news.asp?guid=38DE2210-C6D9-4A59-B84F-98588FA24962 - Computer Business Review Sun creates world's smallest SSL Web server Sun Microsystems Inc has created what can truly be called a microsystem. The tiny server, nicknamed Sizzle (from Slim SSL), is the size and shape of a quarter. It was created by Sun's engineers as a proof-of-concept machine for embedded applications and will be presented at the Pervasive Computing and Communications show in March. 14 Jan 2005, 10:47 GMT - Sizzle is a wireless Web server and is based on an 8-bit microprocessor designed by Crossbow Technology Inc. The server has 8Kb of main memory, which implements a stripped-down operating system plus a Web server and an SSL server. Crossbow has created its own operating system, called TinyOS, for these remote computers, often referred to as motes. The mote that Sun is using in Sizzle is called the MICA2DOT, and it is powered by a three-volt button battery, like the kind in your motherboard to keep your BIOS settings alive. It is unclear if Sun is using TinyOS or a stripped-down version of Solaris or Linux to create its micro Web server. Sun is adding 128Kb of flash memory to the mote, and it is implementing a version of SSL based on Elliptic Curve Cryptography (ECC) that Sun says makes public key cryptography suitable on a very tiny machine with extremely limited capabilities. Sizzle can complete an SSL handshake in under four seconds, and can do it in under two seconds with sessions that are reused; the Web server can transfer about 450 bytes per second. While you may not be able to run Yahoo on it, you can build vast arrays of sensors with ad hoc networking, which is what motes are for. -- - 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]
Hanging the Pirates
http://www.forbes.com/forbes/2005/0131/096_print.html Forbes Security Hanging the Pirates 01.31.05 Paul Kocher has a way to save Hollywood from illegal copying. Over the past few months top brass from Hollywood and Japan's consumer electronics giants have been hashing out their futures in hotel meeting rooms in Tokyo and Los Angeles. Topic A is the politically charged debate over the standard for the new high-definition DVDs, which the film industry hopes will swell the current $24 billion DVD market, as hi-def becomes the norm. Most of the players want to get something decided on within a year. But, as big as the stakes are in those discussions, the movie studios are even more keen on the outcome of the talks on the 39th floor of Toshiba's Tokyo headquarters. By the Numbers Price of Piracy Illegal file-sharing hits music far harder than film--for now. $21 billion n DVD sales in U.S. in 2004, a 200% increase since 2000. $12 billion CD sales in U.S., a 17% decline since 2000. $3 billion Amount movie studios lose to piracy each year. $4 billion Amount music publishers lose to piracy each year. Sources: Adams Media Research; RIAA; MPAA. There, a select security committee representing both hardware and film makers has an extremely rare opportunity to stop digital piracy from doing to movies what it did to music. Napster and its ilk have helped knock 17% off of record label sales in the past three years. With DVD's basic encryption already cracked and one-quarter of American homes now capable of broadband-speed downloads, it's inevitable that one day the latest Harry Potter film will be swapped as easily as U2's new hit. This is the number one priority at the highest levels, says Thomas Lesinski, president of Paramount Home Entertainment. The studios want to have more control over protecting our content. One of the most important people involved in that discussion is Paul Kocher, the 31-year-old president of Cryptography Research, a tiny San Francisco consulting and licensing firm that brought in $6 million last year. Kocher is soft-spoken, young and obscure, but his credibility in the encryption business is sterling. Eight years ago, fresh out of Stanford, Kocher cowrote Secure Sockets Layer (SSL), the protocol that secures the vast majority of commerce on the Internet. What Kocher is pushing is the concept of renewable security. Any attempt to erect a one-time, rigid barrier between thieves and content, he says, is useless, including the current method pushed through by the Japanese consumer electronics companies. With very few exceptions, all the major security systems being used by the studios today are either broken and can't be fixed, or they're not deployed widely enough to be worth hacking, says Kocher. Under the existing Content Scrambling System, electronics makers install the exact same encryption code into nearly every DVD player. But that was broken by European hackers in 1999 and the trick disseminated widely on the Internet. Even the least sophisticated user can now download a program that easily copies protected movies. Kocher's alternative is to allow for constant change. His system, called self-protecting digital content, places the security on the disc instead of in the player. A software recipe running into the millions of steps is burned onto every new movie disc. Each DVD player would contain a small chip costing only a few extra cents that would follow the recipe faithfully. If the DVD player decides the disc is secure, it will decode it and play the movie. But each film could have a different recipe. So if a pirate breaks the code on Spider-Man 2, he wouldn't necessarily be able to break the code on Elf. The studios would always be one step ahead of the thieves; at the very least it would take pirates more time to break each film. Not a big deal: Studios make most of their money from DVDs in the first three months, anyway. A lot of security systems are hard and brittle, says Robert Baldwin, head of the security firm Plus Five Consulting. Paul's is more like a willow tree. It bends and recovers. No studio executive contacted would comment on Kocher's scheme on the record, but it looks likely to be the backbone of any eventual security standard. A group including IBM, Toshiba, Time Warner and Microsoft is also angling to get a complementary encryption scheme called AACS into every future player. It will likely be written to work with Kocher's idea. Consumer electronics firms, which dictated the last encryption format, never had much to lose from security leaks. Film executives like the fact that Kocher's scheme gives them a stronger hand. Now they will be able to decide how much security they want on each disc and when it needs to be updated. Kocher, son of a physics professor at Oregon State University in Corvallis, says he learned about computing because he stayed home a lot, too lazy to bike the two miles into town. He initially wanted to be a
[Fwd: Call for Papers: Virtual Goods 2005]
Dear Virtual Goods Community, here is the link to the cfp: http://virtualgoods.tu-ilmenau.de/2005/cfp_short.txt Please feel free to distrubute it. Best regards Juergen Here is the text: C A L L F O R P A P E R S The 3rd International Workshop for Technology, Economy, Social and Legal Aspects of Virtual Goods including the new Virtual Goods Tutorial Organized by the GI Working Group ECOM and in parallel with IFIP Working Group 6.11 Communication Systems in Electronic Commerce June 2 - 4, 2005, Ilmenau, Germany http://VirtualGoods.tu-ilmenau.de - Full version: http://virtualgoods.tu-ilmenau.de/2005/cfp.html Topics of interest include, but are not restricted to, the following aspects: - * Digital rights management * Peer-to-Peer systems * Payment systems * New business models * Solution architectures * Legal aspects * Inter-cultural aspects * Security and privacy * Content protection * Watermarking * Cryptographic mechanisms Important Dates: March 1, 2005 Full papers submitted April 5, 2005 Notification of acceptance May 1, 2004Web-ready papers due Technical Committee: General chair: Ruediger Grimm: mailto:[EMAIL PROTECTED] Program Chair: Juergen Nuetzel: mailto:[EMAIL PROTECTED] Local chair: Thomas Boehme: mailto:[EMAIL PROTECTED] Please freely distribute this call for papers. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
[i2p] Tunnel cryptography for I2P 0.5 (corrected typo) (fwd from [EMAIL PROTECTED])
From: [EMAIL PROTECTED]
Subject: [i2p] Tunnel cryptography for I2P 0.5 (corrected typo)
To: [EMAIL PROTECTED]
Date: Mon, 17 Jan 2005 22:15:33 -0800
Citizens of I2P,
The following is a discussion of tunnel cryptography plans for
I2P 0.5. There are two options; one will be chosen.
[1] and [2] offer more complete discussion of these plans. Note that
the cryptographic methods discussed in [2] are incomplete. They are
complete in this message.
- Connelly
--
Tunnel cryptography for I2P 0.5
--
Currently when I2P 0.4.x passes an (end-to-end encrypted) message M
down a tunnel, it is easy for two attackers in different locations of
the tunnel to observe the same message M. This makes I2P highly
vulnerable to the predecessor attack.
Can this situation be improved?
The best implementations we currently know of fit in two categories,
and use symmetric cryptography. The categories are:
1. The inbound tunnel gateway knows all symmetric private keys used by
other hops in the tunnel. The outbound tunnel endpoint knows only
its own symmetric private key. Messages are checksummed to prevent
modification.
Pros: Tagging attacks are defeated.
Cons: Attacking an N-length inbound tunnel won't be much harder
than attacking a 2-length inbound tunnel. If the gateway is
malicious, then the gateway can collude with a malicious hop
at any other position in the tunnel; thus the two can
identify that they are in the same tunnel.
= Predecessor attack.
This was one plan by jrandom. A proposed implementation is given
[1]. This implementation could be subject to tagging attacks in
certain cases. I have a revised scheme in mind that may be safe
from these attacks.
2. The inbound tunnel gateway has only its own symmetric private key.
Likewise for the outbound tunnel endpoint. No messages are
checksummed in the tunnel. All messages have the same size in
the tunnel to prevent tagging. Synchronized PRNGs may be used as
described at [2] to help prevent tunnel loops (where an attacker
DoSes several peers by placing them a looped tunnel).
Pros: Attacking an N-length inbound tunnel is not easy (one must do
timing or message counting analysis).
Cons: Tagging (this can be done, but not detected), tunnel loops
can be created, extra packets can be generated within the
tunnel.
This plan was originally drafted in [2] based on a discussion by
jrandom and ???. However, this document has pending modifications
because it is not a complete cryptosystem. A full implementation
plan is appended to the end of this document, based on a discussion
by jrandom and Connelly.
One of these options will (presumably) be used in I2P 0.5. If you
discover a flaw or improvement for either implementation, let us
know. If you have other useful input, drop by IRC or post a message
to this maillist.
We have not found a complete cryptographic analysis for either option.
We are using standard cryptographic primitives and methods when
possible.
Option 2 is known as a non-checksummed tunnel.
--
Proposed Implementation (non-checksummed tunnels)
--
Leaving out the PRNGs.
As part of a tunnel, we receive and send messages which contain
{preIV, payload}. Here preIV is a single block from which the
initialization vector (IV) is derived, and payload is a sequence of
blocks containing the message which is being delivered down the
tunnel. Here 'block' is any string which the symmetric block cipher
can operate on. The preIV and the payload are successively wrapped
in layers of encryption as a message travels down an inbound tunnel,
and messages are successively unwrapped for outbound tunnels.
Encryption at hop i:
1. Drop packet (with warning) if we've seen preIV before
for a previous message in this tunnel [3].
2. IV := hash(preIV + hop i's secret key 1)
3. preIV := ecb_encrypt(preIV, hop i's secret key2)
4. payload:= cbc_encrypt(payload, hop i's secret key3, IV)
5. Return {preIV, payload}.
Decryption at hop i:
1. preIV := ecb_decrypt(preIV, hop i's secret key2)
2. IV := hash(preIV + hop i's secret key1)
3. payload:= cbc_decrypt(payload, hop i's secret key3, IV)
4. Return {preIV, payload}.
Inbound tunnel:
* Message M arrives at the inbound gateway, aka hop 1.
* Hops 1, 2, ..., N successively encrypt.
* We are the tunnel endpoint, and we have everyone's secret keys,
so we can use decrypt(N), decrypt(N-1), ...decrypt(1) to unwrap
the encryption made by others. We recover message M.
Outbound tunnel:
* We have a message M we want to send.
* We are the tunnel creator, so we have
Re: [i2p] Tunnel cryptography for I2P 0.5 (corrected typo)
Thanks Connelly for the writeup and the discussion, The following is a discussion of tunnel cryptography plans for I2P 0.5. There are two options; one will be chosen. A few key changes were missed in this draft, and I've incorporated all of the suggestions from yesterday into [1]. The explanation of the overall rationale for the two different strategies is largely correct. This is still a work in progress, and will be improved as we get both more feedback and clarify some issues. [1]http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt.html?rev=HEAD An implementation of the crypto for first strategy [2] has been created [3], but as there are some weaknesses in inbound tunnels when dealing with colluding attackers who also control the gateway, the second strategy seems more appealing. Next up I'd like to get that implemented into code so that any further issues can be fleshed out, as well as to make concrete what it is that is being specified. [2]http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel.html?rev=HEAD [3]http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/java/src/net/i2p/router/tunnel/ Of course, none of those html docs are a finished spec for I2P overall as they assume familiarity with the other non-tunnel-related parts of I2P and do not include the relevent references to where we snagged our ideas ;) This is just a state-of-the-design view into the 0.5 tunnel revamp. Anyway, thanks again for the updates Connelly, and if anyone is looking for the details currently planned for, please see [1]. Suggestions/comments/criticisms always welcome, or if you want to get involved, please get in touch! We're in #i2p on irc.freenode.net and on irc.duck.i2p pretty much all the time. =jr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Webpay system open to voucher fraud
http://www.theregister.co.uk/2005/01/17/webpay_voucher_fraud/print.html The Register Biting the hand that feeds IT The Register » Security » Network Security » Original URL: http://www.theregister.co.uk/2005/01/17/webpay_voucher_fraud/ Webpay system open to voucher fraud By Jan Libbenga (libbenga at yahoo.com) Published Monday 17th January 2005 16:46 GMT Webpay International AG, the market leading payment system for digital content and services in Europe, doesn't offer a flawless micro payment service, at least in the Netherlands, according to Dutch consumer watchdog tv show Kassa and computer weekly Computer Idee. It is relatively easy to manipulate user data required for the Dutch MSN music download site (TV item in Dutch over here (http://cgi.omroep.nl/cgi-bin/streams?/tv/vara/kassa/bb.laatste.asf?start=00:16:24end=00:26:13) ). The payments for that site are handled by Webpay under its original name Firstgate. Firstgate users can buy online vouchers and decide which songs they want to purchase later. Kassa and Computer Idee discovered that these vouchers can be easily purchased by filling in someone else's name and bank details. Users can even add money to their prepaid account, again using details from other users. None of this information is verified by Firstgate. Even though upgrading the account requires a pin code, it isn't necessary to enter the code straight away. The song or album to be purchased can be downloaded immediately. Firstgate, which offers the same service for cable operator Chello, doesn't deny that this kind of fraud is possible, but stresses that that fraudsters can be traced and will be prosecuted. However, the company wasn't too thrilled with the publicity and originally threatened to sue broadcaster VARA. Webpay International licenses its micropayment clickbuy service also to British Telecom, and to Swisscom, which launched Swisscom clickbuy in Q4 2004. -- - 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]
DIMACS Workshop on Theft in E-Commerce: Content, Identity, and Service
CALL FOR PARTICIPATION** * DIMACS Workshop on Theft in E-Commerce: Content, Identity, and Service April 14 - 15, 2005 DIMACS Center, Rutgers University, Piscataway, NJ Organizers: Drew Dean, SRI International, [EMAIL PROTECTED] Markus Jakobsson, Indiana University, [EMAIL PROTECTED] Presented under the auspices of the Special Focus on Communication Security and Information Privacy. On April 14-15, 2005, we will hold a DIMACS workshop at Rutgers University, NJ, on the topic of Theft in E-Commerce. This will include but not be limited to theft of content, of identity, and of service. While theft is an old problem, the automated nature of e-commerce introduces new opportunities for traditional forms of theft, as well as entirely new forms of theft. The centrality of computation makes these threats a part of computer security. This is an area of research where we are seeing a lot of activity, and where we believe there is a great potential for valuable research contributions. While our primary interest is in defenses against theft, we are also interested in novel attacks and real data about attacks, as the defenders need to know what to defend against. For more information about the workshop location, organization, and the program (once finalized), please see: http://dimacs.rutgers.edu/Workshops/Intellectual/ We are soliciting contributions in these areas, for both long and short presentations (approx 30 minutes vs 10 minutes.) There are no proceedings, but we request that presentation material is submitted to the organizers at the time of the workshop, allowing it to be posted on the DIMACS webpage. In order to propose a talk, please contact one of the organizers, Markus Jakobsson ([EMAIL PROTECTED]) or Drew Dean ([EMAIL PROTECTED]) with a title and a short abstract by February 28, 2005 that allows us to determine whether your proposed talk will fit within the scope of the workshop. Please refer to the information on the webpage above for workshop registration, hotel reservation and travel information, and information on how to apply for financial support for those in need of this. There will be a limited number of scholarships to defray travel costs, with priority given to students and speakers who can not receive funding to attend. The workshop is sponsored by RSA Security. ** Registration: Pre-registration deadline: April 7, 2005 Please see website for registration information. * Information on participation, registration, accomodations, and travel can be found at: http://dimacs.rutgers.edu/Workshops/Intellectual/ **PLEASE BE SURE TO PRE-REGISTER EARLY** - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Word and Excel have RC4 flaw, claim
http://www.theinquirer.net/print.aspx?article=20790print=1 Word and Excel have RC4 flaw, claim Cryptic cross words By: Nick Farrell Wednesday 19 January 2005, 07:50 SECURITY EXPERT Bruce Schneier claims that Microsoft's Word and Excel security protection systems have amateurish flaws which makes them easy to break. On his blog here, the writer of 'Applied Cryptography' said that VoleWare breaks one of the most important rules of stream ciphers. That is that you don't use the same keystream to encrypt two different documents. If someone does, you can break the encryption by XORing the two ciphertext streams together. The keystream drops out, and you end up with plaintext XORed with plaintext -- and you can easily recover the two plaintexts using letter frequency analysis and other basic techniques, he said. Word and Excel both use this amateur crypto mistake Apparently Microsoft made the same mistake in 1999 with RC4 in WinNT Syskey. Five years later, Microsoft has the same flaw in other products, Schneier claims. µ -- - 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]
Schneier on Security: Microsoft RC4 Flaw
http://www.schneier.com/blog/archives/2005/01/microsoft_rc4_f.html Bruce Schneier Schneier on Security A weblog covering security and security technology. January 18, 2005 Microsoft RC4 Flaw One of the most important rules of stream ciphers is to never use the same keystream to encrypt two different documents. If someone does, you can break the encryption by XORing the two ciphertext streams together. The keystream drops out, and you end up with plaintext XORed with plaintext -- and you can easily recover the two plaintexts using letter frequency analysis and other basic techniques. It's an amateur crypto mistake. The easy way to prevent this attack is to use a unique initialization vector (IV) in addition to the key whenever you encrypt a document. Microsoft uses the RC4 stream cipher in both Word and Excel. And they make this mistake. Hongjun Wu has details (link is a PDF). In this report, we point out a serious security flaw in Microsoft Word and Excel. The stream cipher RC4 [9] with key length up to 128 bits is used in Microsoft Word and Excel to protect the documents. But when an encrypted document gets modified and saved, the initialization vector remains the same and thus the same keystream generated from RC4 is applied to encrypt the different versions of that document. The consequence is disastrous since a lot of information of the document could be recovered easily. This isn't new. Microsoft made the same mistake in 1999 with RC4 in WinNT Syskey. Five years later, Microsoft has the same flaw in other products. Posted on January 18, 2005 at 09:00 AM -- - 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]
Consumer-Electronics Firms Join To Develop Antipiracy Software
http://online.wsj.com/article_print/0,,SB110609171910929502,00.html The Wall Street Journal January 19, 2005 Consumer-Electronics Firms Join To Develop Antipiracy Software By DON CLARK Staff Reporter of THE WALL STREET JOURNAL January 19, 2005; Page D5 Some of the biggest consumer-electronics companies are jointly developing new technology to control how consumers use digital content in the home. The companies -- Sony Corp., Samsung Electronics Co., Philips Electronics NV and Matsushita Electric Industrial Co., maker of Panasonic-brand products -- today are announcing what they are calling the Marlin Joint Development Association. The group, which includes a Silicon Valley company called Intertrust Technologies Corp., plans to develop standard specifications for software that can prevent digital movies and music from being improperly copied. It also intends to enforce rules about how such content can be played and shared. Fears of piracy have discouraged content owners from allowing some high-definition video and other digital programming from being distributed in the home. Makers of devices such as digital recorders and DVD players, meanwhile, are worried about adopting incompatible antipiracy technologies, which could mean a protected movie or song might play on one gadget but not another. Such technology is known by the acronym DRM, for digital rights management. Microsoft Corp. has been trying to get hardware makers to use its proprietary DRM software. Other companies, such as Apple Computer Inc., have developed such technology for their own products. A confusing array of joint DRM projects have also popped up, addressing specific problems such as video on a new-generation of disks that are expected to succeed DVDs. What makes Marlin different, backers say, is mainly that it is emanating from some of the biggest brands in consumer electronics. The CE industry has been pretty quiet, said Talal Shamoon, Intertrust's chief executive. Now, they are detonating their DRM, he said. But Michael McGuire, an analyst at Gartner Inc., noted that the new effort has yet to show it will win support from content holders, such as movie studios. The proliferation of DRM efforts also could confuse consumers. If I'm a user, I'm wondering, is this going to make things more complicated for me? Mr. McGuire said. Some of Marlin's current members also are likely to consider multiple DRM options. Sony, for example, said it is too early to say whether it will favor Marlin over its proprietary DRM technologies. We are actively evaluating opportunities to use Marlin, said Mack Araki, a Sony spokesman. But I can't comment on specific plans today. Marlin comes on the heels of an earlier joint effort, called the Coral Consortium, that had some common members with Marlin. Coral, however, was designed to let different DRM programs work together, rather than establish a specific piece of software as a standard for hardware companies to adopt, Mr. Shamoon said. Both efforts were partly based on technology developed by Intertrust, a company that was jointly purchased in 2003 by Sony, Philips and other investors. Success of earlier such efforts has been mixed. While DRM systems usually make piracy more difficult, hackers have successfully cracked some high-profile protection schemes, including FairPlay, the copy-protection software Apple uses for music it sells through its iTunes Music Store. -- - 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]
DIMACS Workshop on Bounded Rationality
Registration Deadline: January 24, 2005** * 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 but in the last few decades a number of game theorists have argued 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 proposed formalizations of partially or boundedly rational players and games played by such players. If one takes the view that a process of decision-making in economic or other social situations constitutes 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? 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. Topics of interest include: * Bounded recall and bounded complexity in repeated games * Strategic aspects of machine learning * Game theoretic applications of cryptography ** Program: This is a preliminary program. Monday, January 31, 2005 8:15 - 8:50 Breakfast and Registration 8:50 - 9:00 Welcome and Opening Remarks Fred Roberts, DIMACS Director 9:00 - 10:00 Correlation, Communication, Complexity and Competition Abraham Neyman, Hebrew University 10:00 - 10:30 Break 10:30 - 11:30 Olivier Gossner, TBA 11:30 - 12:30 Players as Serial or Parallel Random Access Machines Timothy Van Zandt, INSEAD 12:30 - 2:00 Lunch 2:00 - 3:00 Michael Kearns, University of Pennsylvania, TBA 3:00 - 3:30 Break 3:30 - 4:30 Deterministic Calibration and Nash Equilibrium Sham Kakade, University of Pennsylvania 4:30 - 5:30 For Bayesian Wannabees, Are Disagreements not About Information? Robin Hanson, George Mason University 6:00 Dinner - DIMACS Lounge Tuesday, February 1, 2005 8:30 - 9:00 Breakfast and Registration 9:00 - 10:00 Algorithms for Graphical Games Luis Ortiz, MIT 10:00 - 10:30 Break 10:30 - 11:30 Deterministic Calibration with Simpler Checking Rules Dean Foster, University of Pennsylvania 11:30 - 1:00 Lunch 1:00 - 2:00 Mechanism Design and Deliberative Agents Kate Larsen, University of Waterloo 2:00 - 2:30 Break 2:30 - 3:30 Vahab Mirrokni, MIT, Convergence Issues in Competitive Games 3:30 - 4:30 Efficient Equilibrium Algorithms for Compact Repeated Games Michael Littman, Rutgers University ** 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]
Tor 0.0.9.3 is out (fwd from [EMAIL PROTECTED])
--- begin forwarded text Date: Sat, 22 Jan 2005 10:01:46 +0100 From: Eugen Leitl [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Tor 0.0.9.3 is out (fwd from [EMAIL PROTECTED]) User-Agent: Mutt/1.4i Sender: [EMAIL PROTECTED] From: Roger Dingledine [EMAIL PROTECTED] Subject: Tor 0.0.9.3 is out To: [EMAIL PROTECTED] Date: Sat, 22 Jan 2005 01:54:42 -0500 Reply-To: [EMAIL PROTECTED] Tor 0.0.9.3 improves cpu usage, works better when the network was recently offline and you try to use Tor, and makes hidden services less unbearable. http://tor.eff.org/download.html o Bugfixes on 0.0.9: - Backport the cpu use fixes from main branch, so busy servers won't need as much processor time. - Work better when we go offline and then come back, or when we run Tor at boot before the network is up. We do this by optimistically trying to fetch a new directory whenever an application request comes in and we think we're offline -- the human is hopefully a good measure of when the network is back. - Backport some minimal hidserv bugfixes: keep rend circuits open as long as you keep using them; actually publish hidserv descriptors shortly after they change, rather than waiting 20-40 minutes. - Enable Mac startup script by default. - Fix duplicate dns_cancel_pending_resolve reported by Giorgos Pallas. - When you update AllowUnverifiedNodes or FirewallPorts via the controller's setconf feature, we were always appending, never resetting. - When you update HiddenServiceDir via setconf, it was screwing up the order of reading the lines, making it fail. - Do not rewrite a cached directory back to the cache; otherwise we will think it is recent and not fetch a newer one on startup. - Workaround for webservers that lie about Content-Encoding: Tor now tries to autodetect compressed directories and compression itself. This lets us Proxypass dir fetches through apache. -- -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature] --- 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]
New Scientist article: Wireless boom is hackers' heaven
[From: http://www.newscientist.com/article.ns?id=dn6894] Setting up a wireless computer network at home has never been easier or cheaper. But the freedom to access the internet from anywhere in or around the house comes at a cost: Wi-Fi networks leave home computer users open to unprecedented levels of security breaches. Wi-Fi's radio signals carry up to 100 metres, and anyone within range can pick them up. That is good news if you want to take your laptop into the garden and connect to the net from there. But radio waves are no respecters of household boundaries, and that can leave the network wide open to an intruder operating a Wi-Fi PC from a neighbouring house, or sitting in a car outside. Most Wi-Fi networks come with security features to prevent this. But they are not always easy to implement, so many users do not bother. And with Wi-Fi sales rocketing (see graph), this carefree approach is worrying security experts. For an example of what could go wrong, consider the case of a man who was arrested in Toronto 12 months ago after committing a minor traffic offence. It turned out he had been driving around looking for unsecured domestic networks that he then used to access paedophile websites via his Wi-Fi laptop. If he had not been caught in the act, the trail of evidence would have led instead to the people whose networks he had hijacked. Firewall software Domestic Wi-Fi networks are centred on a box called a wireless router, which is usually connected directly to a broadband modem to give access to the internet. The router uses a low-power radio signal to transmit and receive data through Wi-Fi transceiver cards installed in computers anywhere in the house. Wireless routers come with a battery of built-in security features. To prevent people hacking in from the net they run firewall software that blocks off attempts to gain access via the modem. On the Wi-Fi network side, encryption can be used to scramble the radio dialogue between the router and the computers. This should prevent eavesdroppers reading emails, documents or any other material as it passes round the network. The router can also be set up to ensure that only computers authorised by the user are able to use the network. At least, that is the theory. In reality many Wi-Fi users are not bothering to activate these features after completing the daunting process of getting Wi-Fi up and running, says Ollie Whitehouse of Symantec Antivirus in London, UK. Others are failing to change the default passwords set by manufacturers - passwords that all hackers know. Ross Anderson of the University of Cambridge, UK, says it is simpler for the home user to run a Wi-Fi network on the security defaults that are set when it comes out of the box. The software that comes with Wi-Fi cards and routers is often complicated to configure, and turning on the encryption can stop the network working unless people know what they are doing. Wi-Fi cellphones And it is not just home users who are leaving themselves wide open. Consultancy firm KPMG says that around 70% of the Wi-Fi networks on commercial premises it polled in 2002 were not encrypted, leaving companies vulnerable to email snooping, password pilfering and data theft. Phone calls could also be vulnerable to eavesdropping. People are increasingly using voice over IP (VOIP) software to make phone calls over the internet via their computer headsets. The danger can only increase when Wi-Fi enabled mobile phones - which can be used to make free VOIP calls when in range of a Wi-Fi network - come onto the market this year. Security experts say that the solution lies in educating people about the risks involved in going wireless, and making the software to protect them easier to use. Blaming the consumer is wrong. Computers are too complex for the average person to secure. It's the fault of the network, the operating system and the software vendors, says California-based cryptographer Bruce Schneier in the US. Products need to be secure out of the box, he says. Unless security is improved, new breeds of computer virus that target the multiple devices connected to Wi-Fi networks are likely to emerge, says Mikko Hypponen of Finnish security firm F-Secure. A virus picked up via email could, for instance, disable a Wi-Fi cellphone or perhaps divert calls to others on its owner's contacts list. Schneier is pessimistic. When convenience and features are in opposition to security, security generally loses. As wireless networks become more common, security will get worse. Regards, Jim Cheesman - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
PET 2005 Submission deadline approaching (7 Feb) and PET Award (21 Feb)
--- begin forwarded text To: sec-lists: ;, anonymity researchers: ;, David Martin [EMAIL PROTECTED] Date: Tue, 25 Jan 2005 15:05:55 + From: George Danezis [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: PET 2005 Submission deadline approaching (7 Feb) and PET Award (21 Feb) Sender: [EMAIL PROTECTED] Dear Colleagues, The submission deadline for the Privacy Enhancing Technologies workshop (PET 2005) is on the 7th February 2005. The latest CfP is appended. We also solicit nominations for the Award for Outstanding Research in Privacy Enhancing Technologies by February 21. For more information about suggesting a paper for the award: http://petworkshop.org/award/ Yours, George Danezis 5th Workshop on Privacy Enhancing Technologies Dubrovnik, CroatiaMay 30 - June 1, 2005 C A L L F O R P A P E R S http://petworkshop.org/2005/ Important Dates: Paper submission: February 7, 2005 Notification of acceptance: April 4, 2005 Camera-ready copy for preproceedings: May 6, 2005 Camera-ready copy for proceedings: July 1, 2005 Award for Outstanding Research in Privacy Enhancing Technologies Nomination period: March 4, 2004 through March 7, 2005 Nomination instructions: http://petworkshop.org/award/ --- Privacy and anonymity are increasingly important in the online world. Corporations, governments, and other organizations are realizing and exploiting their power to track users and their behavior, and restrict the ability to publish or retrieve documents. Approaches to protecting individuals, groups, but also companies and governments from such profiling and censorship include decentralization, encryption, distributed trust, and automated policy disclosure. This 5th workshop addresses the design and realization of such privacy and anti-censorship services for the Internet and other communication networks by bringing together anonymity and privacy experts from around the world to discuss recent advances and new perspectives. The workshop seeks submissions from academia and industry presenting novel research on all theoretical and practical aspects of privacy technologies, as well as experimental studies of fielded systems. We encourage submissions from other communities such as law and business that present their perspectives on technological issues. As in past years, we will publish proceedings after the workshop in the Springer Lecture Notes in Computer Science series. Suggested topics include but are not restricted to: * Anonymous communications and publishing systems * Censorship resistance * Pseudonyms, identity management, linkability, and reputation * Data protection technologies * Location privacy * Policy, law, and human rights relating to privacy * Privacy and anonymity in peer-to-peer architectures * Economics of privacy * Fielded systems and techniques for enhancing privacy in existing systems * Protocols that preserve anonymity/privacy * Privacy-enhanced access control or authentication/certification * Privacy threat models * Models for anonymity and unobservability * Attacks on anonymity systems * Traffic analysis * Profiling and data mining * Privacy vulnerabilities and their impact on phishing and identity theft * Deployment models for privacy infrastructures * Novel relations of payment mechanisms and anonymity * Usability issues and user interfaces for PETs * Reliability, robustness and abuse prevention in privacy systems Stipends to attend the workshop will be made available, on the basis of need, to cover travel expenses, hotel, or conference fees. You do not need to submit a technical paper and you do not need to be a student to apply for a stipend. For more information, see http://petworkshop.org/2005/stipends.html General Chair: Damir Gojmerac ([EMAIL PROTECTED]), Fina Corporation, Croatia Program Chairs: George Danezis ([EMAIL PROTECTED]), University of Cambridge, UK David Martin ([EMAIL PROTECTED]), University of Massachusetts at Lowell, USA Program Committee: Martin Abadi, University of California at Santa Cruz, USA Alessandro Acquisti, Heinz School, Carnegie Mellon University, USA Caspar Bowden, Microsoft EMEA, UK Jean Camp, Indiana University at Bloomington, USA Richard Clayton, University of Cambridge, UK Lorrie Cranor, School of Computer Science, Carnegie Mellon University, USA Roger Dingledine, The Free Haven Project, USA Hannes Federrath, University of Regensburg, Germany Ian Goldberg, Zero Knowledge Systems, Canada Philippe Golle, Palo Alto Research Center, USA Marit Hansen, Independent Centre for Privacy Protection Schleswig-Holstein, Germany Markus Jakobsson, Indiana University at Bloomington, USA Dogan Kesdogan, Rheinisch-Westfaelische Technische Hochschule Aachen, Germany Brian Levine, University of Massachusetts at Amherst, USA Andreas Pfitzmann, Dresden University of Technology, Germany Matthias Schunter, IBM Zurich Research Lab, Switzerland Andrei Serjantov, The Free
Sleuthing Spyware--And Its Corporate Sponsors
http://www.forbes.com/2005/01/19/cx_pp_0120spyedelman_print.html Forbes Software Sleuthing Spyware--And Its Corporate Sponsors Penelope Patsuris, 01.19.05, 5:34 PM ET Benjamin Edelman became a spyware expert before most of us had any idea what was even clogging our computers. He's currently a candidate for a doctorate in economics at Harvard University and a Harvard Law student, but his work is hardly academic. Edelman, 24, has built a cottage industry documenting the nefarious ways of the spyware and adware industries, which he contends are one and the same. His extensive Web site is packed with the kind of hard evidence--screenshots and videos--that's required to combat the deception he says has been employed by companies like Claria, 180solutions, WhenU and DirectRevenue to make a buck. Each of these companies denies any wrongdoing, except DirectRevenue, whose spokesman had no comment. Many of Edelman's opponents say his accusations are self-serving, since he has at times worked for companies suing adware outfits. Edelman has lots of litigation experience despite his young age, having consulted for and testified on behalf of organizations like the ACLU, the National Association of Broadcasters and the National Football League. In 2002 he testified on behalf of a group of media outfits, including The New York Times Co. (nyse: NYT - news - people ), The Washington Post's (nyse: WPO - news - people ) interactive unit and Dow Jones (nyse: DJ - news - people ), in their lawsuit against adware outfit Gator--now named Claria. The suit claimed, among other things, that Gator's pop-up ads were unlawfully obscuring the media companies' own online content. The suit was settled under confidential terms in February 2003. Edelman doesn't just take on the makers of spyware--he outs the big-name companies that support them. In June 2004, he posted a list of WhenU advertisers, including J.P. Morgan Chase (nyse: JPM - news - people ), Verizon Communications (nyse: VZ - news - people ), Merck (nyse: MRK - news - people ) and T-Mobile. Advertisers react to the finger-pointing with varying degrees of concern. Verizon says that it no longer uses WhenU, while a spokesman for T-Mobile says that he hasn't received any complaints about the WhenU ads and that WhenU is opt-in and it can be removed easily. Repeated calls to Merck and J.P. Morgan Chase were not returned. Edelman's Web page also accuses WhenU of transmitting the browsing activity of its users back to the company, a practice that he says WhenU's privacy policy specifically promises not to engage in. He also writes that WhenU has spammed search giant Google (nasdaq: GOOG - news - people ). WhenU President Avi Naider says Edelman is wrong. In the past Mr. Edelman has made statements about WhenU that drew incorrect conclusions about WhenU and were legally inappropriate, says Naider. We take our privacy protection very seriously. He adds that WhenU's privacy policy has been audited by Microsoft's (nasdaq: MSFT - news - people ) former chief privacy officer, Richard Purcell, who is chairman of TRUSTe, a nonprofit online-privacy organization. Perhaps what's most interesting on Edelman's Web site is a video dated Nov. 18, 2004, which depicts roughly 25 different adware programs, including 180solutions, that download via security holes onto his browser. Todd Sawicki, 180's director of marketing, says that his company is taking various steps to prevent this kind of thing from happening, but that unfortunately, where there is money, the bad guys will follow. Edelman's biggest beef with Claria: Their license fails to prominently disclose the fact that they are collecting and storing information about what users do online, he says. But when you read the Claria installer, it never tells you, 'We collect information.' Instead it says, 'We show you ads that are based on where you visit.' Claria Chief Marketing Officer Scott Eagle says the company's updated user agreement clarifies that point, but admits that the update isn't presented to many users that get Claria when they download free software like Kazaa. Indeed, Claria said in an S-1 filing with the U.S. Securities and Exchange Commission--since withdrawn--that it gets most of its users via Kazaa. Still, Eagle questions Edelman's motives, saying he's worked for companies that are suing Claria. (Edelman did work for Teleflora, which has a case against Claria, but he no longer does.) Edelman counters, My clients don't hire me to help them with litigation against Claria because I'm a big fan. The Harvard student also takes Claria advertisers to task, posting a screen shot of a British ad for Dell (nasdaq: DELL - news - people ) that appeared on his PC via Claria when he was browsing IBM's (nyse: IBM - news - people ) Web site. Edelman notes the irony that Dell has been quite vocal about the burden that the spyware boom has placed on its own
