Re: The Pointlessness of the MD5 'attacks'
This isn't worked out enough to be a proof of concept, but I can imagine a piece of code that has a comment This can't overflow because value X computed from the magic bits table will always be between A and B. Get 0.1% speed boost by leaving out range check here but don't change magic bits. That doesn't even have to be so obscure. It provides a place to introduce a security hole that will not be noticed by substituting a new magic bits table without the protective property. Unless someone takes their copy of the source code that has MD5 equal to the MD5 of the sources that have been reviewed by the experts and verifies for themselves whether their magic bits table does compute a value X between A and B, they are vulnerable. If MD5 is trusted, there is no reason to audit every downloaded copy of the source code like that, as long as you are sure that someone has done the audit. -- sidney http://www.sidney.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
The Pointlessness of the MD5 attacks
Ben Laurie writes: Dan Kaminsky's recent posting seems to have caused some excitement, but I really can't see why. In particular, the idea of having two different executables with the same checksum has attracted attention. But the only way I can see to exploit this would be to have code that did different things based on the contents of some bitmap. My contention is that if the code is open, then it will be obvious that it does something bad if a bit is tweaked, and so will be suspicious, even if the something bad is not triggered in the version seen. So, to exploit this successfully, you need code that cannot or will not be inspected. My contention is that any such code is untrusted anyway, so being able to change its behaviour on the basis of embedded bitmap changes is a parlour trick. You may as well have it ping a website to find out whether to misbehave. I guess I disagree. Imagine that the code has some block cipher with some S-boxes hardcoded into it. The code uses this block cipher to decrypt an associated ciphertext and outputs (or takes some action based on) the resulting message. This is an example of code that could be used to fool a MD5 checksum. Moreover, I don't have a great deal of confidence that even a careful code inspection would cause the code to be considered suspicious. Consequently, I don't have great confidence that such an attack would be detected. I know it is tempting to think that, look, Wang et al only found a pair of random-looking messages that collide; they didn't claim to find a pair of meaningful messages that collide; and maybe we can hope that there is no way to come up with a pair of meaningful-looking colliding messages. But I think that kind of hope is unfounded, and acting on hope is asking for trouble. I believe the only safe course now is to assume that MD5's collision resistance is totally broken. If Wang et al can find meaningless-looking collisions today, it seems all too likely that someone else may be able to find meaningful-looking collisions tomorrow. Hoping that the latter will be hard even though the former is known to be easy seems too optimistic for my tastes. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
The Pointlessness of the MD5 attacks
Ben Laurie writes: Indeed, but what's the point? If you control the binary, just distribute the malicious version in the first place. Where this argument breaks down is that someone might have partial but not total control over the binary. This partial control might not be enough for them to distribute a malicious version straightforwardly, but just enough to exploit a MD5 collision. It is hard to be confident that such an attack scenario is impossible. To give one contrived example, imagine that the Windows 2010 binary comes with an image file that is displayed as part of the splash start screen. Imagine that the graphic designer is allowed to supply that image, but the graphic designer has no other authorized access to the source or binary of Windows. Now a disgruntled graphic designer might be able to arrange to find a MD5 collision MD5(img1) = MD5(img2) so that img1 looks like an entirely reasonable Windows splash screen, but img2 contains some scrawled epithet (Tired of Windows crashing all the time? Try Linux!). Or, even more contrived, imagine that img1.jpg looks like a completely normal JPG file, but img2.jpg exploits some buffer overrun in the startup screen's JPG decoder to overwrite the program's image with some other malicious code. Sure, these scenarios are contrived and unlikely. But how do you know that there is not some other (possibly more complex but less contrived) scenario that you would consider more troubling? People seem to be having a hard time grasping what I'm trying to say, so perhaps I should phrase it as a challenge: find me a scenario where you can use an MD5 collision to mount an attack in which I could not mount an equally effective attack without using an MD5 collision. I've got a better challenge: show me a convincing argument that no such scenario exists. What I'm trying to get at is that you've got the burden of proof backwards. Implicit in your challenge is the idea that we should keep trusting MD5 until someone finds a convincing argument that it is insecure in practice. My argument is that this is much too trusting. I believe that, given the theoretical results on MD5, we should not have any trust whatsoever in the security of MD5 as a collision-resistant hash until someone is able to offer a convincing argument that MD5 is secure enough in practice despite its known weaknesses. I could try to answer your challenge. I might even be able to devise some solution to your challenge that would satisfy you. For instance, maybe the image file attack above qualifies as a solution. Or maybe the S-box table attack in my previous email is good enough. But I don't really want to argue about whether I have found a valid answer to your challenge. I shouldn't be required to meet that burden -- the burden of proof should be on whoever wants to believe that MD5 is secure. Why should the burden be on MD5 defenders? Not just because I said so. Part of the reason is that there are just too many complex scenarios to consider. Suppose I conceded that I couldn't find a scenario you'd accept. What would that prove? Very little. Even if I can't think of a suitable scenario for you off the top of my head, that doesn't mean that with more thought I wouldn't find one. Even if I spent a month trying and still couldn't find one, that doesn't mean that others can't. My experience is that if it is possible to find a theoretical attack with one day's work, it is often possible to extend this to a more practical attack with, say, one week's work. Bruce Schneier puts this concisely: Attacks always get better. Trusting in MD5's collision-resistance amounts to assuming that cryptanalysts of MD5 will get this far, but no farther, and that seems like a pretty questionable assumption to me. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The Pointlessness of the MD5 'attacks'
On Wed, 15 Dec 2004, Tim Dierks wrote: Here's an example, although I think it's a stupid one, and agree with [...] I send you a binary (say, a library for doing AES encryption) which you test exhaustively using black-box testing. The black-box testing would obviously be the mistake. How can you tell that the library doesn't start sending plain-text for messages which start with a particular magic bytes, or some other evilness? You can't hope to test *all* messages. The word 'exhaustively' is where your example goes wrong. I'll play Ben's part and claim that if you can provide a library which will *only* be checked using black-box testing, it's much easier to skip the whole MD5 aspect and have it use a covert channel (leak key bits in padding or some such) or transmit plain-text after the first 100M of data encrypted or some such. There are lots of easy ways to get your maliciousness past a black-box test. The use of MD5 (a relatively *hard* way to be malicious) doesn't appreciably change the threat. --scott [it should be noted that any security-conscious tester will/ought to screen your binary for all of the *published* MD5 collisions, so you'll have to generate one yourself if you want to get away with this.] HTLINGUAL Hager Kennedy AEFOXTROT global action network assassinate Register to vote! http://www.yourvotematters.org/VerifiedVoting ( http://cscott.net/ ) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The Pointlessness of the MD5 attacks
John Kelsey wrote: So, to exploit this successfully, you need code that cannot or will not be inspected. My contention is that any such code is untrusted anyway, so being able to change its behaviour on the basis of embedded bitmap changes is a parlour trick. You may as well have it ping a website to find out whether to misbehave. So, are you sure there can never be a program which allows such an exploit? I've seen programs that had embedded components (state machines in particular) which were not easily human-readable, and had themselves been generated by computer. And even large graphics, sound, or video sequences can really change the meaning of a program's actions in some ways; those might be susceptible to the requirements of the attack. I agree it's hard to see how to exploit the existing MD5 collision attacks in programs that would look innocent, but I don't see what makes it *impossible*. I did not say it was impossible, I said that such exploits would work just as well without MD5 collisions. For example, if you are going to trigger on some subtle distinction such as a single bit flipped, then make that a bit in a counter, or a bit in the input stream. Then you have data files, as Adam Back mentioned, which are often not human readable, but you'd still like to know if the signature on them is valid, or if they've been changed surreptitiously since the last time they were checked over. Finally, I'm very skeptical that the attacks that have been found recently are the best or only ones that can be done. Do we have any special reason to think that there will never be a way to adapt the attack to be able to slip something plausible looking into a C program? Once your hash function starts allowing collisions, it really just becomes a lot less valuable. I do not have a special reason to think anything about future attacks on MD5. I am discussing the present attacks. 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]
Re: The Pointlessness of the MD5 attacks
Jay Sulzberger wrote: On Tue, 14 Dec 2004, Ben Laurie wrote: Ondrej Mikle wrote: [snipped many assertions without supporting evidence that MD5 cracks improve attacks] So, to exploit this successfully, you need code that cannot or will not be inspected. My contention is that any such code is untrusted anyway, so being able to change its behaviour on the basis of embedded bitmap changes is a parlour trick. That's true in theory, but it's different in real world. Take Microsoft software as an example. Many banks use their software (and sometimes even military). I don't think that all of them reviewed Microsoft's source code (I guess only a few, if any at all). There was an incident of a worm attacking ATMs. No, and they are therefore vulnerable to Microsoft. Note that MD5 is not required for Microsoft to attack them. Again, the MD5 crack helps. Here one attack is obvious: third parties may more easily make substitutions of code. No, they may not. This crack does _not_ allow a third party to do anything interesting. Another example, Enigma was being sold after WW 2, but the Allies knew it could be broken. The purchasers did not. Same as when US army sold some radio communications that used frequency hopping to Iraq during 1980's. US knew that it could be broken (just in case...). And MD5 helps with this how? Cheers, Ben. The MD5 crack helps here in several ways. Perhaps the most important is that if MD5 is thought to be uncracked, that simple MD5 checking might be considered so safe that no second check is used, at points where a second and third check would help, thus opening up a possible avenue of attack. You are simply restating the supposed attack here, without providing any evidence it is useful. Indeed, even before MD5 was widely known to be cracked, competent security folk often recommended that several hashes be used since in most applications the cost of computing hashes is small. This is true, but not germane. One point to remember is that the published cracks are likely only a small part of the cracks known to well funded professionals. The parallel to the case of the weak Enigmas is that many people buying the weak Enigmas thought they were uncracked, else they would not have bought them. Despite the recent published MD5 cracks, it is clear that the most interesting cracks of MD5 are as yet unpublished. Again, probably true, but definitely not germane. I am saying nothing about what future MD5 cracks may enable, I am only commenting on the cracks currently known. To be clear, I am not advocating the use of MD5, nor have I for many years. I am simply contesting the theory that the ability to produce collisions, as currently known[1], actually provides any useful attack vectors. Cheers, Ben. [1] I agree, future possible methods of producing collisions are likely to have a real impact on security. This is not what I am discussing. -- 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]
Re: Cryptography Research wants piracy speed bump on HD DVDs
What CR does instead is much simpler and more direct. It tries to cut off any player that has been used for mass piracy. Let me get this right. ... When a pirate makes a copy of a film encoded as SPDC, the output file is cryptographically bound to a set of player decryption keys. So it is easy when looking at a pirated work on a peer to peer network, or any copies found on copied DVDs, to identify which player made those copies, said Laren When the content owner sends out any further content it can contain on it a revocation of just the player that was used to make a pirated copy. A blockbuster worth $100m gets cracked ... and the crack gets watermarked with the Id of the $100 machine that played it. We picture a message popping up on a screen saying something like 'Disney movies won't play on your player any more please call this number for further information.' Or perhaps 'To fix this please call Disney with your credit card,' something like that anyway. So the solution is to punish the $100 machine by asking them to call Disney with a CC in hand? As described this looks like snake oil. Is this for real? iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Fwd: The PoinFULLness of the MD5 'attacks'
For this discussion, I think we are missing the point here... 1. With a rogue binary distribution with correct hash, this is -at least- a denial of service where the customer will install the rogue binary and it will crash in the area that the information was changed. MD5 based Tripwire will not catch this happening if this is done on the distribution machine. 2. If the rogue binary is a driver that gets into the kernel, it could cause a crash and that crash -could- cause a kernel exploit. 3. A modification to an seldom used section of code that can be invoked in some non-typical way can cause a machine to crash on command. 4. Offline, the attacker could automate a trial and error scheme to create random collisions and testing each until one produces an effect to their advantage and then substitute it for the real one. Again, anything that gives the legitimate user a feeling of security (because the hashes match) and allows the attacker to do anything to their advantage is a failure of the MD5 algorithm. Maybe these are low probabilities... Are you willing to step up and say there is nothing that the attacker can ever do using these collisions? I'm not. My suggestion is that all distributions publish the MD5 and SHA-256 hashes for a while and then drop the MD5 based ones in a year or so. thanks jim On Dec 15, 2004, at 10:45 AM, Tim Dierks wrote: On Wed, 15 Dec 2004 08:51:29 +, Ben Laurie [EMAIL PROTECTED] wrote: People seem to be having a hard time grasping what I'm trying to say, so perhaps I should phrase it as a challenge: find me a scenario where you can use an MD5 collision to mount an attack in which I could not mount an equally effective attack without using an MD5 collision. Here's an example, although I think it's a stupid one, and agree with you that the MD5 attack, as it's currently known to work, isn't a material problem (although it's a clear signal that one shouldn't use MD5): I send you a binary (say, a library for doing AES encryption) which you test exhaustively using black-box testing. The library is known not to link against any external APIs (in fact, perhaps it's implemented in a language and runtime with a decent security sandbox model, e.g., Java). You then incorporate it into your application and sign the whole thing with MD5+RSA to vouch for its accuracy. I incorporate several copies of a suitable MD5 collision block in my library, so one of them will be at the correct 64-byte block boundary. I can then modify bits inside of my library, which car checked by the library code and cause it to change the functionality of the library, yet the signature will still verify. This would be pretty easy to do as a proof-of-concept, but I don't have the time. - Tim - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL/TLS passive sniffing
* Victor Duchovni: The third mode is quite common for STARTTLS with SMTP if I am not mistaken. A one day sample of inbound TLS email has the following cipher frequencies: 8221(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) 6529(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) The Debian folks have recently stumbled upon a problem in this area: Generating the ephemeral DH parameters is expensive, in terms of CPU cycles, but especailly in PRNG entropy. The PRNG part means that it's not possible to use /dev/random on Linux, at least on servers. The CPU cycles spent on bignum operations aren't a real problem. Would you recommend to switch to /dev/urandom (which doesn't block if the entropy estimate for the in-kernel pool reaches 0), and stick to generating new DH parameters for each connection, or is it better to generate them once per day and use it for several connections? (There's a second set of parameters related to the RSA_EXPORT mode in TLS, but I suppose it isn't used much, and supporting it is not a top priority.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
DIMACS Workshop on Large-Scale Games at Northwestern University
**Call For Papers * DIMACS Workshop on Large-Scale Games April 17 - 19, 2005 **Location: Evanston Campus, Northwestern University, Evanston, Illinois** Organizers: Lance Fortnow, University of Chicago, [EMAIL PROTECTED] Rakesh Vohra, Northwestern University, [EMAIL PROTECTED] Presented under the auspices of the Special Focus on Computation and the Socio-Economic Sciences. On the Internet we have games with a large number of agents, asynchronous play, and an the absence of full knowledge about the number of agents one is playing against or the beliefs they possess. The Internet is not the only institution to possess these features nor the first. Markets for traditional goods and services as well as travel networks all possess these features. This workshop is devoted to the analysis of large scale games of the kinds inspired by the Internet and other computer networks, markets, traffic networks and other large systems. We invite papers that will show how to adapt and extend classical game theoretic models to deal with a large number of players, accommodate the absence of common knowledge, common priors, asynchrony in play and distributed computation. Examples of the kind of work that would be suitable for this workshop include price of anarchy models, robust and on-line mechanism design, timing games, asymptotic analysis of traditional auctions, continuous double auctions (two-sided markets) and network formation. Please submit an extended abstract or paper (in .pdf form only) to [EMAIL PROTECTED] by January 15, 2005. Include the word `DIMACS' in the subject heading. Acceptance decisions will be made by February 15, 2005. It will consist of 5 invited overview talks (hour long) and a collection of submitted talks (half hour). The overview talks are listed below. This workshop is supported by DIMACS, the Managerial Economics and Decision Sciences Department of the Kellogg School (http://www.kellogg.nwu.edu/meds/index.htm) and Northwestern University's Institute for Complex Systems (http://ccl.northwestern.edu/nico/). The workshop will take place at Northwestern University's Evanston Campus. It will start on the morning of the 17th and end around lunch time on the 19th. OVERVIEW TALKS: * Network and Coalition Formation: Matthew Jackson * Price of Anarchy Models: Tim Roughgarden * Equilibrium Notions for Games with Many Players: Ehud Kalai * Mechanism Design Models without the Common Prior: Jason Hartline * Asymptotic Analysis of Market Mechanisms: Mark Satterthwaite ** Call For Participation: Please submit an extended abstract or paper (in .pdf form only) to [EMAIL PROTECTED] by January 15, 2005. Include the word `DIMACS' in the subject heading. Acceptance decisions will be made by February 15, 2005. ** Registration Fees: (Pre-registration deadline: March 15, 2005) Please see website for additional registration information. * Information on participation, registration, accomodations, and travel can be found at: http://dimacs.rutgers.edu/Workshops/Games/ **PLEASE BE SURE TO PRE-REGISTER EARLY** *** - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Digipass Starts to Make a Mark
http://online.wsj.com/article_print/0,,SB110348908376704197,00.html The Wall Street Journal December 20, 2004 Digipass Starts to Make a Mark Vasco Enhances Online Security As Web Banks Gain Popularity By STEVE DE BONVOISIN DOW JONES NEWSWIRES December 20, 2004 BRUSSELS -- Life-insurance salesman Renaud Bruneels, 34 years old, says he doesn't have time to take care of life's little administrative issues by visiting a bank during regular business hours. The Belgian has solved the problem by becoming one of 12 million users world-wide of Vasco Data Security International Inc.'s Digipass. The pocket-size gadget, which looks like a calculator, lets him use a single password to pay everything from garbage fees to phone bills over the Internet. INSIDE TECH 1 See complete coverage2 of Europe's technology sector, from cellphones to software. It gives me the level of security I need to ... do all my banking transactions, Mr. Bruneels says. Vasco, which is based in Brussels and Chicago, is riding an uptick in online banking -- particularly in Europe, which has moved ahead of the U.S.; the company believes that the U.S. market will take off within the next two years, as banks roll out the service to retail customers. Digipass can be used to access anything online, from bank accounts to secure servers to a corporate intranet. Given a username and password, it issues a one-time code to be used for purchases or transactions on the Web. Because the code only works once, hackers who infiltrate a computer can't use it again. The added level of security sets the Digipass system apart from other online transactions via mobile handsets or laptop computers. Vasco was founded in 1997 by Digipass inventor Jan Valcke, a Belgian, and Ken Hunt, an American who ran an online-authentication software company. But after the Internet bubble burst in 2000, customers hesitated to invest in Internet banking security. Digipass came out a little too early ... when the big focus was on viruses and not on identity theft, said Edward Ching, technology analyst at Rodman Renshaw in New York. The stock fell from a high of $25 (ยค18.81) in February 2000 to under $1 in early 2003, forcing Vasco to delist from Nasdaq's National Market and move on to the SmallCap Market. In 2002, Mr. Hunt took over as chief executive. Vasco switched to just in time production, and spent hundreds of thousands of dollars training resellers to tackle the corporate-access market. In November, the company posted its third consecutive quarterly sales increase. Vasco forecasts 2004 sales will rise between 23% and 25% from $22.87 million in 2003, and on Thursday Vasco said it expects 2005 sales to grow 35% to 45% with gross margins in the range of 60% to 65%. On Friday, Vasco shares fell eight cents to $6.40 in 4 p.m. Nasdaq Stock Market trading. Vasco still faces stiff competition. It has only about $10 million in cash, putting it at a disadvantage against U.S. rival RSA Security Inc., when chasing big contracts. In September, RSA signed a landmark deal with Time Warner Inc.'s America Online service to provide authentication for users signing into their online e-mail accounts. We don't have the brand recognition we deserve, says Mr. Hunt, who admits Vasco wasn't even invited to bid on the Time Warner contract. As a result, the company has increased its presence in trade shows together with partners such as Novell Inc. and Lucent Technologies Inc., and is bringing prospective and current clients together in workshops to help them solve operational problems. More than 100 million households world-wide now bank online, and that number is expected to triple to 300 million or more households by the end of the decade. Europe has taken the lead. About 37% of all Internet users on the Continent bank online, as opposed to 17% in the U.S., according to reports from research firms Gartner and Forrester Research. The number of Europeans carrying out financial transactions on the Net is expected to rise to 130 million by 2007, compared with 67 million Americans. Banks are Digipass's main customers. Digipass is the most secure system available and the one which offers the greatest mobility, said Liliane Tackaert, spokeswoman for Belgo-Dutch banking giant Fortis NV. About 775,000 of the bank's clients in Belgium and Luxembourg use the service. Rabobank, of the Netherlands, Europe's biggest online bank in terms of online customers, has more than two million Digipasses in use. Vasco hopes it will become a lead supplier for the new European EMV payment card next year. Developed jointly by Europay International, MasterCard Inc. and Visa International, the card requires a PIN number in addition to a usual signature when buying goods in a shop, as well as a one-time code -- such as the one generated by Digipass -- to buy goods online or over the phone. In addition to Vasco, Xiring, of Suresnes, France, and U.S.-based ActivCard Corp., Fremont, California, are in the
Re: International meet on cryptology in Chennai
--- begin forwarded text Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys Date: Tue, 21 Dec 2004 00:08:49 -0800 (PST) From: Sarad AV [EMAIL PROTECTED] Subject: Re: International meet on cryptology in Chennai To: R.A. Hettinga [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] --- R.A. Hettinga [EMAIL PROTECTED] wrote: They call it IndoCrypt http://www-rocq.inria.fr/codes/indocrypt2004/ Sarad. __ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com --- 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: SSL/TLS passive sniffing
Florian Weimer wrote: Would you recommend to switch to /dev/urandom (which doesn't block if the entropy estimate for the in-kernel pool reaches 0), and stick to generating new DH parameters for each connection, No, I wouldn't. or ... generate them once per day and use it for several connections? I wouldn't do that, either. If the problem is a shortage of random bits, get more random bits! Almost every computer sold on the mass market these days has a sound system built in. That can be used to generate industrial-strength randomness at rates more than sufficient for the applications we're talking about. (And if you can afford to buy a non-mass-market machine, you can afford to plug a sound-card into it.) For a discussion of the principles of how to get arbitrarily close to 100% entropy density, plus working code, see: http://www.av8n.com/turbid/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Cryptography Research wants piracy speed bump on HD DVDs
On Dec 15, 2004, at 11:54, Taral wrote: What stops someone using 3 players and majority voting on frame data bits? As I understand it, they use such a huge number of bits for marking, that any reasonably-sized assembly of players will still coincide on some marked bits. (However, I very much doubt whether they can blacklist all the players in the assembly without blacklisting some innocent players as well!) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL/TLS passive sniffing
On Sun, Dec 19, 2004 at 05:24:59PM +0100, Florian Weimer wrote: * Victor Duchovni: The third mode is quite common for STARTTLS with SMTP if I am not mistaken. A one day sample of inbound TLS email has the following cipher frequencies: 8221(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) 6529(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) The Debian folks have recently stumbled upon a problem in this area: Generating the ephemeral DH parameters is expensive, in terms of CPU cycles, but especailly in PRNG entropy. The PRNG part means that it's not possible to use /dev/random on Linux, at least on servers. The CPU cycles spent on bignum operations aren't a real problem. Would you recommend to switch to /dev/urandom (which doesn't block if the entropy estimate for the in-kernel pool reaches 0), and stick to generating new DH parameters for each connection, or is it better to generate them once per day and use it for several connections? Actually reasoning along these lines is why Lutz Jaenicke implemented PRNGD, it is strongly recommended (at least by me) that mail servers use PRNGD or similar. PRNGD delivers psuedo-random numbers mixing in real entropy periodically. EGD, /dev/random and /dev/urandom don't produce bits fast enough. Also Postfix internally seeds the built-in OpenSSL PRNG via the tlsmgr process and this hands out seeds for smtp servers and clients, so the demand for real entropy is again reduced. Clearly a PRNG is a compromise (if the algorithm is found to be weak we could have problems), but real entropy is just too expensive. I use PRNGD. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The Pointlessness of the MD5 attacks
David Wagner wrote: Ben Laurie writes: Dan Kaminsky's recent posting seems to have caused some excitement, but I really can't see why. In particular, the idea of having two different executables with the same checksum has attracted attention. But the only way I can see to exploit this would be to have code that did different things based on the contents of some bitmap. My contention is that if the code is open, then it will be obvious that it does something bad if a bit is tweaked, and so will be suspicious, even if the something bad is not triggered in the version seen. So, to exploit this successfully, you need code that cannot or will not be inspected. My contention is that any such code is untrusted anyway, so being able to change its behaviour on the basis of embedded bitmap changes is a parlour trick. You may as well have it ping a website to find out whether to misbehave. I guess I disagree. Imagine that the code has some block cipher with some S-boxes hardcoded into it. The code uses this block cipher to decrypt an associated ciphertext and outputs (or takes some action based on) the resulting message. This is an example of code that could be used to fool a MD5 checksum. Moreover, I don't have a great deal of confidence that even a careful code inspection would cause the code to be considered suspicious. Consequently, I don't have great confidence that such an attack would be detected. Assuming you could find a collision s.t. the resulting decryption looked safe with one version and unsafe with the other (rather than gibberish), which I find an even bigger stretch than the idea that you could find a block that looked safe in one version and unsafe in another, I would have said that the mere fact of using a pointless decryption to control the action of the code would be suspect. I know it is tempting to think that, look, Wang et al only found a pair of random-looking messages that collide; they didn't claim to find a pair of meaningful messages that collide; and maybe we can hope that there is no way to come up with a pair of meaningful-looking colliding messages. That kind of thinking may tempt you, but it doesn't tempt me. I am not discussing what it might be possible to do, I am discussing what it is possibile to do. But I think that kind of hope is unfounded, and acting on hope is asking for trouble. I believe the only safe course now is to assume that MD5's collision resistance is totally broken. I had assumed that years ago. If Wang et al can find meaningless-looking collisions today, it seems all too likely that someone else may be able to find meaningful-looking collisions tomorrow. Hoping that the latter will be hard even though the former is known to be easy seems too optimistic for my tastes. Indeed. Not the point I am making. In a nutshell, yes, it is scary that Wang found collisions. No, it is not _more_ scary that you can use those collisions to fool people who aren't looking anyway. 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]
Re: Do We Need a National ID Card?
On Dec 22, 2004, at 8:53, R.A. Hettinga wrote: Do we need a national ID card? The comment period on NIST's draft FIPS-201 (written in very hasty response to Homeland Security Presidential Directive HSPD-12) ends tomorrow. The draft, as written, enables use of the card by Smart IEDs and for improved selection of kidnapping victims. One cabinet department's Associate CIO for Cybersecurity said of this project, Eventually this is going to lead to a national ID card. Refs: http://csrc.nist.gov/piv-project/ http://www.fas.org/irp/offdocs/nspd/hspd-12.html http://csrc.nist.gov/publications/drafts/draft-FIPS_201-110804- public1.pdf - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The Pointlessness of the MD5 attacks
From: Ben Laurie [EMAIL PROTECTED] Sent: Dec 22, 2004 12:24 PM To: David Wagner [EMAIL PROTECTED] Cc: cryptography@metzdowd.com Subject: Re: The Pointlessness of the MD5 attacks ... Assuming you could find a collision s.t. the resulting decryption looked safe with one version and unsafe with the other (rather than gibberish), which I find an even bigger stretch than the idea that you could find a block that looked safe in one version and unsafe in another, I would have said that the mere fact of using a pointless decryption to control the action of the code would be suspect. Hmm. So maybe I'm missing something. Here's my scenario: a. Alice decides to use GOST for encryption. She finds an implementation in C from Eve, which includes the S-boxes hard-coded in. Note that the specific S-boxes used for GOST are potentially pretty important for their security. b. She also finds a review from some well-known cryptanalyst, Bob, discussing the requirements on the S-boxes, and verifying that the above implementation uses good S-boxes, which includes the md5 hash of the C source code. c. Alice downloads the C source code, and checks the md5 hash. Since the hash is correct, she compiles the code, and starts using her known-secure version of GOST to encrypt sensitive data. d. Unknown to her, though, Eve has slipped in a changed version of the C source code, with the S-boxes changed in a way that makes the encryption much weaker. What prevents this attack from working? Alice counts on a review done by someone competent and a hash of the source code, but the weakness of the hash function means that she's vulnerable to an attack. The only thing that might keep it from working is if it happens to be impossible to choose a pair of sets of S-boxes so that one is weak, the other is strong, and the pair allows an md5 collision. I don't know whether this is possible or not, but there's no inherent reason to think it's impossible--just making some of the 4-bit wide S-boxes in GOST non-bijective has pretty big security implications. (Though 32 rounds covers a lot of sins in S-box selection, in terms of practical attacks rather than academic ones.) ... Indeed. Not the point I am making. In a nutshell, yes, it is scary that Wang found collisions. No, it is not _more_ scary that you can use those collisions to fool people who aren't looking anyway. I think you can use them in ways that may fool people who *are* looking. All you need is a legitimate reason to have a more-or-less arbitrarily chosen block of bits in a part of your program, and then the person reviewing the code says okay, that's random-looking, but reasonable enough. As an alternative example, consider embedding a large prime number in your code, to be used as the modulus when you're doing Diffie-Hellman. Someone reviews the code, and verifies that the number is prime and has all the other required properties. Then, you swap in a different bitstring of equal length, but which is composite and yields a reasonably easy attack on Diffie-Hellman. What prevents this? Ben --John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL/TLS passive sniffing
* Victor Duchovni: The Debian folks have recently stumbled upon a problem in this area: Generating the ephemeral DH parameters is expensive, in terms of CPU cycles, but especailly in PRNG entropy. The PRNG part means that it's not possible to use /dev/random on Linux, at least on servers. The CPU cycles spent on bignum operations aren't a real problem. Would you recommend to switch to /dev/urandom (which doesn't block if the entropy estimate for the in-kernel pool reaches 0), and stick to generating new DH parameters for each connection, or is it better to generate them once per day and use it for several connections? Actually reasoning along these lines is why Lutz Jaenicke implemented PRNGD, it is strongly recommended (at least by me) that mail servers use PRNGD or similar. PRNGD delivers psuedo-random numbers mixing in real entropy periodically. EGD, /dev/random and /dev/urandom don't produce bits fast enough. Is this the only criticism of /dev/urandom (on Linux, at least)? Even on ancient hardware (P54C at 200 MHz), I can suck about 150 kbps out of /dev/urandom, which is more than enough for our purposes. (It's not a web server, after all.) I'm slightly troubled by claims such as this one: http://lists.debian.org/debian-devel/2004/12/msg01950.html I know that Linux' /dev/random implementation has some problems (I believe that the entropy estimates for mouse movements are a bit unrealistic, somewhere around 2.4 kbps), but the claim that generating session keys from /dev/urandom is a complete no-no is rather surprising. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Cryptography Research wants piracy speed bump on HD DVDs
On Wed, Dec 22, 2004 at 10:58:11AM -0600, Matt Crawford wrote: On Dec 15, 2004, at 11:54, Taral wrote: What stops someone using 3 players and majority voting on frame data bits? As I understand it, they use such a huge number of bits for marking, that any reasonably-sized assembly of players will still coincide on some marked bits. (However, I very much doubt whether they can blacklist all the players in the assembly without blacklisting some innocent players as well!) Is there really that much space for marking? Any substantial number of marked bits will become obvious in the output stream, no? -- Taral [EMAIL PROTECTED] This message is digitally signed. Please PGP encrypt mail to me. A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgpCUKLbedBvo.pgp Description: PGP signature
pgp global directory bugged instructions
So PGP are now running a pgp key server which attempts to consilidate the inforamtion from the existing key servers, but screen it by ability to receive email at the address. So they send you an email with a link in it and you go there and it displays your key userid, keyid, fingerprint and email address. Then it says: | Please verify that the email address on this key, [EMAIL PROTECTED], | is your email address, and is properly configured to send and | receive PGP secured email. | | If the information is correct, click 'Accept'. By clicking 'Accept', | your key will be published to the directory, where other PGP users | will be able to retrieve it in order to encrypt messages to you and | verify signed messages from you. | | If this information is incorrect, click 'Cancel'. By clicking | 'Cancel', this key will not be published. You may then submit | another key with the correct information. So here's the problem: it does not mention anything about checking that this is your fingerprint. If it's not your fingerprint but it is your email address you could end up DoSing yourself, or at least perpetuating a imposter key into the new supposedly email validated keyserver db. (For example on some key servers there are keys with my name and email that are nothing to do with me -- they are pure forgeries). Suggest they add something to say in red letters check the fingerprint AND keyid matches your key. Adam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Border Patrol hails new ID system
http://www.washingtontimes.com/functions/print.php?StoryID=20041220-103705-9177r The Washington Times www.washingtontimes.com Border Patrol hails new ID system By Jerry Seper THE WASHINGTON TIMES Published December 21, 2004 Border Patrol agents assigned to U.S. Customs and Border Protection (CBP) identified and arrested 23,502 persons with criminal records nationwide through a new biometric integrated fingerprint system during a three-month period beginning in September, CBP officials said yesterday. Most of those arrested were foreign nationals. This 21st-century biometric identification technology is a critical law-enforcement tool for our CBP Border Patrol agents, said CBP Commissioner Robert C. Bonner. It allows CBP Border Patrol agents to quickly identify criminals by working faster, smarter and employing technology to better secure the nation. Mr. Bonner has described the new system as absolutely critical to CBP's priority mission of keeping terrorists and terrorist weapons out of the country, adding that it gives the agents the ability to identify those with criminal backgrounds we could never have identified before. The program, known as the Integrated Automated Fingerprint Identification System (IAFIS), is a biometric identification technology enabling Border Patrol agents to search CBP's Automated Biometric Identification System (IDENT) and the FBI's criminal fingerprint database simultaneously, CBP spokesman Mario Villarreal said. It allows Border Patrol agents to rapidly identify people with outstanding warrants and criminal histories by electronically comparing a live-scanned 10-fingerprint entry against a comprehensive national database of previously captured fingerprints, he said. The IAFIS/IDENT system went on line this year at all 148 Border Patrol station throughout the country. It began as a pilot project in San Diego, where it was employed at the Border Patrol's Brown Field, Calif., station, and at the Calexico, Calif., port of entry. During the three-month period this year, the agents identified and detained 84 homicide suspects, 37 kidnapping suspects, 151 sexual assault suspects, 212 robbery suspects, 1,238 suspects for assaults of other types, and 2,630 suspects implicated in dangerous narcotics-related charges. CBP is the unified border agency within the Department of Homeland Security charged with the management, control and protection of the nation's borders at and between the ports of entry. CBP is charged with keeping terrorists and terrorist weapons out of the country while enforcing hundreds of U.S. laws. -- - 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]
