Re: [Cryptography] Crypto being blamed in the London riots.
On Aug 10, 2011, at 12:19 53PM, Perry E. Metzger wrote: On Wed, 10 Aug 2011 11:59:53 -0400 John Ioannidis j...@tla.org wrote: On Tue, Aug 9, 2011 at 8:02 PM, Sampo Syreeni de...@iki.fi wrote: Thus, why not turn the Trusted Computing idea on its head? Simply make P2P public key cryptography available to your customers, and then bind your hands behind your back in an Odysseian fasion, using hardware means? Simply make it impossible for even yourself to circumvent the best cryptographic protocol you can invent, which you embed in your device before ever unveiling it, and then just live with it? Customers? There is no profit in any manufacturer or provider to build that kind of functionality. Blackberry already more or less has that functionality, which disproves your hypothesis. More precisely, Blackberry email is encrypted from the recipient's Exchange server to the mobile device. The scenario is corporate email; the business case is that RIM could claim that they *couldn't* read the email; they never had it in the clear. However, that's only true for that service. For personal Blackberries, there is no corporate-owned server doing the encryption. The service in question here, though, is Blackberry Messenger. There seems to be some confusion about whether or not such messages are encrypted, and if so under what circumstances. One link (http://www.berryreview.com/2010/08/06/faq-blackberry-messenger-pin-messages-are-not-encrypted/) says that they're not, in any meaningful form. More authoritatively, http://web.archive.org/web/20101221211610/http://www.cse-cst.gc.ca/its-sti/publications/itsb-bsti/itsb57a-eng.html says that they aren't. The most authoritative source is RIM itself. P 27 of http://docs.blackberry.com/16650/ confirms the CSE document. Looking at things more abstractly, there's a very difficult key management problem for a decentralized, many-to-one encryption service. Here, you're either in CA territory or web of trust territory. In this case, are the alleged perpetrators of the riots careful enough about to which keys they're sending the organizing messages? If the pattern is anything like Facebook friending, I sincerely doubt it. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: Photos of an FBI tracking device found by a suspect
On Oct 8, 2010, at 11:21 16AM, Perry E. Metzger wrote: My question: if someone plants something in your car, isn't it your property afterwards? http://gawker.com/5658671/dont-post-pictures-of-an-fbi-tracking-device-you-find-on-a-car-to-the-internet See http://www.wired.com/threatlevel/2010/10/fbi-tracking-device/ for even more disturbing aspects of the story -- they operated by intimidation (to say nothing of apparent ethnic and religious profiling). --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Anyone know anything about the new ATT encrypted voice service?
On Oct 6, 2010, at 6:19 01PM, Perry E. Metzger wrote: ATT debuts a new encrypted voice service. Anyone know anything about it? http://news.cnet.com/8301-13506_3-20018761-17.html (Hat tip to Jacob Applebaum's twitter feed.) http://www.att.com/gen/press-room?pid=18624cdvn=newsnewsarticleid=31260mapcode=enterprise says a bit more. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
ciphers with keys modifying control flow?
Does anyone know of any ciphers where bits of keys modify the control path, rather than just data operations? Yes, I know that that's a slippery concept, since ultimately things like addition and multiplication can be implemented with loops in the hardware or firmware. I also suspect that it's potentially dangerous, since it might create very hard-to-spot classes of weak keys. The closest I can think of is SIGABA, where some of the keying controlled the stepping of the other rotors. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Certificate-stealing Trojan
Per http://news.softpedia.com/news/New-Trojan-Steals-Digital-Certificates-157442.shtml there's a new Trojan out there that looks for a steals Cert_*.p12 files -- certificates with private keys. Since the private keys are password-protected, it thoughtfully installs a keystroke logger as well --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Something you have, something else you have, and, uh, something else you have
On Sep 17, 2010, at 4:53 51AM, Peter Gutmann wrote: From the ukcrypto mailing list: Just had a new Lloyds credit card delivered, it had a sticker saying I have to call a number to activate it. I call, it's an automated system. It asks for the card number, fair enough. It asks for the expiry date, well maybe, It asks for my DOB, the only information that isn't actually on the card, but no big secret. And then it asks for the three-digit-security-code- on-the-back, well wtf? AIUI, and I may be wrong, the purpose of activation is to prevent lost-in- the-post theft/fraud - so what do they need details which a thief who has the card in his hot sweaty hand already knows for? Looks like it's not just US banks whose interpretation of n-factor auth is n times as much 1-factor auth. I don't know how NZ banks do it; in the US, they use the phone number you're calling from. Yes, it's spoofable, but most folks (a) don't know it, and (b) don't know how. Of course, in many newer houses here there's a phone junction box *outside* the house. So -- steal the envelope, and plug your own phone into the junction box, and away you go... --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
HDCP master key supposedly leaked
http://arstechnica.com/tech-policy/news/2010/09/claimed-hdcp-master-key-leak-could-be-fatal-to-drm-scheme.ars --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Intel plans crypto-walled-garden for x86
On Sep 13, 2010, at 11:58 57PM, John Gilmore wrote: http://arstechnica.com/business/news/2010/09/intels-walled-garden-plan-to-put-av-vendors-out-of-business.ars In describing the motivation behind Intel's recent purchase of McAfee for a packed-out audience at the Intel Developer Forum, Intel's Paul Otellini framed it as an effort to move the way the company approaches security from a known-bad model to a known-good model. Otellini went on to briefly describe the shift in a way that sounded innocuous enough--current A/V efforts focus on building up a library of known threats against which they protect a user, but Intel would live to move to a world where only code from known and trusted parties runs on x86 systems. Let me guess -- to run anything but Windows, you'll soon have to jailbreak even laptops and desktop PC's? I've written a long blog post on this issue for the Concurring Opinions legal blog; see http://www.concurringopinions.com/archives/2010/09/a-new-threat-to-generativity.html --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: questions about RNGs and FIPS 140
On Aug 25, 2010, at 4:37 16PM, travis+ml-cryptogra...@subspacefield.org wrote: 3) Is determinism a good idea? See Debian OpenSSL fiasco. I have heard Nevada gaming commission regulations require non-determinism for obvious reasons. It's worth noting that the issue of determinism vs. non-determinism is by no means clearcut. You yourself state that FIPS 140-2 requires deterministic PRNGs; I think one can rest assured that the NSA had a lot of input into that spec. The Clipper chip programming facility used a PRNG to set the unit key -- and for good reasons, not bad ones. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
On Aug 25, 2010, at 9:04 20AM, Richard Salz wrote: Also, note that HSTS is presently specific to HTTP. One could imagine expressing a more generic STS policy for an entire site A really knowledgeable net-head told me the other day that the problem with SSL/TLS is that it has too many round-trips. In fact, the RTT costs are now more prohibitive than the crypto costs. I was quite surprised to hear this; he was stunned to find it out. This statement is quite correct. I know of at least one major player that was very reluctant to use SSL because of this issue; the round trips, especially on intercontinental connections, led to considerable latency, which in turn hurt the perceived responsiveness of their service. We need to do something about the speed of light. Is anyone working on hyperwave or subether technologies? --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: [IP] Malware kills 154
On Aug 24, 2010, at 12:32 19PM, Chad Perrin wrote: On Mon, Aug 23, 2010 at 03:35:45PM -0400, Steven Bellovin wrote: And the articles I've seen do not say that the problem caused the crash. Rather, they say that a particular, important computer was infected with malware; I saw no language (including in the Google translation of the original article at http://www.elpais.com/articulo/espana/ordenador/Spanair/anotaba/fallos/aviones/tenia/virus/elpepiesp/20100820elpepinac_11/Tes, though the translation has some crucial infelicities) that said because of the malware, bad things happened. It may be like the reactor computer with a virus during a large blackout -- yes, the computer was infected, but that wasn't what caused the problem. The problem was evidently a couple of maintenance technicians who didn't do their jobs correctly. The computer comes into the matter because one of its jobs was to activate an alarm if a critical system whose failure *was* the proximate cause of the crash was not working properly. It didn't activate the alarm, which would have led to the aircraft being prohibited from taking off, because of the malware. What I have not seen are any statements attributed to the investigating agency that support your last conclusion: that the malware is what caused the alarm failure. I saw a very good summary of the official findings; I'll ask permission to repost them. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: [IP] Malware kills 154
On Aug 23, 2010, at 11:50 30AM, John Levine wrote: Authorities investigating the 2008 crash of Spanair flight 5022 have discovered a central computer system used to monitor technical problems in the aircraft was infected with malware http://www.msnbc.msn.com/id/38790670/ns/technology_and_science-security/?gt1=43001 This was very poorly reported. The malware was on a ground system that wouldn't have provided realtime warnings of the configuration problem that caused the plane to crash anyway. And the articles I've seen do not say that the problem caused the crash. Rather, they say that a particular, important computer was infected with malware; I saw no language (including in the Google translation of the original article at http://www.elpais.com/articulo/espana/ordenador/Spanair/anotaba/fallos/aviones/tenia/virus/elpepiesp/20100820elpepinac_11/Tes, though the translation has some crucial infelicities) that said because of the malware, bad things happened. It may be like the reactor computer with a virus during a large blackout -- yes, the computer was infected, but that wasn't what caused the problem. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: [IP] Malware kills 154
On Aug 23, 2010, at 11:11 13AM, Peter Gutmann wrote: Perry E. Metzger pe...@piermont.com forwards: Authorities investigating the 2008 crash of Spanair flight 5022 have discovered a central computer system used to monitor technical problems in the aircraft was infected with malware http://www.msnbc.msn.com/id/38790670/ns/technology_and_science-security/?gt1=43001 Sigh, yet another attempt to use the dog ate my homework of computer problems, if their fly-by-wire was Windows XP then they had bigger things to worry about than malware. To say nothing of what happens when you run a nuclear power plant on Windows: http://www.upi.com/News_Photos/Features/Irans-Bushehr-nuclear-power-plant/3693/2/ (slightly OT, I realize, but too good to pass up). --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Has there been a change in US banking regulations recently?
On Aug 16, 2010, at 9:19 49PM, John Gilmore wrote: who's your enemy? The NSA? The SVR? Or garden-variety cybercrooks? Enemy? We don't have to be the enemy for someone to crack our security. We merely have to be in the way of something they want; or to be a convenient tool or foil in executing a strategy. John, as you yourself have said, cryptography is a matter of economics. Other than a few academics, people don't factor large numbers for fun; rather, they want the plaintext or the ability to forge signatures. Is factoring the best way to do that? Your own numbers suggest that it is not. You wrote After they've built 50, which perhaps only take six months to crack a key, will YOUR key be one of the 100 keys that they crack this year? 100 keys, perhaps multiplied by 10 for the number of countries that will share the effort, means 1000 keys/year. How many *banks* have SSL keys? If you want to attack one of those banks, which is *cheaper*, getting time on a rare factoring machine, or finding some other way in, such as hacking an endpoint? For that matter, don't forget Morris' three Bs: burglary, bribery, and blackmail. (Aside: I was once discussing TWIRL with someone who has ties to the classified community. When I quoted solution speeds of the we're discussing, he chortled, saying that the political fight over whose solutions were more valuable would paralyze things.) If the threat is factoring, there are cheaper defenses than going to 1024-bit keys. For example, every one under a given CA can issue themselves subcertificates. For communication keys, use D-H; it's a separate solution effort for each session. (Yes, it's cheaper if the modulus is held constant.) Cracking the signing key won't do any good, because of perfect forward secrecy. You don't need long keys when they're used solely for short-lived authentication -- DNSSEC comes to mind. Now -- all that said, I agree that 2048-bit keys are a safer choice. However, defenders have to consider economics, too, and depending on what they're protecting it may not be a smart choice. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: 2048-bit RSA keys
On Aug 17, 2010, at 5:19 10PM, Samuel Neves wrote: On 17-08-2010 21:42, Perry E. Metzger wrote: On Tue, 17 Aug 2010 22:32:52 +0200 Simon Josefsson si...@josefsson.org wrote: Bill Stewart bill.stew...@pobox.com writes: Basically, 2048's safe with current hardware until we get some radical breakthrough like P==NP or useful quantum computers, and if we develop hardware radical enough to use a significant fraction of the solar output, we'll probably find it much easier to eavesdrop on the computers we're trying to attack than to crack the crypto. Another breakthrough in integer factoring could be sufficient for an attack on RSA-2048. Given the number of increasingly efficient integer factorization algorithms that have been discovered throughout history, another breakthrough here seems more natural than unlikely to me. A breakthrough could also render 10kbit keys broken, or might never happen at all. A breakthrough could make short ECC keys vulnerable. A breakthrough could make AES vulnerable. One can't operate on this basis -- it makes it impossible to use anything other than one-time pads. A breakthrough is a rather strong term. But it's not unreasonable to believe that the number field sieve's complexity could be lowered on the near future by an *incremental* improvement --- it would only require lowering the complexity from L[1/3, ~1.92] to L[1/3, ~1.2] to make 2048 bit factorization roughly as easy as 768 bits today. It's worth quote from the paper at CRYPTO '10 on factorization of a 768-bit number: The new NFS record required the following effort. We spent half a year on 80 processors on polynomial selection. This was about 3% of the main task, the sieving, which took almost two years on many hundreds of machines. On a single core 2.2 GHz AMD Opteron processor with 2 GB RAM, sieving would have taken about fifteen hundred years. We did about twice the sieving strictly necessary, to make the most cumbersome step, the matrix step, more manageable. Preparing the sieving data for the matrix step took a couple of weeks on a few processors. The final step after the matrix step took less than half a day of computing. They conclude with at this point factoring a 1024-bit RSA modulus looks more than five times easier than a 768-bit RSA modulus looked back in 1999, when we achieved the first public factorization of a 512-bit RSA modulus. Nevertheless, a 1024-bit RSA modulus is still about a thousand times harder to factor than a 768-bit one. It may be possible to factor a 1024-bit RSA modulus within the next decade by means of an academic effort on the same scale as the effort presented here. Recent standards recommend phasing out such moduli by the end of the year 2010 [28]. See also [21]. Another conclusion from our work is that we can confidently say that if we restrict ourselves to an open community, academic effort such as ours and unless something dramatic happens in factoring, we will not be able to factor a 1024-bit RSA modulus within the next five years [27]. After that, all bets are off. They also suggest that a 3-4 year phase-out of 1024-bit moduli is the proper course. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Has there been a change in US banking regulations recently?
On Aug 15, 2010, at 1:17 30PM, Peter Gutmann wrote: Ray Dillinger b...@sonic.net writes: On Fri, 2010-08-13 at 14:55 -0500, eric.lengve...@wellsfargo.com wrote: The big drawback is that those who want to follow NIST's recommendations to migrate to 2048-bit keys will be returning to the 2005-era overhead. Either way, that's back in line with the above stated 90-95% overhead. Meaning, in Dan's words 2048 ain't happening. I'm under the impression that 2048 keys are now insecure mostly due to advances in factoring algorithms Insecure against what? Right -- who's your enemy? The NSA? The SVR? Or garden-variety cybercrooks? Given the million [0] easier attack vectors against web sites, which typically range from trivial all the way up to relatively easy, why would any rational attacker bother with factoring even a 1024-bit key, with a difficulty level of quite hard? It's not as if these keys have to remain secure for decades, since the 12-month CA billing cycle means that you have to refresh them every year anyway. That depends on what you're protecting. If it's the 4-digit PIN to billion-zorkmid bank accounts, they key needs to remain secure for many years, given how seldom PINs are changed. Given both the state of PKI and the practical nonexistence of attacks on crypto of any strength because it's not worth the bother, would the attackers even notice if you used a 32-bit RSA key? How would an adversary effectively scale and monetise an attack based on being able to break an RSA key, even if it was at close to zero cost? The unfortunate effect of such fashion-statement crypto recommendations as you must use 2K bit keys, regardless of the threat environment is that what it actually says is you must not use SSL on your web site. Le mieux est l'ennemi du bien strikes again. Yup. [0] Figure exaggerated slightly for effect. But only slightly exaggerated... --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: new tech report on easy-to-use IPsec
On Aug 11, 2010, at 12:21 47PM, Adam Aviv wrote: I think the list may get a kick out of this. The tech-report was actually posted on the list previously, which is where I found it. Link included for completeness. http://mice.cs.columbia.edu/getTechreport.php?techreportID=1433 Thanks. I'll add that the code is now up on SourceForge under a BSD license: http://sourceforge.net/projects/simple-vpn/ Original Message Subject: Re: new tech report on easy-to-use IPsec Date: Wed, 28 Jul 2010 21:36:47 -0400 From: Steven Bellovin s...@cs.columbia.edu To: Adam Aviv a...@cis.upenn.edu On Jul 28, 2010, at 9:29 51PM, Adam Aviv wrote: I couldn't help but notice this nugget of wisdom in your report: [quote] Public key infrastructures (PKIs) are surrounded by a great mystique. Organizations are regularly told that they are complex, require ultra-high security, and perhaps are best outsourced to competent parties. Setting up a certifcate authority (CA) requires a ceremony, a term with a technical meaning [13] but nevertheless redolent of high priests in robes, acolytes with censers, and more. This may or may not be true in general; for most IPsec uses, however, little of this is accurate. (High priests and censers are defnitely not needed; we are uncertain about the need for acolytes ...) Peter Gutmann told me privately that he thinks the alternate model involves human sacrifices and perhaps a goat... --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Obama administration seeks warrantless access to email headers.
On Jul 30, 2010, at 3:58 08PM, Perry E. Metzger wrote: On Fri, 30 Jul 2010 09:38:44 +0200 Stefan Kelm sk...@bfk.de wrote: Perry, The administration wants to add just four words -- electronic communication transactional records -- to a list of items that the law says the FBI may demand without a judge's approval. Government Would that really make that much of a difference? In Germany, at least, the so-called judge's approval often isn't worth a penny, esp. wrt. phone surveillance. It simply is way too easy to get such an approval, even afterwards. It is significantly harder here in the US. Actually, no, it isn't. Transaction record access is not afforded the same protection as content. I'll skip the detailed legal citations; the standard now for transactional records is 'if the governmental entity offers specific and articulable facts showing that there are reasonable grounds to believe that the contents of a wire or electronic communication, or the records or other information sought, are relevant and material to an ongoing criminal investigation. This is much less than the probably cause and specificity standards for full-content wiretaps, which do enjoy very strong protection. Equally importantly, it is much simpler to determine what warrants were issued after the fact. Not in this case. Since the target of such an order is not necessarily the suspect, the fact of the information transfer may never be introduced in open court. Nor is there a disclosure requirement here, the way there is for full-content wiretaps. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Jul 28, 2010, at 8:21 33AM, Ben Laurie wrote:
On 28/07/2010 13:18, Peter Gutmann wrote:
Ben Laurie b...@links.org writes:
I find your response strange. You ask how we might fix the problems, then
you
respond that since the world doesn't work that way right now, the fixes
won't
work. Is this just an exercise in one-upmanship? You know more ways the
world
is broken than I do?
It's not just that the world doesn't work that way now, it's quite likely
that
it'll never work that way (for the case of PKI/revocations mentioned in the
message, not the original SNI). We've been waiting for between 20 and 30
years (depending on what you define as the start date) for PKI to start
working, and your reponse seems to indicate that we should wait even harder.
If I look at the mechanisms we've got now, I can identify that commercial
PKI
isn't helping, and revocations aren't helping, and work around that. I'm
after effective practical solutions, not just a solution exists, QED
solutions.
The core problem appears to be a lack of will to fix the problems, not a
lack of feasible technical solutions.
I don't know why it should help that we find different solutions for the
world to ignore?
There seem to be at least three different questions here: bad code (i.e., that
Windows doesn't check the revocation status properly), the UI issue, and the
conceptual question of what should replace the current PKI+{CRL,OCSP} model.
For the last issue, I'd note that using pki instead of PKI (i.e., many
different per-realm roots, authorization certificates rather than identity
certificates, etc.) doesn't help: Realtek et al. still have no better way or
better incentive to revoke their own widely-used keys.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: MITM attack against WPA2-Enterprise?
I don't know, if it is truly only a ten line change to a common WPA2 driver to read, intercept and alter practically any traffic on the network even in enterprise mode, that would seem like a serious issue to me. Setting up the enterprise mode stuff to work is a lot of time and effort. If it provides essentially no security over WPA2 in shared key mode, one wonders what the point of doing that work is. This doesn't seem like a mere engineering compromise. If I understand the problem correctly, it doesn't strike me as particularly serious. Fundamentally, it's a way for people in the same enterprise and on the same LAN to see each other's traffic. A simple ARP-spoofing attack will do the same thing; no crypto needed. Yes, that's a more active attack, and in theory is somewhat more noticeable. In practice, I suspect the actual risk is about the same. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: MITM attack against WPA2-Enterprise?
On Jul 26, 2010, at 10:30 19PM, Perry E. Metzger wrote: On Mon, 26 Jul 2010 21:42:53 -0400 Steven Bellovin s...@cs.columbia.edu wrote: I don't know, if it is truly only a ten line change to a common WPA2 driver to read, intercept and alter practically any traffic on the network even in enterprise mode, that would seem like a serious issue to me. Setting up the enterprise mode stuff to work is a lot of time and effort. If it provides essentially no security over WPA2 in shared key mode, one wonders what the point of doing that work is. This doesn't seem like a mere engineering compromise. If I understand the problem correctly, it doesn't strike me as particularly serious. Fundamentally, it's a way for people in the same enterprise and on the same LAN to see each other's traffic. A simple ARP-spoofing attack will do the same thing; no crypto needed. Yes, that's a more active attack, and in theory is somewhat more noticeable. In practice, I suspect the actual risk is about the same. I think the issue is that people have been given the impression that WPA2 provides enough security that people can feel reasonably secure that others will not be reading their traffic over the air the way that they might in a pure shared key scenario, and that this justified the extra complexity of deployment. While what you say is perfectly true, it does lead one to ask if WPA2 enterprise has not been significantly oversold. Probably... To me, access link crypto is about access control. WEP -- apart from the failings in RC4 and how it was used -- got that badly wrong, because it was impossible to change keys in any rational way. WPA2 was supposed to fix that; I'd have been happy if that were all it did. As others have noted, end-to-end crypto is the proper approach. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
MITM attack against WPA2-Enterprise?
There is a claim of a flaw in WPA2-Enterprise -- see http://wifinetnews.com/archives/2010/07/researchers_hints_8021x_wpa2_flaw.html --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Root Zone DNSSEC Deployment Technical Status Update
On Jul 17, 2010, at 3:30 05PM, Taral wrote: On Sat, Jul 17, 2010 at 7:41 AM, Paul Wouters p...@xelerance.com wrote: Several are using old SHA-1 hashes... old ? old in that they are explicitly not recommended by the latest specs I was looking at. DNSSEC signatures do not need to have a long lifetime; no one cares if, in 10 years, someone can find a preimage attack against today's signed zones. This is unlike many other uses of digital signatures, where you may have to present evidence in court about what some did or did not sign. It's also unclear to me what the actual deployment is of stronger algorithms, or of code that will do the right thing if multiple signatures are present. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
new tech report on easy-to-use IPsec
Folks on this list may be interested in a new tech report: Shreyas Srivatsan, Maritza Johnson, and Steven M. Bellovin. Simple-VPN: Simple IPsec configuration. Technical Report CUCS-020-10, Department of Computer Science, Columbia University, July 2010. http://mice.cs.columbia.edu/getTechreport.php?techreportID=1433 The IPsec protocol promised easy, ubiquitous encryption. That has never happened. For the most part, IPsec usage is confined to VPNs for road warriors, largely due to needless configuration complexity and incompatible implementations. We have designed a simple VPN configuration language that hides the unwanted complexities. Virtually no options are necessary or possible. The administrator specifies the absolute minimum of information: the authorized hosts, their operating systems, and a little about the network topology; everything else, including certificate generation, is automatic. Our implementation includes a multitarget compiler, which generates implementation-specific configuration files for three different platforms; others are easy to add. We hope to have the code up on Sourceforge soon. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Commercial quantum cryptography system broken
http://www.technologyreview.com/blog/arxiv/25189/ Not at all to my surprise, they broke it by exploiting a difference between a theoretical system and a real-world implementation. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
A real case of malicious steganography in the wild?
For years, there have been unverifiable statements in the press about assorted hostile parties using steganography. There may now be a real incident -- or at least, the FBI has stated in court documents that it happened. According to the Justice Department (http://www.justice.gov/opa/pr/2010/June/10-nsd-753.html), 11 Russian nationals have been operating as deep cover agents in the US for many years. According to Complaint #2 (link at the bottom of the page), a steganographic program was used. Other Internet-era techniques allegedly employed include ad hoc WiFi networks. (To be sure, the FBI could be wrong. In the past, I've seen them make mistakes about that, but they're *much* more experienced now.) It will be interesting to see how this develops in court. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Question w.r.t. AES-CBC IV
On Jul 9, 2010, at 1:55 12PM, Jonathan Katz wrote: CTR mode seems a better choice here. Without getting too technical, security of CTR mode holds as long as the IVs used are fresh whereas security of CBC mode requires IVs to be random. In either case, a problem with a short IV (no matter what you do) is the possibility of IVs repeating. If you are picking 32-bit IVs at random, you expect a repeat after only (roughly) 2^16 encryptions (which is not very many). Unless I misunderstand your point, I think that in the real world there's a very real difference in the insecurity of CBC vs CTR if the IV selection is faulty. With CBC, there is semantic insecurity, in that one can tell if two messages have a common prefix if the IV is the same. Furthermore, if the IV is predictable to the adversary under certain circumstances some plaintext can be recovered. With CTR, however, there are very devastating two-message attacks if the IVs are the same; all that's necessary is some decent knowledge of some probable plaintext. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Quantum Key Distribution: the bad idea that won't die...
While I'm quite skeptical that QKD will prove of practical use, I do think it's worth investigating. The physics are nice, and it provides an interesting and different way of thinking about cryptography. I think that there's a non-trivial chance that it will some day give us some very different abilities, ones we haven't even thought of. My analog is all of the strange and wondrous things our cryptographic protocols can do -- blind signatures, zero knowledge proofs, secure multiparty computation, and more -- things that weren't on the horizon just 35 years ago. I'm reminded of a story about a comment Whit Diffie once heard from someone in the spook community about public key crypto. We had it first -- but we never knew what we had. You guys have done much more with it than we ever did. All they knew to do with public key was key distribution or key exchange; they didn't even invent digital signatures. They had non-secret encryption; we had public key cryptography. Might the same be true for QKD? I have no idea. I do suggest that it's worth thinking in those terms, rather than how to use it to replace conventional key distribution. Remember that RSA's essential property is not that you can use it to set up a session key; rather, it's that you can use it to send a session key to someone with whom you don't share a secret. Beyond Perry's other points -- and QKD is inherently point-to-point; you need n^2 connections, since you can't terminate the link-layer crypto at a router without losing your security guarantees -- it's worth reminding people that the security guarantees apply to ideal quantum systems. If your emitter isn't ideal -- and of course it isn't -- it can (will?) emit more photons; I can play my interception games with the ones your detector doesn't need. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Against Rekeying
On Mar 23, 2010, at 11:21 AM, Perry E. Metzger wrote:
Ekr has an interesting blog post up on the question of whether protocol
support for periodic rekeying is a good or a bad thing:
http://www.educatedguesswork.org/2010/03/against_rekeying.html
I'd be interested in hearing what people think on the topic. I'm a bit
skeptical of his position, partially because I think we have too little
experience with real world attacks on cryptographic protocols, but I'm
fairly open-minded at this point.
I'm a bit skeptical -- I think that ekr is throwing the baby out with the bath
water. Nobody expects the Spanish Inquisition, and nobody expects linear
cryptanalysis, differential cryptanalysis, hypertesseract cryptanalysis, etc.
A certain degree of skepticism about the strength of our ciphers is always a
good thing -- no one has ever deployed a cipher they think their adversaries
can read, but we know that lots of adversaries have read lots of unbreakable
ciphers.
Now -- it is certainly possible to go overboard on this, and I think the IETF
often has. (Some of the advice given during the design of IPsec was quite
preposterous; I even thought so then...) But one can calculate rekeying
intervals based on some fairly simple assumptions about the amount of
{chosen,known,unknown} plaintex/ciphertext pairs needed and the work factor for
the attack, multiplied by the probability of someone developing an attack of
that complexity, and everything multiplied by Finagle's Constant. The trick,
of course, is to make the right assumptions. But as Bruce Schneier is fond of
quoting, attacks never get worse; they only get better. Given recent research
results, does anyone want to bet on the lifetime of AES? Sure, the NSA has
rated it for Top Secret traffic, but I know a fair number of people who no
longer agree with that judgment. It's safe today -- but will it be safe in 20
years? Will my plaintext still be sensitive then?
All of that is beside the point. The real challenge is often to design a
system -- note, a *system*, not just a protocol -- that can be rekeyed *if* the
long-term keys are compromised. Once you have that, setting the time interval
is a much simpler question, and a question that can be revisited over time as
attacks improve.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Security of Mac Keychain, File Vault
On Oct 24, 2009, at 5:31 PM, Jerry Leichter wrote: The article at http://www.net-security.org/article.php?id=1322 claims that both are easily broken. I haven't been able to find any public analyses of Keychain, even though the software is open-source so it's relatively easy to check. I ran across an analysis of File Vault not long ago which pointed out some fairly minor nits, but basically claimed it did what it set out to do. The article makes a bunch of other claims which aren't obviously unreasonable. Anyone one know of more recent analysis of Mac encryption stuff? (OS bugs/security holes are a whole other story) The article specifically mentions Mac Marshall for attacking FileVault, but from the descriptions of it I can find it's just doing password guessing. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: [Barker, Elaine B.] NIST Publication Announcements
On Sep 29, 2009, at 10:31 AM, Perry E. Metzger wrote: Stephan Neuhaus neuh...@st.cs.uni-sb.de writes: For business reasons, Alice can't force Bob to use a particular TTA, and it's also impossible to stipulate a particular TTA as part of the job description (the reason is that Alice and the Bobsgreat band name BTW---won't agree to trust any particular TTA and also don't want to operate their own). You don't need such a complicated description -- you're just asking can I do secure timestamping without requiring significant trust in the timestamping authority. The Haber Stornetta scheme provides a timestamping service that doesn't require terribly much trust, since hard to forge widely witnessed events delimit particular sets of timestamps. The only issue is getting sufficient granularity. I don't know if their scheme was patented in Germany. It was in the U.S., though I think that at least some of the patents expire within the year. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
FileVault on other than home directories on MacOS?
Is there any way to use FileVault on MacOS except on home directories? I don't much want to use it on my home directory; it doesn't play well with Time Machine (remember that availability is also a security property); besides, different directories of mine have different sensitivity levels. I suppose I could install TrueCrypt (other suggestions or comments on TrueVault?), but I prefer to minimize the amount of extra software I have to maintain. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
NSA intercepts led to a terrorist conviction
Threat Level Privacy, Crime and Security Online NSA-Intercepted E-Mails Helped Convict Would-Be Bombers The three men convicted in the United Kingdom on Monday of a plot to bomb several transcontinental flights were prosecuted in part using crucial e-mail correspondences intercepted by the U.S. National Security Agency, according to Britain’s Channel 4. The e-mails, several of which have been reprinted by the BBC and other publications, contained coded messages, according to prosecutors. They were intercepted by the NSA in 2006 but were not included in evidence introduced in a first trial against the three last year. http://www.wired.com/threatlevel/2009/09/nsa-email/ has more. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
On Aug 26, 2009, at 6:26 AM, Ben Laurie wrote: On Mon, Aug 10, 2009 at 6:35 PM, Peter Gutmannpgut...@cs.auckland.ac.nz wrote: More generally, I can't see that implementing client-side certs gives you much of anything in return for the massive amount of effort required because the problem is a lack of server auth, not of client auth. If I'm a phisher then I set up my bogus web site, get the user's certificate-based client auth message, throw it away, and report successful auth to the client. The browser then displays some sort of indicator that the high-security certificate auth was successful, and the user can feel more confident than usual in entering their credit card details. All you're doing is building even more substrate for phishing attacks. Without simultaneous mutual auth, which -SRP/-PSK provide but PKI doesn't, you're not getting any improvement, and potentially just making things worse by giving users a false sense of security. I certainly agree that if the problem you are trying to solve is server authentication, then client certs don't get you very far. I find it hard to feel very surprised by this conclusion. If the problem you are trying to solve is client authentication then client certs have some obvious value. That said, I do tend to agree that mutual auth is also a good avenue to pursue, and the UI you describe fits right in with Chrome's UI in other areas. Perhaps I'll give it a try. This returns us to the previously-unsolved UI problem: how -- with today's users, and with something more or less like today's browsers since that's what today's users know -- can a spoof-proof password prompt be presented? --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Kahn's Seizing the Enigma back in print -- with a catch
David Kahn's Seizing the Enigma is back in print. However, it's only available from Barnes and Noble -- their publishing arm is doing the reprint. According to the preface, the new edition corrects minor errors, but didn't give any details. http://search.barnesandnoble.com/Seizing-the-Enigma/David-Kahn/e/9781435107915/?itm=1 --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
