Re: MS responds to Gutmann's Vista paper
=?UTF-8?B?SXZhbiBLcnN0acSH?= [EMAIL PROTECTED] writes: Aside from admitting to increased CPU utilization, which seemed pretty incontestable anyway, they're disputing [0] many of the points made in the original paper [1]. Their response is a mixture of technical content and PR handwaving, I've responded to the latter as part of the Vista writeup at http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.html#response, and will be integrating the technical clarifications into the body of the writeup when I get time Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Free WiFi man-in-the-middle scam seen in the wild.
For years, I've complained about banks, such as Chase, which let people type in the password to their bank account into a page that has been downloaded via http: instead of https:. The banks always say oh, that's no problem, because the password is posted via https:, and I say but that's only if the page comes from *you*, and it might come from a bad guy. How would someone possibly send the user a faked up web page? they then ask. I reply like this the two obvious ways are DNS cache contamination and doing a man-in-the-middle in the network, and the latter is really easy now that people trusting WiFi base stations in strange places that they've never used before. You could just put a tiny box near a cafe or airport lounge and siphon off passwords day and night. The bank people then tell me that I'm crazy. (They're usually more polite than that, but that's the import of what they say.) I have a great letter from a manager at Chase informing me that they've been assured by fabulous security people that their system is safe. Adding insult to injury, the banks put a little padlock GIF on their insecure form, probably to reduce the number of phone calls they get about it. Well, guess what. It turns out that people are now deploying man-in-the-middle WiFi devices in places like airports and siphoning passwords for bank accounts. Who would have thought of such a nefarious thing? Certainly this is a new problem and one no would have thought of it before now...: January 19, 2007 (Computerworld) -- The next time you're at an airport looking for a wireless hot spot, and you see one called Free Wi-Fi or a similar name, beware -- you may end up being victimized by the latest hot-spot scam hitting airports across the country. You could end up being the target of a man in the middle attack, in which a hacker is able to steal the information you send over the Internet, including usernames and passwords. And you could also have your files and identity stolen,[...] http://www.computerworld.com/action/article.do?command=viewArticleBasicarticleId=9008399source=NLT_NETnlid=27 (Incidently, the article gets a few things wrong. It somewhat implies that you are safe if you pick a WiFi network you have a previous relationship with, which isn't true.) Just to pick on my favorite exemplar of how not to do things for a moment, go over to: http://www.chase.com/ and ponder how it could be that a giant multinational financial institution could set its customers up this way. If you go over to, say, www.fidelity.com, you will find that you can't even get to the http: version of the page any more -- you are always redirected to the https: version. For the record, Fidelity has gotten this right for as long as I've been watching them. Now you might wonder, why do I keep picking on Chase? A certain other security person and I had an extended argument with the folks at another company I won't name other than to say that it was American Express. At the time, they more or less said, yah, this is a problem, but fixing it is going to be a pain. However, I'll note that now, as with Fidelity, you pretty much can't go onto their web site without using https: -- kudos to Amex. Indeed, though this was all a major problem a couple of years ago with many banks, many have now fixed it. However, for a select few, like, say, Chase, the message simply isn't getting through even though these organizations have been repeatedly informed that they are leaving their customers vulnerable. One wonders what level of trouble they're going to have to get into before they actually do the right thing. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Free WiFi man-in-the-middle scam seen in the wild.
Quoting Perry E. Metzger [EMAIL PROTECTED]: Now you might wonder, why do I keep picking on Chase? A certain other security person and I had an extended argument with the folks at another company I won't name other than to say that it was American Express. At the time, they more or less said, yah, this is a problem, but fixing it is going to be a pain. However, I'll note that now, as with Fidelity, you pretty much can't go onto their web site without using https: -- kudos to Amex. Indeed, though this was all a major problem a couple of years ago with many banks, many have now fixed it. However, for a select few, like, say, Chase, the message simply isn't getting through even though these organizations have been repeatedly informed that they are leaving their customers vulnerable. One wonders what level of trouble they're going to have to get into before they actually do the right thing. I'll just point out that you CAN go to: https://chaseonline.chase.com/ And that works, and should be secure. No, it's not the same as typing chase into your browser and having the right thing happen, but honestly this is what browser caches are for. (When I type chase into my browser bar it autocompletes to the above URL). -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Free WiFi man-in-the-middle scam seen in the wild.
On Tue, January 23, 2007 09:24, Perry E. Metzger wrote: (Incidently, the article gets a few things wrong. It somewhat implies that you are safe if you pick a WiFi network you have a previous relationship with, which isn't true.) It also is only warning against ad-hoc connections with misleading names. While I see a bunch of these around (not necessarily in airports, either... several show up from my cube at work), it doesn't take much to put up a perfectly normal-looking access point. See http://www.ethicalhacker.net/content/view/66/24/ for examples. -- Roy M. Silvernail is [EMAIL PROTECTED], and you're not Antelope Freeway, one sixty-fourth of a mile. - TFT http://www.rant-central.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Free WiFi man-in-the-middle scam seen in the wild.
Derek Atkins [EMAIL PROTECTED] writes: I'll just point out that you CAN go to: https://chaseonline.chase.com/ And that works, and should be secure. And for the six people that know to do that, it works great. :) It used to be that Verizon (my local phone company, sadly) had this general problem but you could click on log in and it would direct you to a secure page with a little error message and you could then enter your username and password. They've since fixed that so it is no longer possible to log in safely to their web site at all. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Private Key Generation from Passwords/phrases
Joseph Ashwood wrote: I'm going to try to make this one a bit less aggregious in tone. I'm also Thank you. - Original Message - From: Matthias Bruestle Joseph Ashwood wrote: - Original Message - From: Matthias Bruestle You also ended up removing a large portion of my point. My primary point was that 2^76 2^112. You made several assumptions in coming to your conclusion that are at least suspect. You observe that currently 3DES:ECC-224 speed is about 4000:1, and assume that it will stay this way. However, if you look at the history of ECC, the speed of ECC doesn't scale linearly against 3DES, in fact a single thread of 3DES might've actually been faster 1 year ago (during the GHz war, before multi-core), whereas ECC is still improving as the ability of the CPU to perform complex routing and branch prediction improves. So next year the ratio could be 100:1, I doubt it will be that dramatic but it is possible. As a result this assumption will have to be reexamined every time a CPU revision is released, a slight timing change can actually make a big difference to the 3DES:ECC speed ratio. Also you need to consider the attack speed of the attacker, versus the production speed of the user. I know there are likely some shifts. Hence I wrote The relation stays (mostly) the same. But in my opinion these shifts are minimal compared to all the other uncertainties, e.g.: - How long does the protected secret/signature be ok? - How well is your adversary funded? - How much entropy has the passphrase really? - How much is the general speed increase in the next 20 years? - ... If you calculate your bits without safety margin, then next year AMD could add a 3DES unit to an CPU, the speed ratio is 4:1 and you're busted. (Because of the hardware friendly design of DES I would say a faster 3DES is easier to get than a faster ECC.) You assume that the fastest way to computer point exponents is through counting up to the exponent. While I admit I'm not familiar with point exponentiation algorithms, I strongly suspect this one to be incorrect, I see no immediate reason that (k*k*k*k) must be decomposed to (((k*k)*k)*k) instead of ((k*k)*(k*k)), at exp=4 there is no difference but at exp=16million there is an enormous difference. You might be able to make this assumption true for your system by somehow proving that the only way to compute k^x requires b^x steps (for some b. My assumption is that the passphrase is properly processed, i.e. nicely hashed. So an attacker has to go through this process if he wants to exploit the reduced entropy of the passphrase and (at least) I see no way how to exploit this reduced entropy then to help algorithms like Pollard's rho/lambda to speed up the computation. The attacker may use any point multiplication method he wants to use. (Jacobian, modified Jacobian, NAF, windowing, ...) I see no reason it the arguments presented that the attacker would still have to perform 2^76 (ECC)work in 2^112 (3DES)time, instead of 2^76 (ECC)work in substantially less than 2^112 (3DES)time. An attacker would have to perform 2^100 (ECC)work, because the ratio accounts in my calculation only for 2^12 steps. The other 2^24 is a thrown away 24bit random. That is not to say that I don't think you will have 2^76 (ECC)work required to break it, taking longer than 2^76 (ECC)work, but that I disagree with your result. If you set your target at 2^80 (ECC)work, then I believe you can achieve it this way. I also think that if you were to perform result[i] = hash(result[i-1], passphrase) (result[0] = 0x000...000) it is a safe assumption that there is no faster way than counting to i, which would vastly improve your chances of security (see Secure Applications of Low-Entropy Keys by Hall, Kelsey, Schneier and Wagner for reference). I also think that most users would be unwilling to wait the full day you spec'd, it is hard enough to get users to wait 5 seconds. The parameters can be changed as needed. A day can be ok for one purpose, e.g. for key recovery, while it is not ok for a different purpose, e.g. recreation of the private key for each decryption. In the later case the passphrase has to contain more entropy. Regarding passphrase entropy: Getting entropy into a rememberable passphrase is a related, but completely different problem. Matthias -- Matthias Bruestle, Managing Director Phone +49 (0) 91 19 55 14 91, Fax +49 (0) 91 19 55 14 97 MaskTech GmbH, Nordostpark 16, 90411 Nuernberg, Germany - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: analysis and implementation of LRW
On Tue, 23 Jan 2007, Peter Gutmann wrote: The IEEE P1619 standard group has dropped LRW mode. It has a vulnerability that that are collisions that will divulge the mixing key which will reduce the mode to ECB. Is there any more information on this anywhere? I haven't been able to find anything in the P1619 archives (or at least not under an obvious heading). Probably http://grouper.ieee.org/groups/1619/email/msg00962.html -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: analysis and implementation of LRW
On Tue, Jan 23, 2007 at 05:56:29PM +0200, Alexander Klimov wrote: * On Tue, 23 Jan 2007, Peter Gutmann wrote: * The IEEE P1619 standard group has dropped LRW mode. It has a vulnerability * that that are collisions that will divulge the mixing key which will reduce * the mode to ECB. * * Is there any more information on this anywhere? I haven't been able to find * anything in the P1619 archives (or at least not under an obvious heading). wikipedia has some infos and links: http://en.wikipedia.org/wiki/IEEE_P1619#LRW_issue Andrea -- Andrea Pasquinucci [EMAIL PROTECTED] PGP key: http://www.ucci.it/ucci_pub_key.asc fingerprint = 569B 37F6 45A4 1A17 E06F CCBB CB51 2983 6494 0DA2 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Fw: NIST announces Draft Requirements and Evaluation Criteria for New Hash Algorithms
Begin forwarded message: Date: Tue, 23 Jan 2007 12:03:45 -0500 From: Shu-jen Chang [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: NIST announces Draft Requirements and Evaluation Criteria for New Hash Algorithms NIST Wants Comments on Proposed Hash Algorithm Requirements and Evaluation Criteria The National Institute of Standards and Technology is planning a competition to develop one or more cryptographic hash algorithms to augment and revise the current Secure Hash Standard (Federal Information Processing Standard 180-2). As a first step in this process, NIST is publishing draft minimum acceptability requirements, submission requirements, and evaluation criteria for candidate algorithms ( See the Federal Register Announcement on http://www.nist.gov/hash-function ), and requests public comment by April 27, 2007. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: analysis and implementation of LRW
David Wagner wrote: Jim Hughes writes: The IEEE P1619 standard group has dropped LRW mode. It has a vulnerability that that are collisions that will divulge the mixing key which will reduce the mode to ECB. This is interesting. Could you elaborate on this? I suspect we could all learn from the work the IEEE P1619 working group is doing. I tried to trawl the P1619 mailing list archives to find some detailed analysis on the topic of collisions, as you suggested, but I probably wasn't looking in the right places. The closest I found was this message: http://grouper.ieee.org/groups/1619/email/msg01322.html which estimates that if one continuously accesses the disk for 4.6 years (roughly the average life time of a disk), the chances of seeing a collision are about 1/2^29. Is that the analysis that triggered the concern over collisions? Google is your friend: http://grouper.ieee.org/groups/1619/email/msg00558.html Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ 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: analysis and implementation of LRW
Jim Hughes writes: The IEEE P1619 standard group has dropped LRW mode. It has a vulnerability that that are collisions that will divulge the mixing key which will reduce the mode to ECB. Peter Gutmann asks: Is there any more information on this anywhere? I haven't been able to find anything in the P1619 archives (or at least not under an obvious heading). Alexander Klimov replies: Probably http://grouper.ieee.org/groups/1619/email/msg00962.html Huh. Was that the reason? I suspect there may have been more to it than that. The message at the cited URL basically says that if the attacker somehow manages to learn half of the key material, then bad things happen. That alone isn't likely to lead to rejecting or accepting a mode of operation, I would think. You know the old joke. Patient: Doctor, doctor, it hurts if I let the attacker learn part of my key. Doctor: Well, don't do that, then. I should perhaps mention that there is some further background which no one has brought up yet, and which may help to understand the IEEE P1619 work. I know there was a concern on the IEEE P1619 mailing list that, if the encryption key is sitting in memory, when you suspend to disk, if the suspend image is encrypted using that same key, then you are encrypting the key under itself (C = E(K,K)). Encrypting the key under itself is in general a potentially unsafe thing to do. For one thing, it voids the security warranty; every provable security theorem that I know of requires that the plaintext must not depend on the key. For another thing, with some modes, there are known attacks where encrypting the key under itself might reveal partial information about the key. LRW is one of those modes where there is such a known weakness. I understand that the IEEE P1619 group came to the conclusion that it was not reasonable to re-architect existing software to ensure that it would never encrypt the key under itself. This then creates a requirement that the mode of operation must be safe to use even when encrypting a key under itself. That is indeed an interesting requirement, and one that seems to legitimately rule out a number of existing modes of operation for IEEE P1619. With that background, I want to circle back to the message from Jim Hughes. I was aware of this encrypt-a-key-under-itself issue, and it's an interesting one. But Jim Hughes didn't cite that as the reason for rejecting LRW; his mention of collisions made it sound to me like he may have been thinking of something else. Perhaps I misunderstood his intent. It might be helpful to have clarification on this: Jim, were you suggesting that there is a second issue, or have I misunderstood you? If there is an issue with collisions, I'd be interested to understand it better. Does anyone have any more information on this anywhere? Does this refer to the birthday bound issue, that if you use a 128-bit block cipher, then the security warranty is violated once you encrypt close to 2^64 blocks of data? Or is it something other than that? My apologies if I've totally misunderstood the P1619 group's reasoning. I suspect there may be a lot we can learn from IEEE P1619's effort. Thanks to everyone for their comments. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Free WiFi man-in-the-middle scam seen in the wild.
Hi, Perry E. Metzger wrote: For years, I've complained about banks, such as Chase, which let people type in the password to their bank account into a page that has been downloaded via http: instead of https:. The banks always say oh, that's no problem, because the password is posted via https:, and I say but that's only if the page comes from *you*, and it might come from a bad guy. A German bank had the same problem. After some discussions without positive results I wrote an article about SSL problems for a large German IT magazine and described their situation. A short time after they changed the login page to https. Matthias -- Matthias Bruestle, Managing Director Phone +49 (0) 91 19 55 14 91, Fax +49 (0) 91 19 55 14 97 MaskTech GmbH, Nordostpark 16, 90411 Nuernberg, Germany - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
more on NIST hash competition
In addition to the URL Steve sent earlier, there is a web page up for the NIST hash competition: http://www.csrc.nist.gov/pki/HashWorkshop/index.html Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
