Re: Nullsoft's WASTE communication system
The AP wire reports that the founder of Nullsoft, Justin Frankel, plans to resign in the wake of WASTE being pulled. http://www.nytimes.com/aponline/technology/AP-AOL-Nullsoft.html --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of Firewalls book) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Pre-cursor to Non-Secret Encryption
In message [EMAIL PROTECTED], John Young writes: Related: We have a three-year-old FOIA request to NSA for information on: The invention, discovery and development of non-secret encryption (NSE) and public key cryptography (PKC) by United Kingdom, United States, or any other nation's intelligence and cryptology agencies, prior to, parallel with, or subsequent to, the PKC work of Diffie-Hellman-Merkle. NSA has recently said that some responsive information may be released in the near future, although it is not clear if that is weeks or months or years away. Can you amend that to ask for digital signature information, too? From my research on Permissive Action Links, I think there's some chance that digital signatures were invented separately, possibly by NSA before GCHQ's non-secret encryption work. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of Firewalls book) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: authentication and ESP
In message [EMAIL PROTECTED], martin f krafft writes : As far as I can tell, IPsec's ESP has the functionality of authentication and integrity built in: RFC 2406: 2.7 Authentication Data The Authentication Data is a variable-length field containing an Integrity Check Value (ICV) computed over the ESP packet minus the Authentication Data. The length of the field is specified by the authentication function selected. The Authentication Data field is optional, and is included only if the authentication service has been selected for the SA in question. The authentication algorithm specification MUST specify the length of the ICV and the comparison rules and processing steps for validation. To my knowledge, IPsec implementations use AH for signing though. Why do we need AH, or why is it preferred? Thanks for your clarification! The question has been asked quite often. The short answer is that AH protects parts of the preceeding IP header, which ESP doesn't do. I did an analysis many years ago which showed that everything in the AH header was either unprotectable, irrelevant, or protected in some other fashion. But the question has been re-opened, notably with regard to protecting Neighbor Discover in IPv6. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of Firewalls book) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New toy: SSLbar
It's a toolbar for Mozilla (and related web browsers) that automatically displays the SHA1 or MD5 fingerprint of the SSL certificate when you visit an SSL secured web site. You could of course click the little padlock icon and dig through a couple of dialogs to see it, but it's much easier when it's right there in front of you on the toolbar. So, what's the point? If you look at the fingerprint of an SSL certificate, and compare this against a fingerprint that you obtain from the site's owner via another channel (IIP, email, PGP-signed web page, etc.) you can be absolutely certain that the certificate is legitimate, and that you are exchanging encrypted data with the persons(s) you intended to. Please don't take this personally -- I'm speaking in general terms here, rather than casting aspersions on anyone in particular. I've deliberately deleted any personal names from this reply, to underscore that point. From a security point of view, why should anyone download any plug-in from an unknown party? In this very specific case, why should someone download a a plug-in that by its own description is playing around in the crypto arena. How do we know it's not going to steal keys? Is the Mozilla API strong enough that it can't possibly do that? Is it implemented well enough that we trust it? (I see that in this case, the guts of the plug-in are in Javascript. Given how often Javascript has played a starring role in assorted security flaws, that doesn't reassure me. But I do appreciate open source.) --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of Firewalls book) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New toy: SSLbar
In message [EMAIL PROTECTED], Ian Grigg writes: Also, to impune the plug-in arrangement is to impune all plug-ins, and to impune the download from an unknown is to impune all downloads from unknowns. Sounds about right... ... I.e., download this fantastic tool which just so annoyingly includes a trojan from the person who manages the site doesn't seem to occur as a real attack with any frequency. In fact, the come and get it method seems to exceed the scan and 'sploit method of building botnets. That is, Trojans are a very active method of infection. (Partly because it takes a long time to find the right victim, and partly because it leaves the attacker static and vulnerable, I'm guessing. In comparison, it seems that attackers get much better results by using targetted mass mailings tools to deliver their EMD.) Botnets communicate via IRC, among many other ways. Sometimes, they even use encrypted channels --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of Firewalls book) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Attacking networks using DHCP, DNS - probably kills DNSSEC
In message [EMAIL PROTECTED], Bill Stewart writes: Somebody did an interesting attack on a cable network's customers. They cracked the cable company's DHCP server, got it to provide a Connection-specific DNS suffic pointing to a machine they owned, and also told it to use their DNS server. This meant that when your machine wanted to look up yahoo.com, it would look up yahoo.com.attackersdomain.com instead. This looks like it has the ability to work around DNSSEC. Somebody trying to verify that they'd correctly reached yahoo.com would instead verify that they'd correctly reached yahoo.com.attackersdomain.com, which can provide all the signatures it needs to make this convincing. So if you're depending on DNSSEC to secure your IPSEC connection, do make sure your DNS server doesn't have a suffix of echelon.nsa.gov... No, that's just not true of DNSsec. DNSsec doesn't depend on the integrity of the connection to your DNS server; rather, the RRsets are digitally signed. In other words, it works a lot like certificates, with a trust chain going back to a magic root key. I'm not saying that there can't be problems with that model, but compromised DNS servers (and poisoned DNS caches) are among the major threat models it was designed to deal with. If nothing else, the existence of caching DNS servers, which are not authoritative for the information they hand out, makes a transmission-based solution pretty useless. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of Firewalls book) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Attacking networks using DHCP, DNS - probably kills DNSSEC
In message [EMAIL PROTECTED], Simon Josefsson writes: Of course, everything fails if you ALSO get your DNSSEC root key from the DHCP server, but in this case you shouldn't expect to be secure. I wouldn't be surprised if some people suggest pushing the DNSSEC root key via DHCP though, because alas, getting the right key into the laptop in the first place is a difficult problem. I can pretty much guarantee that the IETF will never standardize that, except possibly in conjunction with authenticated dhcp. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of Firewalls book) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Attacking networks using DHCP, DNS - probably kills DNSSEC NOT
In message [EMAIL PROTECTED], Simon Josefsson writes: Bill Stewart [EMAIL PROTECTED] writes: * Your laptop see and uses the name yahoo.com.attackersdomain.com. You may be able to verify this using your DNSSEC root key, if the attackersdomain.com people have set up DNSSEC for their spoofed entries, but unless you are using bad software or judgment, you will not confuse this for the real yahoo.com. The DNS suffix business is designed so that your laptop tries to use yahoo.com.attackersdomain.com, either before yahoo.com or after unsuccessfully trying yahoo.com, depending on implementation. It may be bad judgement, but it's designed to support intranet sites for domains that want their web browsers and email to let you refer to marketing as opposed to marketing.webservers.example.com, and Netscape-derived browsers support it as well as IE. It can be a useful feature, but it does not circumvent DNSSEC in any way, that I can see. DNSSEC see yahoo.com.attackersdomain.com and can verify that the IP addresses for that host are the one that the owner of the y.c.a.c domain publishes, and that is what DNSSEC delivers. The bad judgement I referred to was if your software, after DNSSEC verification, confuses yahoo.com with yahoo.com.attackersdomain.com. It's also not a new problem -- see RFC 1535. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of Firewalls book) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Monoculture
In message [EMAIL PROTECTED], Perry E. Metzger writes: Unfortunately, those parts are rather dangerous to omit. 0) If you omit the message authenticator, you will now be subject to a range of fine and well documented cut and paste attacks. With some ciphers, especially stream ciphers, you'll be subject to far worse attacks still. 1) If you omit the IV, suddenly you're going to be subject to a second new range of attacks based on the fact that fixed blocks will always encrypt the exact same way. We went through all that, by the way, when designing IPSec. At first, we didn't put in mandatory authenticators, because we didn't understand that they were security critical. Then, of course, we discovered that they were damn critical, and that most of the text books on this had been wrong. We didn't understand lots of subtleties about our IVs, either. One big hint: do NOT use IVs on sequential packets with close hamming distance! Better yet, don't use predictable IVs; the threat is much clearer. Perry is right -- a number of us learned the hard way about cryptographic protocol complexity. I led the fight to remove sequence numbers from the early version of ESP, since no one could elucidate a threat model beyond the enemy could duplicate packets. My response was so what -- packet duplication is always possible per the IP datagram model. (A while back, my ISP fulfilled that part of the model; I was seeing up to 90% duplicate packets. But I digress.) But then I wrote a paper where I showed lots of ways to attack IPsec if you didn't have both sequence numbers and integrity protection, so I led the fight to reintroduce sequence numbers, and to make integrity protection part of ESP rather than leaving it to AH. We all learn, even in embarrassing ways. My first published cryptographic protocol, EKE, has had an interesting history. One version of it is still believed secure: encrypt both halves of a DH exchange with a shared secret. (Ironically enough, that was the very first variant we came up with -- I still have the notebook where I recorded it.) We came up with lots of variations and optimizations that all looked just fine. We were wrong... Someone has already alluded to the Needham-Schroeder protocol. It's instructive to review the history of it. The original protocol was published in 1978; it was the first cryptographic protocol in the open literature. Presciently enough, it warned that cryptographic protocol design seemed to be a very suble art. Three years later, Denning and Sacco showed an attack on the protocol under certain assumptions; they suggested changes. In 1994, Abadi and Needham published a paper showing a flaw in the Denning-Sacco variant. In 1996, Lowe published a new attack on the *original* Needham-Schroeder paper. Translated into modern terms -- the first paper was published before certificates were invented -- the faulty protocol was only three lines long! Three lines of protocol, in the oldest paper in the literature, and it took 18 years to find the flaw... No, we're not a guild. To me, guild has connotations of exclusivity and closed membership. Anyone can develop their own protocols, and we're quite happy -- *if* they understand what they're doing. That means reading the literature, understand the threats, and deciding which you need to counter and which you can ignore. In IPsec, Steve Kent -- who has far more experience with cryptographic protocols than most of us, since he has access to, shall we say, more than just the open literature -- was a strong proponent of making integrity checks option in ESP. Why, when I just finished saying that they're important? Integrity checks can be expensive, and in some situations the attacks just don't apply. The trick is to understand the tradeoffs, and *to document them*. Leave out what you want, but tell people what you've left out, why you've left it out, and under what circumstances will that change get them into trouble. --Steve Bellovin, http://www.research.att.com/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
In message [EMAIL PROTECTED], Benja Fallenstein writes: Hi, bear wrote: starting with Rivest Shamir's Interlock Protocol from 1984. Hmmm. I'll go read, and thanks for the pointer. Perhaps I spoke too soon? It's not in Eurocrypt or Crypto 84 or 85, which are on my shelf. Where was it published? Communications of the ACM: Rivest and Shamir, How to expose an eavesdropper, CACM vol 24 issue 4, 1984. If you have an ACM Digital Library account, it's at http://portal.acm.org/ft_gateway.cfm?id=358053type=pdfcoll=ACMdl=ACMCFID=1 2683735CFTOKEN=40809148 I've started writing a short summary earlier today, after reading, but then I got distracted and didn't have time... sorry :) Hope this helps anyway. The basic idea is that Alice sends *half* of her ciphertext, then Bob *half* of his, then Alice sends the other half and Bob sends the other half (each step is started only after the previous one was completed). The point is that having only half of the first ciphertext, Mitch can't decrypt it, and thus not pass on the correct thing to Bob in the first step and to Alice in the second, so both can actually be sure to have the public key of the person that made the other move. You have to be careful how you apply it; sometimes, there are attacks. See Steven M. Bellovin and Michael Merritt, An Attack on the Interlock Protocol When Used for Authentication, in IEEE Transactions on Information Theory 40:1, pp. 273-275, January 1994, http://www.research.att.com/~smb/papers/interlock.ps for an example of how it's a bad protocol to use to send passwords. --Steve Bellovin, http://www.research.att.com/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A-B-a-b encryption
In message [EMAIL PROTECTED], Perry E.Metzger writes: Hmm. You need a cipher such that given B(A(M)) and A you can get B(M). I know of only one with that property -- XOR style stream ciphers. Unfortunately that makes for a big flaw, so I'm not sure we should throw out our Diffie-Hellman implementations yet. I believe that Pohlig-Hellman with the same modulus has this property, too. But I don't recall seeing any analysis if Pohlig-Hellman modulus reuse has the same failings as RSA with modulus reuse. --Steve Bellovin, http://www.research.att.com/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Open Source Embedded SSL - Export Questions
In message [EMAIL PROTECTED], J Harper writes: SSLv3 protocol implementation Simple ASN.1 parsing Cipher suites: TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA I understand the need to conserve space; that said, I strongly urge you to consider AES as well. If this is for embedded systems, it will live for a long time, and I expect AES to displace 3DES in the near future. --Steve Bellovin, http://www.research.att.com/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Problems with GPG El Gamal signing keys?
In message [EMAIL PROTECTED], Anton Stiglic writes : By the way, is the paper by Phong Q. Nguyen describing the vulnerability available somewhere? This note appeared on the IETF OpenPGP mailing list. -- Subject: Re: Removing Elgamal signatures From: David Shaw [EMAIL PROTECTED] Date: Mon, 1 Dec 2003 12:31:11 -0500 To: [EMAIL PROTECTED] On Mon, Dec 01, 2003 at 08:46:25AM -0800, Hal Finney wrote: It would be good to see these results made available because they might turn out to be applicable to other types of keys that we might consider in the future. The paper is as yet unpublished, but the author's web page with contact info is http://www.di.ens.fr/~pnguyen/ --Steve Bellovin, http://www.research.att.com/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: yahoo to use public key technology for anti-spam
In message [EMAIL PROTECTED], bear writes: But you should be sending mails via *your* SMTP server, and should be connecting to that SMTP server using SSL and authentication. Open relays encourage spam. People shouldn't be relaying mail via just any SMTP server. This is generally how I work it. I sit down at any hotspot and I get network connectivity. But all the hotspot is ever going to see of my browsing, email, and anything else I like to keep private is SSH packets to my home machine, or encrypted X packets running between the X server on my laptop and X clients on my home machine. A bit of lag is acceptable. Sending private mail via untrusted SMTP servers is not. That isn't Carl's point. He may very well be using a trustworthy SMTP server, via a secure tunnel. The issue is whether he has to use a server owned by the owner of his return address. I use a variety of email addresses, for various reasons. I have my usual work account, some university accounts, a few personal accounts, one I reserve for EBay use, etc. I also use several different SMTP servers to send my email. I *always* have a secure tunnel set up; in fact, Postfix on my laptop is hard-wired to send to port 20025 on 127.0.0.1. Of course, where that ends up will vary, but it's not in a one-to-one correspondence with the sending address I use. The Yahoo scheme would apparently require that each email I send be routed via the domain owner's SMTP server. --Steve Bellovin, http://www.research.att.com/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The future of security
In message [EMAIL PROTECTED], Ian Grigg writes: Security architects will continue to do most of their work with little or no crypto. And rightly so, since most security problems have nothing to do with the absence of crypto. j. a cryptographic solution for spam and viruses won't be found. This ties into the same thing: spam is *unwanted* email, but it's not *unauthorized*. Crypto can help with the latter, but only if you can define who is in the authorized set of senders. That's not feasible for most people. --Steve Bellovin, http://www.research.att.com/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The future of security
In message [EMAIL PROTECTED], Anton Stiglic writes: - Original Message - From: Steven M. Bellovin [EMAIL PROTECTED] j. a cryptographic solution for spam and viruses won't be found. This ties into the same thing: spam is *unwanted* email, but it's not *unauthorized*. Crypto can help with the latter, but only if you can define who is in the authorized set of senders. That's not feasible for most people. Something like hashcash / client puzzles / Penny Black define a set of authorized email (emails that come with a proof-of-work), and then provide a cryptographic solution. This is not a full-proof solution (as described in the paper Proof-of-Work Proves Not to Work), but a good partial solution that is probably best used in combination with other techniques such as white-lists, Bayesian spam filters , etc... I think cryptography techniques can provide a partial solution to spam. The spammers are playing with other people's money, cycles, etc. They don't care. --Steve Bellovin, http://www.research.att.com/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The future of security
In message [EMAIL PROTECTED], Ben Laurie writes: Steven M. Bellovin wrote: In message [EMAIL PROTECTED], Anton Stiglic write s: - Original Message - From: Steven M. Bellovin [EMAIL PROTECTED] j. a cryptographic solution for spam and viruses won't be found. This ties into the same thing: spam is *unwanted* email, but it's not *unauthorized*. Crypto can help with the latter, but only if you can define who is in the authorized set of senders. That's not feasible for most people. Something like hashcash / client puzzles / Penny Black define a set of authorized email (emails that come with a proof-of-work), and then provide a cryptographic solution. This is not a full-proof solution (as described in the paper Proof-of-Work Proves Not to Work), but a good partial solution that is probably best used in combination with other techniques such as white-lists, Bayesian spam filters , etc... I think cryptography techniques can provide a partial solution to spam. The spammers are playing with other people's money, cycles, etc. They don't care. We took that into account in the paper. Perhaps you should read it? http://www.dtc.umn.edu/weis2004/clayton.pdf We're saying something different. If I understood your paper correctly, it says, more or less, that setting the cost high enough to reduce spam will make the cost too high for legitimate users. My point is that even if you do raise the cost high enough, they'll become more aggressive at 0wning machine so that they can throw more (stolen) cylces or (stolen) zorkmids at the problem. The economic question, then, is what is the cost of compromising enough new machines. Given the code base and the user behavior that we see in the field, my answer is pretty low. The consequence, in your metric, would be an increase in C, which would further inconvenience legitimate users, thus creating a feedback loop. --Steve Bellovin, http://www.research.att.com/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Is finding security holes a good idea?
In message [EMAIL PROTECTED], Ben Laurie writes: What you _may_ have shown is that there's an infinite number of bugs in any particularly piece of s/w. I find that hard to believe, too :-) Or rather, that the patch process introduces new bugs. Let me quote from Fred Brooks' Mythical Man-Month, Chapter 11: The fundamental problem with program administration is that fixing a defect has a substantial (20-50 percent) chance of introducing another. So the whole process is two steps forward and one step back. Why arene't defects fixed more cleanly? First, even a subtle defect shows itself as a local failure of some kind. In fact it often has system-wide ramifications, usually nonobvious. Any attempt to fix it with minimum effort will repair the local and obvious, but unless the structure is pure or the documentation very fine, the far-reaching effects of the repair will be overlooked. Second, the repairer is usually not the man who wrote the code, and often he is a junior programmer or trainee. As a consequence of the introduction of new bugs, program maintenance requires far more system testing per statement written than any other programming. ... Lehman and Belady have studied the history of successive release in a large operating system. They find that the total number of modules increases linearly with release number, but that the number of modules affected increases exponentially with release number. All repairs tend to destroy the structure, to increase the entropy and disorder of the system. Less and less effort is spent on fixing original design flaws; more and more is spent on fixing flaws introduced by earlier fixes. As time passes, the system becomes less and less well-ordered. Sooner or later the fixing ceases to gain any ground. Each forward step is matched by a backward one. Etc. In other words, though the original code may not have had an infinite number of bugs, the code over time will produce an infinite series - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Question on the state of the security industry (second half not necessarily on topic)
In message [EMAIL PROTECTED], Jason H olt writes: [...] I had the same question about the NSA when some friends were interviewing there. Apparently investigators will just show up at your house and want to know all sorts of things about your friends, who you may or may not know to be in the process of looking for work there. As I understand it, the investigators don't even carry NSA badges; they're DSS or private investigators. In all seriousness, background investigations have been outsourced... I had a similar experience a few years ago. I was supposed to visit the --- agency. Someone I had *not* been dealing with called to ask for my social security number and birthdate. I declined, on the grounds that I had no idea who he was. But if I'm not legitimate, how do I know you're going to visit tomorrow? My reply was you're from --- and you don't think people can learn things they're not supposed to know? He was livid -- if you don't tell me, you can't visit. I told him that that was fine with me, and he should get my usual contact to call me. But he's unavailable today!. I indicated that I was still unconcerned -- and 10 minutes later, this unavailable person called me... On the other hand, when my broker called last week and asked for some confidential info, he was very understanding and co-operative when I declined to give out that information over the phone when he had called me. So it's not completely hopeless. --Steve Bellovin, http://www.research.att.com/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: EZ Pass and the fast lane ....
In message [EMAIL PROTECTED], John Gilmore writes: If they could read the license plates reliably, then they wouldn't need the EZ Pass at all. They can't. It takes human effort, which is in short supply. There are, in fact, toll roads that try to do that; see, for example, http://www.where.ca/toronto/subcategory_guide.cfm?subcategory_id=25category_id=24subtitle_id=142 But it's not foolproof; see http://66.102.7.104/search?q=cache:ELIC5NLh1qQJ:www.canoe.ca/Columnists/blizzard_feb18.html+ottawa+%22licence+plate%22+%22toll+road%22+toronto+problemhl=en (the original seems to have expired, hence the reference to the Google cache). --Steve Bellovin, http://www.research.att.com/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Using crypto against Phishing, Spoofing and Spamming...
In message [EMAIL PROTECTED], Ian Grigg writes: Don't be silly. It's not a threat because people generally use SSL. Back in the old days, password capture was a very serious threat. It went away with SSH. It seems to me quite likely that it would be a problem with web browsing in the absence of SSL. Right... It's easy to claim that it went away because we protected against it. Unfortunately, that's just a claim - there is no evidence of that. This is why I ask whether there has been any evidence of MITMs, and listening attacks. We know for example that there were password sniffing attacks back in the old days, by hackers. Hence SSH. Costs - Solution. But, there is precious little to suggest that credit cards would be sniffed - I've heard one isolated and unconfirmable case. And, there is similar levels of MITM evidence - anecdotes and some experiences in other fields, as reported here on this list. I think that Eric is 100% correct here: it doesn't happen because it's a low-probability attack, because most sites do use SSL. I think that people are forgetting just how serious the password capture attacks were in 1993-94. The eavesdropping machines were on backbones of major ISPs; a *lot* of passwords were captured. Furthermore, the technology has improved -- have you looked at dsniff lately, with the ARP-based active attack capability? And credit cards are much easier to grab -- they're probably sent in one packet, instead of several, and the number is a self-checking string of digits. It's also worth remembering that an SSL-like solution -- cryptographically protecting the transmission of credit card number, instead of digitally signing a funds transfer authorization linked to some account -- was more or less the only thing possible at the time. The Internet as a medium of commerce was too new for the banks to have developed something SET-like, and there wasn't an overwhelmingly-dominant client platform at the time for which custom software could be developed. (Remember that Windows 95 was the first version with an integral TCP/IP stack.) *All* that Netscape could deploy was something that lived in just the browser and Web server. SET itself failed because the incentives were never there -- consumers didn't perceive any benefit to installing funky software, and merchants weren't given much incentive to encourage it. --Steve Bellovin, http://www.research.att.com/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from [EMAIL PROTECTED]) (fwd from [EMAIL PROTECTED])
In message [EMAIL PROTECTED], Peter Gutmann writes: Eugen Leitl [EMAIL PROTECTED] writes: Maybe it's worth doing some sort of generic RFC for this security model to avoid scattering the same thing over a pile of IETF WGs, things like the general operational principles (store a hash of the server key, compare it on subsequent connects), how to present the value to the user (a format that's consistent across protocols would be nice), maybe a simple /etc/passwd-type file format listing servers and their matching hashes, etc etc etc. Sounds good. Who wants to write it...? --Steve Bellovin, http://www.research.att.com/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: IBM's original S-Boxes for DES?
In message [EMAIL PROTECTED], Nicolai Moles -Benfell writes: Hi, A number of sources state that the NSA changed the S-Boxes (and reduced the ke y size) of IBM's original DES submission, and that these change were made to strengthen the cipher against differential/linear/?? cryptanalysis. Does anybody have a reference to, or have an electronic copy of these original S-Boxes? It was only to protect against differential cryptanalysis; they did not know about linear cryptanalysis. See Don Coppersmith, The Data Encryption Standard (DES) and its strength against attacks, IBM Journal of Research and Development, Vol. 38, n. 3, pp. 243-250, May 1994. --Steve Bellovin, http://www.research.att.com/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: workshop on unwanted Internet traffic
In message [EMAIL PROTECTED], Steve Bellov in writes: Readers of this list may be interesting the the SRUTI -- Steps Towards Reducing Unwanted Traffic on the Internet -- workshop. See http://www.research.att.com/~bala/srut for details. CORRECTION: it's http://www.research.att.com/~bala/sruti --Steve Bellovin, http://www.research.att.com/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The Reader of Gentlemen's Mail, by David Kahn
In message [EMAIL PROTECTED], Bill Stewart writ es: My wife was channel-surfing and ran across David Kahn talking about his recent book The Reader of Gentlemen's Mail: Herbert O. Yardley and the Birth of American Codebreaking. ISBN 0300098464 , Yale University Press, March 2004 Amazon's page has a couple of good detailed reviews http://www.amazon.com/exec/obidos/ASIN/0300098464/qid=1105254301/sr=2-1/ref=pd _ka_b_2_1/102-1630364-0272149 I have the book. For the student of the history of cryptography, it's worth reading. For the less dedicated, it's less worthwhile. It's not The Codebreakers; it's not The Code Book; other than the title quote (and I assume most readers of this list know the story behind it), there are no major historical insights. The most important insight, other than Yardley's personality, is what he was and wasn't as a cryptanalyst. The capsule summary is that he was *not* a cryptanalytic superstar. In that, he was in no way a peer of or a competitor to Friedman. His primary ability was as a manager and entrepreneur -- he could sell the notion of a Black Chamber (with the notorious exception of his failure with Stimson), and he could recruit good (but not always great) people. But he never adapted technically. His forte was codes -- he know how to create them and how to crack them. But the world's cryptanalytic services were also learning how to crack them with great regularity; that, as much as greater ease of use, was behind the widespread adoption of machine cryptography (Enigma, M-209, Typex, Purple, etc.) during the interwar period. Yardley never adapted and hence he (and his organizations) became technologically obsolete. One of the reviews on Amazon.com noted skeptically Kahn's claim that Friedman was jealous of Yardley's success with women. I have no idea if that's true, though moralistic revulsion may be closer. But I wonder if the root of the personal antagonism may be more that of the technocrat for the manager... --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: entropy depletion
Let me raise a different issue: a PRNG might be better *in practice* because of higher assurance that it's actually working as designed at any given time. Hardware random number generators are subject to all sorts of environmental issues, including stuck bits, independent oscillators that aren't independent, contamination by power line frequency noise, etc. By contrast, a correct implementation of a cryptographic algorithm will always function correctly. (Yes, there could be an undetected hardware fault. Run it three times, on different chips) To me, the interesting question about, say, Yarrow is not how well it mixes in entropy, but how well it performs when there's essentially no new entropy added. Clearly, we need something to see a PRNG, but what are the guarantees we have against what sorts of threats if there are never any new true-random inputs? (Remember the purported escrow key generation algorithm for Clipper? See http://www.eff.org/Privacy/Newin/Cypherpunks/930419.denning.protocol for details. The algorithm was later disavowed, but I've never been convinced that the disavowal was genuine.) --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Cryptanalytic attack on an RFID chip
Steve Bono, Matthew Green, Adam Stubblefield, Ari Juels, Avi Rubin, and Michael Szydlo have successfully attacked a cryptographically-enabled RFID chip made by Texas Instruments. This chip is used in anti-theft automobile immobilizers and in the ExxonMobil SpeedPass. You can find details at http://www.rfidanalysis.org/ (and a link to the draft paper), and a New York Times article at http://www.nytimes.com/2005/01/29/national/29key.html The paper itself is very nice, and combines RF techniques, cryptanalysis, Internet sleuthing, space-time tradeoffs, and more. There are some points I'm sure we'll be discussing at length, such as the authors' decision to withhold some of the details of their attack, the actual effective range of an RFID transponder when the attacker uses a suitable antenna, and the practical significance of the work. But oddly enough, what struck me was TI's response: rather than attacking the researchers, they co-operated, to the extent of providing them with challenge keys to see if the technique was really that effective. TI is to be congratulated -- such a response is all too rare. Btw, the paper suggests carrying car keys or SpeedPasses in aluminum foil. I suspect that a more practical form factor is a spring-loaded conductive sleeve that normally surrounds the RFID chip, but is push back either manually or on key insertion. --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Is 3DES Broken?
In message [EMAIL PROTECTED], Aram Perez writes: Hi Folks, I hate to bother you with what I consider a dumb question, but I'm trying to give a person the benefit of my doubts. There's a person on a legal forum that I participate in that claims that 3DES has been broken/cracked. However, he has not provided any documentation to the effect as his time at present is limited and valuable. He claims that the specifics were already posted on this and several other similar forums. Other than Ross Anderson and his students extracting a 3DES key from an IBM4758, has 3DES been in fact broken? Thank you, Aram Perez [Moderator's note: The quick answer is no. The person who claims otherwise is seriously misinformed. I'm sure others will chime in. --Perry] I'll be happy to second Perry's comment -- I've seen no evidence whatsoever to suggest that it's been broken. But there are some applications where it's a bad choice for cryptographic reasons. When using CBC mode, one should not encrypt more than 2^32 64-bit blocks under a given key. That comes to ~275G bits, which means that on a GigE link running flat out you need to rekey at least every 5 minutes, which is often impractical. Since I've seen Gigabit Ethernet cards for US$25, this bears thinking about -- and while 10GigE is still too expensive for most people, its prices are dropping rapidly. With 10GigE, you'd have to rekey every 27.5 seconds... For reference purposes, with AES you'd be safe for 2^64*128 bits. That's a Big Number of seconds. --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: how to tell if decryption was successfull?
In message [EMAIL PROTECTED], Andreas writes: [newbie here] I was wondering how can one tell if some data was successfully decrypted. Isn't there an assumption going on about what the cleartext data should be? Text? Image? ZIP file? Ziped jpeg? Another cyphertext? rot-13? There are a lot of ways to tell, but you generally have to have some idea what you're looking for. For two examples of how to do it, see http://www1.cs.columbia.edu/~smb/papers/probtxt.ps (or .pdf) and http://www1.cs.columbia.edu/~smb/papers/recog.ps (or .pdf) --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Dell to Add Security Chip to PCs
In message [EMAIL PROTECTED], Dan Kaminsky writes: Uh, you *really* have no idea how much the black hat community is looking forward to TCPA. For example, Office is going to have core components running inside a protected environment totally immune to antivirus. How? TCPA is only a cryptographic device, and some BIOS code, nothing else. Does the coming of TCPA chips eliminate the bugs, buffer overflows, stack overflows, or any other way to execute arbitrary code? If yes, isn't that a wonderful thing? Obviously it doesn't (eliminate bugs and so on). TCPA eliminates external checks and balances, such as antivirus. As the user, I'm not trusted to audit operations within a TCPA-established sandbox. Antivirus is essentially a user system auditing tool, and TCPA-based systems have these big black boxes AV isn't allowed to analyze. Imagine a sandbox that parses input code signed to an API-derivable public key. Imagine an exploit encrypted to that. Can AV decrypt the payload and prevent execution? No, of course not. Only the TCPA sandbox can. But since AV can't get inside of the TCPA sandbox, whatever content is protected in there is quite conspicuously unprotected. It's a little like having a serial killer in San Quentin. You feel really safe until you realize...uh, he's your cellmate. I don't know how clear I can say this, your threat model is broken, and the bad guys can't stop laughing about it. I have no idea whether or not the bad guys are laughing about it, but if they are, I agree with them -- I'm very afriad that this chip will make matters worse, not better. With one exception -- preventing the theft of very sensitive user-owned private keys -- I don't think that the TCPA chip is solving the right problems. *Maybe* it will solve the problems of a future operating system architecture; on today's systems, it doesn't help, and probably makes matters worse. TCPA is a way to raise the walls between programs executing in different protection spaces. So far, so good. Now -- tell me the last time you saw an OS flaw that directly exploited flaws in conventional memory protection or process isolation? They're *very* rare. The problems we see are code bugs and architectural failures. A buffer overflow in a Web browser still compromises the browser; if the now-evil browser is capable of writing files, registry entries, etc., the user's machine is still capable of being turned into a spam engine, etc. Sure, in some new OS there might be restrictions on what such an application can do, but you can implement those restrictions with today's hardware. Again, the problem is in the OS architecture, not in the limitations of its hardware isolation. I can certainly imagine an operating system that does a much better job of isolating processes. (In fact, I've worked on such things; if you're interested, see my papers on sub-operating systems and separate IP addresses per process group.) But I don't see that TCPA chips add much over today's memory management architectures. Furthermore, as Dan points out, it may make things worse -- the safety of the OS depends on the userland/kernel interface, which in turn is heavily dependent on the complexity of the privileged kernel modules. If you put too much complex code in your kernel -- and from the talks I've heard this is exactly what Microsoft is planning -- it's not going to help the situation at all. Indeed, as Dan points out, it may make matters worse. Microsoft's current secure coding initiative is a good idea, and from what I've seen they're doing a good job of it. In 5 years, I wouldn't be at all surprised if the rate of simple bugs -- the buffer overflows, format string errors, race conditions, etc. -- was much lower in Windows and Office than in competing open source products. (I would add that this gain has come at a *very* high monetary cost -- training, code reviews, etc., aren't cheap.) The remaining danger -- and it's a big one -- is the architecture flaws, where ease of use and functionality often lead to danger. Getting this right -- getting it easy to use *and* secure -- is the real challenge. Nor are competing products immune; the drive to make KDE and Gnome (and for that matter MacOS X) as easy to use (well, easier to use) than Windows is likely to lead to the same downward security sprial. I'm ranting, and this is going off-topic. My bottom line: does this chip solve real problems that aren't solvable with today's technology? Other than protecting keys -- and, of course, DRM -- I'm very far from convinced of it. The fault, dear Brutus, is not in our stars but in ourselves. --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
link-layer encryptors for Ethernet?
Are there any commercial link-layer encryptors for Ethernet available? I know that Xerox used to make them, way back when, but are there any current ones, able to deal with current speeds (and connectors)? --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: link-layer encryptors for Ethernet?
In message [EMAIL PROTECTED], james hughes writes: The following device is a layer 2 tunneling device that has 256 bit AES at up to 400Mb/s. http://blueridgenetworks.com/products/index.htm http://blueridgenetworks.com/support/borderguard_vpn__serv_res_ctr.htm Layer 2? It seems to be an IPsec box. At the least, their Administrator's Guide talks about using IP Protocol 50. --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: link-layer encryptors for Ethernet?
In message [EMAIL PROTECTED], Anne Lynn Wheeler writes: the internal network was larger than the arpanet/internet just about the whole time up until about mid-85. all the links leaving physical premise had to be encrypted ... there was the claim that over half of all encrypters in the world were on the internal network (and put at least one of the major products/companies into business). lots of random comments about about the internal network http://www.garlic.com/~lynn/subtopic.html#internalnet small sample posting about the internal net passing 1000 nodes not long after internet passed 255 nodes. http://www.garlic.com/~lynn/internet.htm#22 one of the big issues in part of this period was getting encrypters on links that cross national boundaries. Yup. Often, large corporations had policies requiring them, because of how frequently a transoceanic fiber would be cut and the circuits rerouted to satellite. --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
In message [EMAIL PROTECTED], Amir Herzberg writes: Want to see a simple, working method to spoof sites, fooling Mozilla/FireFox/... , even with an SSL certificate and `lock`? http://www.shmoo.com/idn/ See also: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItemitem=3866526512 Want to protect your Mozilla/FireFox from such attacks? Install our TrustBar: http://TrustBar.Mozdev.org (this was the first time that I had a real reason to click the `I don't trust this authority` button...) Actually, both Trustbar and checking the certificate are working because the code isn't right yet -- those sections of code (in Firefox) don't understand IDN yet, and they need to. Sure, they're catching a problem here, but they're catching the problem for those network users who are expecting and reading ASCII characters. But think of, say, the Japanese user who would like to see that the certificate really was issued to some string of Kanji, and instead sees the IDN encoding? That's less than helpful -- he or she would have no way whatsoever of verifying the certificate. --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: link-layer encryptors for Ethernet?
In message [EMAIL PROTECTED], Chris Kuethe writes: http://www.gdds.com/company/portfolio.html#ias http://www.gdc4s.com/Products/sectera.htm Maybe one of these nifty looking general dynamics widgets is what you're afte r? Anything beginning with KG or KO is government, and not what I'm looking for. The KG-235, which your second URL took me to, is for TS/SCI traffic -- *way* above what I need... --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
In message [EMAIL PROTECTED], Amir Herzberg writes: Steve, my point was not the trivial fact that TrustBar would not display the homograph; suppose it did... even then, the user is _asked_ about the certificate, since it was signed by an unusual CA that the user did not specify as `to be trusted always`; this should certainly be a good warning for most users (and of course, a good situation to check for tricks such as homographs...). And even if some user allowed this CA as `always trusted`, there is still a fair chance he'll notice that the brand of CA on his bank's site has suddenly changed... which may also raise the alarm. Unusual CA? I'm not sure what a *usual* CA is. Just for fun, I opened up the CA list that came with my copy of Firefox. There are no fewer than 40 different entities listed, many of whom have more than one certificate. I personally know less than half of them to be trustworthy -- and that's assuming that, say, Thawte, Thawte Consulting, and Thawte Consulting cc are all the same company and I can count that as three different ones. I had no idea that that the U.S. Postal Service had a CA that was trusted by my browser -- and I dare say that many non-Americans wouldn't trust it at all, on the assumption that it would do whatever the U.S. government told it to do. (For such people: the relationship between the USPS and the government is complex. Let it suffice to say that they moved from .gov to .com, and they had quasi-valid reasons for doing so.) Baltimore is listed; last I heard, they were out of business. Is a private root key (or the equivalent signing device) an asset that can be acquired under bankruptcy proceedings? Almost certainly. The following text appears in the December 2004 Shareholder Circular I found at www.baltimore.com: The Company sold the last of its remaining operating businesses in 2003, and has not engaged in operating activities since that time. Since taking office in July 2004, the Company's new Board of Directors has been working to resolve all significant legacy issues, to identify a means of utilising the Company's remaining non-cash assets, toreduce costs so as to maximise the cash available for future deployment and to review appropriate business opportunities to enhance shareholder value. Paragraph 5 of Part II of this document describes, among other things, the current position relating to the utilisation of the Company's non-cash assets. Apart from the question of whether or not EvilHackerDudes.Org, a sub rosa corporation, purchased that key, the fact that this CA is out of business is certainly good cause for a bank to change its CA. Would you like to be the supervisor of customer service when people start calling about this problem their browser is complaining about? Remember that 99.99% of people have no idea what a certificate is, what a CA is, or how to judge whether or not a given CA exercises due diligence when issuing a cert. One member of this mailing list, in a private exchange, noted that he had asked his bank for their certificate's fingerprint. My response was that I was astonished he found someone who knew what he was talking about. I'm not saying your toolbar is a bad idea; in fact, I think it's a good one. But the problem of verifying certificates is a very deep one, and simple answers will not solve the phishing or MITM problem. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
SHA-1 cracked
According to Bruce Schneier's blog (http://www.schneier.com/blog/archives/2005/02/sha1_broken.html), a team has found collisions in full SHA-1. It's probably not a practical threat today, since it takes 2^69 operations to do it and we haven't heard claims that NSA et al. have built massively parallel hash function collision finders, but it's an impressive achievement nevertheless -- especially since it comes just a week after NIST stated that there were no successful attacks on SHA-1. --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SHA-1 cracked
In message [EMAIL PROTECTED], Alexandre Dulaunoy writes: On Tue, 15 Feb 2005, Steven M. Bellovin wrote: According to Bruce Schneier's blog (http://www.schneier.com/blog/archives/2005/02/sha1_broken.html), a team has found collisions in full SHA-1. It's probably not a practical threat today, since it takes 2^69 operations to do it and we haven't heard claims that NSA et al. have built massively parallel hash function collision finders, but it's an impressive achievement nevertheless -- especially since it comes just a week after NIST stated that there were no successful attacks on SHA-1. and what about HMAC-SHA1 ? Is it reducing the operation required by the same factor or as the structure of HMAC is so different that the attack is very unlikely to be practical ? As the blog entry mentions, it's it's unlikely that SHA-1 is affected. That said, the attack merits close attention; as Schneier has noted in other contexts, attacks always get better, never worse. --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [IP] One cryptographer's perspective on the SHA-1 result
Burt Kaliski posted the following to Dave Farber's IP list. I was about to post something similar myself. Beyond that, it is now clear that the industry needs an open evaluation process -- like the Advanced Encryption Standard competition -- to establish a new hash function standard for the long term, or at least an alternative if SHA-256 and above turn out still to be good enough after review. As he quite eloquently pointed out, we have a near-monoculture of hash algorithms. Virtually every well-known hash algorithm, with the exception of Whirlpool, is derived from MD2/MD4/MD5. At the time SHA-0 was released, in fact, there was a great deal of speculation that NSA had copied Rivest's framework to avoid disclosing any new principles for hash function construction. I have no idea if that's true or not. As we all know, even NSA found SHA more problematic than they would have hoped; witness the release of SHA-1 not all that long afterwards. When NIST released SHA256/384/512 shortly after AES, but without a public competition, the word was that they didn't have the resources to run two simultaneous large-scale, open processes. That's a fair statement, and given the choice between an openly-chosen encryption algorithm and an openly-chosen hash function I think most of us would have made the same decision. I don't know if there's quite the need for open process for a hash function as there was for a secrecy algorithm. The AES process, after all, had to cope with the legacy of Clipper and key escrow, to say nothing of the 25 years of DES paranoia that was only laid to rest by the reinvention of differential cryptanalysis. (The Deep Crack machine only confirmed another part of the paranoia, of course, but the essential parameter it exploited -- key size -- was both obviously insufficient in 1979 and obviously sufficient from the requirements of the AES competition.) It is clear, as Burt said, that we need a large-scale effort to produce new and better hash functions. To try to repair the MD*/SHA* family is to risk the cry of epicycles. --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: FUD about CGD and GBDE
In message [EMAIL PROTECTED], Thor Lancelot Simon writes: On Thu, Mar 03, 2005 at 05:31:34PM +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], ALeine writes: Not necessarily, if one were to implement the ideas I proposed I believe the performance could be kept at the same level as now. I gave up on journalling myself because IMO it complicates things a lot and the problem it solves is very very small. The impact in disk seeks is non-trivial to predict, but it is very hard to argue that it will not lead to an increase in disk seeks. (This is really a variant of the age old argument between jounaling filesystems and traditional filesystems) I can only recommend that you try :-) We need more ideas and more people trying out ideas. I could not disagree more. When it comes to nonstandard homebrewed cryptosystems foisted off on unsuspecting users with a bundle of claims of algorithm strength that they're not competent to evaluate for themselves, we do not need more ideas, nor more people trying out ideas; we need less. Standard, widely analyzed cryptographic algorithms are good. What Thor said. It's instructive to quote from Vol. 2 of Knuth: With all the precautions taken in Algorithm K, doesn't it seem plausible that it would produce at least an infinite supply of unbelievably random numbers? No! In fact, when this algorithm was first put onto a computer, it almost immediately converged to the 10-digit value 6065038420, which---by extraordinary coincidence---is transformed into itself by the algorithm (see Table 1). With another starting number, the sequence began to repeat after 7401 values, in a cyclic period of length 3178. The moral to this story is that *random numbers should not be generated with a method chosen at random*. Some theory should be used. And Knuth was talking about a situation without an adversary. I don't claim that there's a flaw. I do assert that that I haven't seen a threat model that would justify extra complexity. Let me go one step further. The cryptographic literature is full of examples of broken protocols. My favorite is the flaw in the original Needham-Schroeder protocol, from 1978, that went unnoticed until 1996, when an automated tool found it. I should add that once pointed out, the flaw is blindingly obvious -- but it went unnoticed for 18 years, in the oldest protocol in the open literature. Btw, in modern terms this protocol is 3 lines long. One more quote, this time a remarkably prescient one from that Needham and Schroeder: Finally, protocols such as those developed here are prone to extremely subtle errors that are unlikely to be detected in normal operation. The need for techniques to verify the correctness of such protocols is great, and we encourage those interested in such problems to consider this area. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
NSA warned Bush it needed to monitor networks
http://www.nytimes.com/aponline/national/AP-Spy-Agency-Documents.html WASHINGTON (AP) -- The National Security Agency warned President Bush in 2001 that monitoring U.S. adversaries would require a ``permanent presence'' on networks that also carry Americans' messages that are protected from government eavesdropping. ... ``Make no mistake, NSA can and will perform its missions consistent with the Fourth Amendment and all applicable laws,'' the document says. ... - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
how to phase in new hash algorithms?
We all understand the need to move to better hash algorithms than SHA1. At a minimum, people should be switching to SHA256/384/512; arguably, Whirlpool is the right way to go. The problem is how to get there from here. OpenSSL 0.9.7 doesn't even include anything stronger than SHA1. As a practical matter, this means that no one can use anything stronger in certificates, especially root certificates. Worse yet, people can't use anything stronger for public consumption for at least five years after a stronger hash algorith is available -- we have to wait until most older software has died off, since most machines are never upgraded. This means that appearance of the code in client machines is on the critical path. I've heard that OpenSSL 0.9.8 will include stronger hashes, but there's no work in progress to backport the code to 0.9.7. So -- what should we as a community be doing now? There's no emergency on SHA1, but we do need to start, and soon. --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NSA warned Bush it needed to monitor networks
A few days ago, I posted this: WASHINGTON (AP) -- The National Security Agency warned President Bush in 2001 that monitoring U.S. adversaries would require a ``permanent presence'' on networks that also carry Americans' messages that are protected from government eavesdropping. ... ``Make no mistake, NSA can and will perform its missions consistent with the Fourth Amendment and all applicable laws,'' the document says. Today, I happened to learn the URL for the document itself: http://www.gwu.edu/~nsarchiv/NSAEBB/NSAEBB24/nsa25.pdf . There's little that strikes me as sensitive in it, other than the (redacted) budget numbers. What's someplace between amusing and appalling is some of the other things that NSA had considered sensitive. For example, consider this paragraph, from page 5: The National Security Agency has a proud tradition of serving the nation. NSA has been credited with preventing or significantly shortening military conflicts, thereby saving lives of U.S. military and civilian personnel. NSA gives the nation a decisive edge in policy interactions with other nations, in countering terrorism, and in helping stem the flow of narcotics into our country. NSA has been the premier information agency of the industrial age, and through ongoing modernization and cutting edge research, will continue to be the premiere knowledge agency of the information age. That paragraph, believe it or not, was classified Secret. For what it's worth, the official definition of Secret, from Executive Order 12958 (http://www.dss.mil/seclib/eo12958.htm), is: Secret shall be applied to information, the unauthorized disclosure of which reasonably could be expected to cause serious damage to the national security that the original classification authority is able to identify or describe. What in that paragraph could cause serious damage? The notion that NSA gives the U.S. government an edge in policy interactions, i.e., it may spy on foreign governments? I'm shocked, shocked to hear that. Then there are the paragraphs on pages 16 and 17 that describe NSA's legislative lobbying on crypto legislation. Those were marked FUOO -- For Official Use Only. DD Form 254 says The For Official Use Only (FOUO) marking is assigned to information at the time of its creation in a DoD User Agency. It is not authorized as a substitute for a security classification marking but it is used on official government information that may be withheld from the public under exemptions 2 through 9 of the Freedom of Information Act. Why is that information eligible to be withheld? Because it tells the public that NSA is interested in legislation about crypto and exports? I could go on, but the topic of overclassification is well-worn. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Encryption plugins for gaim
In message [EMAIL PROTECTED], Peter Saint-Andre writes: On Tue, Mar 15, 2005 at 02:02:31PM -0500, Adam Fields wrote: On Tue, Mar 15, 2005 at 12:54:19PM -0600, Peter Saint-Andre wrote: Why not help us make Jabber/XMPP more secure, rather than overloading AIM? With AIM/MSN/Yahoo your account will always exist at the will of Unfortunately, I already have a large network of people who use AIM, and they all each have large networks of people who use AIM. Many of them still use the AIM client. Getting them to switch to gaim is feasible. Getting them to switch to Jabber is not. However, getting them to switch to gaim first, and then ultimately Jabber might be an option. Frankly, the former is more important to me in the short term. Yep, the same old story. :-) AOL, whereas with XMPP you can run your own server etc. Unfortunately Does can == have to? From what I remember of trying to run Jabber a few years ago, it did. No, we have 200k registered users on the jabber.org server and some servers have even more. You can run your own server, though, and accept connections only from other servers you trust, etc. Let me second the recommendation for jabber (though I wish the code quality of some of the components were better). The protocol itself supports TLS for client-to-server encryption; you can also have AIM (or other IM) gateways on that server. In many situations (i.e., wireless), it protects the most vulnerable link from eavesdropping. While clearly not as good as end-to-end encryption, it's far better than nothing, especially in high-threat environments such as the IETF... (Of course, I only know of one open source client -- psi -- that checks the server certificate.) In theory, server-to-server communications can also be TLS-protected, though I don't know if any platforms support that. On top of any other encryption, many implementations support PGP encryption between correspondents. I don't know of any support for e2e-encrypted chat rooms. I haven't played with OTR, nor am I convinced of the threat model. That said, what you really need to watch out for is the transcript files on your own machine... --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Schneier: SHA-1 has been broken - Time for a second thought about SDLH ?
In message [EMAIL PROTECTED], Ralf Senderek w rites: And that is why I ask to give the Shamir Discrete Logarithm Hash Funktion a se cond thought. At leeast we have a proof of collision resistance under the assumptio n that factoring is infeasible for the modulus used. And that it more than we ever had regarding the MD4 series. BTW, choosing the next generation hash function should - as I think - not be dominated by terms of performance. (i.e done in the olde fashion) Dominated? No, of course not. But a hash function based on discrete log will be slow enough that no one will use it. --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Moore says his law won't last
http://www.vnunet.com/news/1162433 Something like this cannot continue forever, he said. The dimensions are small enough now that we're approaching the size of atoms and that's a fundamental block. I think the law has another 10-20 years before fundamental limits are reached. This has obvious implications for brute force attacks -- projections based on Moore's Law are thus much too conservative. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Three NIST Special Pubs for Review (Forwarded)
--- Forwarded Message Date: Thu, 21 Apr 2005 13:29:28 -0400 To: [EMAIL PROTECTED] From: Elaine Barker [EMAIL PROTECTED] Subject: Three NIST Special Pubs for Review There are three NIST Special Publications available for public review and comment: SP 800-38B: As part of NIST's ongoing effort to update and develop modes of operation for use with the AES algorithm, NIST intends to recommend either the Galois Counter Mode (GCM) or the Carter-Wegman + Counter (CWC) mode. GCM and CWC are modes for authenticated encryption with associated data, combining Counter mode confidentiality with authentication that is based on a universal hash algorithm. Both GCM and CWC are parallelizable. The submission documents specifying GCM and CWC are available through the modes home page, http://nist.gov/modeshttp://nist.gov/modes. NIST invites comments on these two modes, including comments on intellectual property matters, by June 1, 2005, at mailto:[EMAIL PROTECTED][EMAIL PROTECTED] SP 800-57, Parts 1 and 2: Drafts of NIST Special Publication 800-57 Recommendation for Key Management, Parts 1 and 2 are available for public comment at http://csrc.nist.gov/publications/drafts.htmlhttp://csrc.nist.gov/publications/drafts.html. This Recommendation provides cryptographic key management guidance. Part 1 provides guidance and best practices for the management of cryptographic keying material. Comments will be accepted on Part 1 until June 3, 2005. Please send comments to mailto:[EMAIL PROTECTED][EMAIL PROTECTED], with Comments on SP 800-57, Part 1 in the subject line. Part 2 provides guidance on policy and security planning requirements for U.S. government agencies. Reviewers of Part 2 should note that a number of the security planning documents referenced in this part of SP 800-57 are undergoing review and revision. It is anticipated that Part 2 will be updated to reflect these revisions. Comments will be accepted on Part 2 until May 18, 2005. Please send comments to mailto:[EMAIL PROTECTED][EMAIL PROTECTED], with Comments on SP 800-57, Part 2 in the subject line. Elaine Barker 100 Bureau Drive, Stop 8930 Gaithersburg, MD 20899 Phone: 301-975-2911 --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: What happened with the session fixation bug?
In message [EMAIL PROTECTED], James A. Donald writes: -- PKI was designed to defeat man in the middle attacks based on network sniffing, or DNS hijacking, which turned out to be less of a threat than expected. First, you mean the Web PKI, not PKI in general. The next part of this is circular reasoning. We don't see network sniffing for credit card numbers *because* we have SSL. Since many of the worm-spread pieces of spyware incorporate sniffers, I'd say that part of the threat model is correct. As for DNS hijacking -- that's what's behind pharming attacks. In other words, it's a real threat, too. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL stops credit card sniffing is a correlation/causality myth
In message [EMAIL PROTECTED], Ian G writes: On Tuesday 31 May 2005 02:17, Steven M. Bellovin wrote: In message [EMAIL PROTECTED], James A. Donald writes: -- PKI was designed to defeat man in the middle attacks based on network sniffing, or DNS hijacking, which turned out to be less of a threat than expected. First, you mean the Web PKI, not PKI in general. The next part of this is circular reasoning. We don't see network sniffing for credit card numbers *because* we have SSL. I think you meant to write that James' reasoning is circular, but strangely, your reasoning is at least as unfounded - correlation not causality. And I think the evidence is pretty much against any causality, although this will be something that is hard to show, in the absence. Given the prevalance of password sniffers as early as 1993, and given that credit card number sniffing is technically easier -- credit card numbers will tend to be in a single packet, and comprise a self-checking string, I stand by my statement. * AFAICS, a non-trivial proportion of credit card traffic occurs over totally unprotected traffic, and that has never been sniffed as far as anyone has ever reported. (By this I mean lots of small merchants with MOTO accounts that don't bother to set up proper SSL servers.) Given what a small percentage of ecommerce goes to those sites, I don't think it's really noticeable. * We know that from our experiences of the wireless 802.11 crypto - even though we've got repeated breaks and the FBI even demonstrating how to break it, and the majority of people don't even bother to turn on the crypto, there remains practically zero evidence that anyone is listening. FBI tells you how to do it: https://www.financialcryptography.com/mt/archives/000476. Sure -- but setting up WEP is a nuisance. SSL (mostly) just works. As for your assertion that no one is listening, I'm not sure what kind of evidence you'd seek. There's plenty of evidence that people abuse unprotected access points to gain connectivity. As an alternate hypothesis, credit cards are not sniffed and never will be sniffed simply because that is not economic. If you can hack a database and lift 10,000++ credit card numbers, or simply buy the info from some insider, why would an attacker ever bother to try and sniff the wire to pick up one credit card number at a time? Sure -- that's certainly the easy way to do it. And if they did, why would we care? Better to let a stupid thief find a way to remove himself from a life of crime than to channel him into a really dangerous and expensive crime like phishing, box cracking, and purchasing identity info from insiders. Since many of the worm-spread pieces of spyware incorporate sniffers, I'd say that part of the threat model is correct. But this is totally incorrect! The spyware installs on the users' machines, and thus does not need to sniff the wire. The assumption of SSL is (as written up in Eric's fine book) that the wire is insecure and the node is secure, and if the node is insecure then we are sunk. I meant precisely what I said and I stand by my statement. I'm quite well aware of the difference between network sniffers and keystroke loggers. Eric's book and 1.2 The Internet Threat Model http://iang.org/ssl/rescorla_1.html Presence of keyboard sniffing does not give us any evidence at all towards wire sniffing and only serves to further embarrass the SSL threat model. As for DNS hijacking -- that's what's behind pharming attacks. In other words, it's a real threat, too. Yes, that's being tried now too. This is I suspect the one area where the SSL model correctly predicted a minor threat. But from what I can tell, server-based DNS hijacking isn't that successful for the obvious reasons (attacking the ISP to get to the user is a higher risk strategy than makes sense in phishing). They're using cache contamination attacks, among other things. ... As perhaps further evidence of the black mark against so-called secure browsing, phishers still have not bothered to acquire control-of-domain certs for $30 and use them to spoof websites over SSL. Now, that's either evidence that $30 is too much to pay, or that users just ignore the certs and padlocks so it is no big deal anyway. Either way, a model that is bypassed so disparagingly without even a direct attack on the PKI is not exactly recommending itself. I agre completely that virtually no one checks certificates (or even knows what they are). --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Citibank discloses private information to improve security
Bank of America is adopting some new schemes that might help. First, they're asking users to select a picture the user selected at registration time. The theory is presumably that a phishing site won't have the right image for you. Second, you can register your computer; if your account is accessed from another computer, additional authentication is demanded, thus rendering a compromised password much less useful. I think both schemes will help; I doubt that either will stop the problems. http://www.bankofamerica.com/newsroom/press/press.cfm?PressID=press.20050526.03.htm --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
analysis of the Witty worm
Readers of this list may be interested in an analysis of the Witty worm's spread by Kumark, Paxson, and Weaver. An article summarizing the paper is at http://www.zdnet.co.uk/print/?TYPE=storyAT=39200183-39020375t-1025c A tentative conclusion is that the worm was probably written by an insider at ISS The paper itself (there's a link in the article) has several more items of interest to this list. Especially interesting is the effective cryptanalysis of the PRNG used by the worm. Implicit in many of the analyses, though not a focus of the paper, is the amount of information that the authors could gather about network configurations at different sites: as we all know, traffic analysis is a powerful technique. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: encrypted tapes (was Re: Papers about Algorithm hiding ?)
In message [EMAIL PROTECTED], Perry E. Metzger writes: The truth is, the likely reason no one encrypted the data on the tapes in transit was because no one thought to do it, or they were too lazy to bother to make even the simplest effort, or both. I don't completely agree. While I suspect that laziness or lack of thought are the primary problems, there are some real costs. The minor one is compression: most modern tape drives compress the data before writing, and you can't compress encrypted data. That means they'd need to compress in software before writing to the tape; that chews up CPU time that they may not have to spare on the machines in question. (Remember that we're talking about massive amounts of data here.) The bigger issue, though, is more subtle: keeping track of the keys is non-trivial. These need to be backed up, too, and kept separate from (but synchronized with) the tapes. Worse yet, they need to be kept secure. That may mean storing the keys with a different escrow company. A loss of either piece,the tape or the key, renders the backup useless. Backups are not very reliable to start with. Too few companies do regular checks on the adequacy or quality of their backups. Most companies feel they can't afford lowering the reliability even further. ... The only thing that will fix this having enough people get so badly burned that CEOs start taking heads when people do dumb things. I imagine it can't be too many more years before that becomes the case. Bingo. Especially the CEO's head -- or the CFO's head, or the general counsel's -- for some of the mistakes we've seen. But there's no one cause. For those who subscribe to the Wall Street Journal online, see http://online.wsj.com/documents/info-idtheft0504.html?mod=technology_main_promo_left for a chart of recent failures to protect identity data. Of the 10 failures for which a cause is listed, though, 4 were loss of tapes in transit. (One was a shipment of tapes to a credit bureau.) 2 involved hacking, one was an inside job, one was a stolen laptop, and 2 were fraudulent use of logins and passwords. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AmEx unprotected login site
In message [EMAIL PROTECTED], Perry E. Metzger writes: Jerrold Leichter [EMAIL PROTECTED] writes: If you look at their site now, they *claim* to have fixed it: The login box has a little lock symbol on it. Click on that, and you get a pop-up window discussing the security of the page. It says that although the page itself isn't protected, your information is transmitted via a secure environment. No clue as to what exactly they are doing, hence if it really is secure. They're still doing the wrong thing. Unless the page was transmitted to you securely, you have no way to trust that your username and password are going to them and not to someone who cleverly sent you an altered version of the page. They're doing the wrong thing, and probably feel they have no choice. Setting up an SSL session is expensive; most people who go to their home page do not log in, and hence do not (to Amex) require cryptographic protection. A few years ago, I talked with someone who was setting up a system that really needed security. Given how few pages people would visit on the site, though, he estimated that it would increase his costs by a factor of about 15. (I didn't verify the numbers; I know from experience that he's competent and has his hear in the right place re security). --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AmEx unprotected login site
In message [EMAIL PROTECTED], Perry E. Metzger writes: Steven M. Bellovin [EMAIL PROTECTED] writes: They're still doing the wrong thing. Unless the page was transmitted to you securely, you have no way to trust that your username and password are going to them and not to someone who cleverly sent you an altered version of the page. They're doing the wrong thing, and probably feel they have no choice. Setting up an SSL session is expensive; most people who go to their home page do not log in, and hence do not (to Amex) require cryptographic protection. That's why Citibank and most well run bank sites have you click on a button on the front page to go to the login screen. There are ways to handle this correctly. There's an attack there, too -- one can divert the link to the login screen. The other major offender are organizations (such as portions of Verizon) that subcontract payment systems to third parties. They are training their users to expect to be directed to a site they don't recognize to enter in their credit card information. Really! This is your vendor's payment site! Pay no attention to the URL and certificate! That one in particular takes amazing brains... It's a tough problem: they want to outsource the payment processing, but don't have the infrastructure to do so properly. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: analysis of the Witty worm
In message [EMAIL PROTECTED], Jerrold Leichter writes: | | The paper itself (there's a link in the article) has several more items | | of interest to this list. Especially interesting is the effective | | cryptanalysis of the PRNG used by the worm. Implicit in many of the | | analyses, though not a focus of the paper, is the amount of information | | that the authors could gather about network configurations at different | | sites: as we all know, traffic analysis is a powerful technique. | The links in the paper no longer work - they go to restricted pages. The | (or an) HTML version is in the Google cache at: | | http://64.233.161.104/search?q=cache:oS94i-ojvIgJ:www.cc.gatech.edu/~akumar/ witty.html+witty+worm+analysis+paxsonhl=enstart=1 Oops. I should have read it more closely first. The only thing in Google's cache is the intro page, with an abstract. The paper (pdf and ps) and a slide show are inaccessible, and are not in Google's cache. Anyone saved a copy? It's on Vern's web page: http://www.icir.org/vern/papers/witty-draft.pdf or http://www.icir.org/vern/papers/witty-draft.ps --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
AES cache timing attack
Dan Bernstein has a new cache timing attack on AES: http://cr.yp.to/antiforgery/cachetiming-20050414.pdf (This was mentioned in Bruce Schneier's CRYPTO-GRAM newsletter.) Briefly, the attack relies on the fact that retrieving an S-box entry from the cache is much faster than retrieving it from main memory; this in turn leaks bits of keying material. One of his claims is that the attack is possible because of the characteristics of efficient software implementations of AES, and that NIST should have realized the problem -- there are ciphers that don't have this problem. He also makes some suggestions to CPU designers about steps they can take to let implementors avoid such traps. For years, it was a commonplace that one should not design one's own encryption algorithms. Some people have extended that advice to apply to cryptographic protocols. Dan Boneh now says he's warning people even against doing their own implementations. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: de-identification
In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes : Ladies and Gentlemen, I'd like to come up to speed on the state of the art in de-identification (~=anonymization) of data especially monitoring data (firewall/hids logs, say). A little googling suggests that this is an academic subspeciality as well as a word with many interpretations. If someone here can point me at the mother lode of insight, I would be most grateful. What's your threat model? It's proved to be a very hard problem to solve, since there are all sorts of other channels -- application data, timing data (the remote fingerprinting paper mentioned this one), etc. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
massive data theft at MasterCard processor
MasterCard reported the exposure of up to 40,000,000 credit card numbers at CardSystems Solutions, a third-party processor of credit card data. CardSystems was infected with a script that targeted specific data. In other words, this wasn't the usual carelessness, this was enemy action, and of a sophisticated nature. See http://www.mastercardinternational.com/cgi-bin/newsroom.cgi?id=1038 for the official statement. Designing a system that deflects this sort of attack is challenging. The right answer is smart cards that can digitally sign transactions, but that would require rolling out new readers to all the merchants. That's doable, about once per decade -- and at least one credit card vendor (JP Morgan-Chase) is using the opportunity to push out RFID-based credit card readers instead. So the marketing department outranks the security department -- big surprise there --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Forwarded] RealID: How to become an unperson.
In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes: But nevertheless, I do not understand why americans are so afraid of an ID card. It has by far more advantages than disadvantages, and actually the US driving license is already a kind of ID card. Let me refer you to a National Academies report (I was on the committee): Stephen T. Kent and Lynette Millett, ed. IDs -- Not That Easy: Questions About Nationwide Identity Systems. National Academies Press, 2002. http://books.nap.edu/html/id_questions/ Briefly, the report notes that there are a very large number of questions that need to be answered about any such system before it's even possible to discuss it intelligently. And whenever I enter the US, I have to give the fingerprints of my index fingers and they take a picture of me. That's worse than an ID card. Agreed. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
new NSA chief named
http://www.baltimoresun.com/news/nationworld/bal-te.nsa07jul07,1,6042171.story?coll=bal-home-headlinesamp;cset=truectrack=1cset=true --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
the limits of crypto and authentication
There's been a lot of discussion about how to strengthen cryptography and authentication, to get away from problems of phishing, pharming, etc. But such approaches can take you only so far, as this link indicates: http://www.lurhq.com/grams.html Briefly, it's a Trojan that waits for you to log int o E-Gold, checks your balance, and drains your account except for .004 grams of gold. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Why Blockbuster looks at your ID.
In message [EMAIL PROTECTED], John Levine writes: Why does the clerk at Blockbuster want to see your driver's license? Because his management has been told, by their bank, that if they do not attempt to verify the identity of credit card users they will risk their business relationship with the bank. It's been my impression that the way you're supposed to verify the ID of a credit card user is by checking the signature. I've heard of banks telling businesses not to demand separate ID. On the other hand, I can easily believe that Blockbuster came up with the ID idea all by themselves. I very rarely rent from Blockbuster, so I may have the details wrong; I can state for sure how things work at the local video store I usually patronize. When I signed up with them, I supplied a credit card number; they retained that for contingency charges if I fail to return a video. (Odd -- my local library doesn't do that. But I digress.) In return, they handed me an account-linked credential -- exactly the sort of thing that is often advocated on this list. From my perspective, the form factor of the credential wasn't ideal; it was one of those key ring-sized cards, and I soon lost it, probably during a wallet upgrade. No problem -- they're happy to fall back to the secondary authentication system, to whit my drivers' license. I show that to get access to the account, independent of how I actually pay for the rental. In other words, they are not using my license to authenticate my credit card. (I would add that the feeds are low enought that I almost always pay in cash; I have no idea if they even have the ability to use the stored credit card for rental fees if I don't present the card separately. Hmm -- the account is old enough that the expiration date on my credit card has long since expired. They've never asked me for an update. Maybe they're using a reputation system?) --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
In message [EMAIL PROTECTED], Nick Owen writes: It would seem simple to thwart such a trojan with strong authentication simply by requiring a second one-time passcode to validate the transaction itself in addition to the session. How does the user know which transaction is really being authenticated? (I alluded to this in a 1997 panel session talk; see http://www.cs.columbia.edu/~smb/talks/ncsc-97/index.htm ) --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: mother's maiden names...
In message [EMAIL PROTECTED], R.A. Hettinga writes: At 12:26 PM -0400 7/13/05, Perry E. Metzger wrote: Why do banks not collect simple biometric information like photographs of their customers yet? Some do. Cambridge Trust puts your picture on the back of your VISA card, for instance. They have for more than a decade, maybe even two. One New York bank -- long since absorbed into some megabank -- did the same thing about 30 years ago. They gave up -- it was expensive then, and may not have solved any real problems. (Possibly, it simply didn't fit their real purpose of attracting more customers.) --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
draft paper: Deploying a New Hash Algorithm
Eric Rescorla and I have written a paper Deploying a New Hash Algorithm. A draft is available at http://www.cs.columbia.edu/~smb/papers/new-hash.ps and http://www.cs.columbia.edu/~smb/papers/new-hash.pdf . Here's the abstract: As a result of recent discoveries, the strength of hash functions such as MD5 and SHA-1 have been called into question. Regardless of whether or not it is necessary to move away from those now, it is clear that it will be necessary to do so in the not-too-distant future. This poses a number of challenges, especially for certificate-based protocols. We analyze S/MIME, TLS, and IPsec. All three require protocol or implementation changes. We explain the necessary changes, show how the conversion can be done, and list what measures should be taken immediately. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: draft paper: Deploying a New Hash Algorithm
In message [EMAIL PROTECTED], Alex Alten write s: Steve, This also seems to be in conjunction with the potential switch over from RSA et al. to ECC for PKI, etc. Yes, Eric and I have been talking about that, and we'll add some discussion of that to the next version of the paper. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: draft paper: Deploying a New Hash Algorithm
In message [EMAIL PROTECTED], Steve Furlong writes:
[Moderator's note: ... attackers are often cleverer than protocol
designers. ...
Is that true? Or is it a combination of
(a) a hundred attackers for every designer, and
(b) vastly disparate rewards: continued employment and maybe some
kudos for a designer or implementer, access to $1,000,000,000 of bank
accounts for an attacker
I'd have phrased it differently than Perry did. I'd say that the
attackers are often cleverer *about security* than protocol designers,
because insecurity is their specialty. Ordinary protocol desingers are
good at designing those protocols, but they haven't been trained to
think about security. Here's how I put it in my talk at the IETF
plenary last night:
\ns{Patterns of Thought}
\item Serial number 1 of any new device is delivered to your enemy.
\item You hand your packets to your enemy for delivery.
\item Your enemy is just as smart as you are. If we haven't seen
a given class of attack yet, it's because it hasn't been necessary;
simpler attacks have worked well enough. (Besides, how do you know
if you'll actually notice it?)
\endns
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: faster SHA-1 attacks?
In message [EMAIL PROTECTED], Perry E. Metzger writes: I was unable to watch webcast of the rump session at the Crypto conference last night, but I have heard that a proxy announced that Wang has an order 2^63 attack on SHA-1. Can anyone confirm that, and give details? Shamir gave her rump session talk (and first gave a humorous presentation on why she couldn't get a visa -- she admitted to attacking U.S. government systems, and used collisions). She is indeed claiming a 2^63 attack, and found a new path to use in the attack. Because of the new path, there is reason to think the attack will get even better. Shamir noted that 2^63 is within reach of a distributed Internet effort to actually find one. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: How many wrongs do you need to make a right?
In message [EMAIL PROTECTED], Florian Weimer writes: * Steven M. Bellovin: In message [EMAIL PROTECTED], Florian Weimer writes: Can't you strip the certificates which have expired from the CRL? (I know that with OpenPGP, you can't, but that's a different story.) OTOH, I wouldn't be concerned by the file size, although it's certainly annoying. I would be really worried that the contents of that CRL leaks sensitive information. At least from a privacy point of view, this is a big, big problem, especially if you include some indication which allows you to judge the validity of old signatures. One can easily conceive of schemes that don't have such problems, such as simply publishing the hash of revoked certificates, or using a Bloom filter based on the hashes. This doesn't completely eliminate the data leak, as a long as the certificates were used in end-to-end communications. Analysis for relative outsiders becomes harder, though. Details matter. If two parties do a DH exchange before sending their certificates, it would take an active attack. In many protocols, one party authenticates first, thereby preventing an active attack on the other. But any CRL scheme exposes knowledge of a compromise to a corrupt insider -- and they're often the primary party from whom you want to keep such information. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
In message [EMAIL PROTECTED], Adam Back writes: Thats broken, just like the WAP GAP ... for security you want end2end security, not a secure channel to an UTP (untrusted third party)! What is security? What are you trying to protect, and against whom? I use Jabber extensively, and I utterly rely on the SSL encryption to the server. I sometimes use end-to-end GPG encryption, but only when I need to discuss something very private. In general, I don't bother, because of my threat model. The biggest threat I face, in many situations, is people eavesdropping on my wireless link, or playing ARP-spoofing games on my wired link. SSL to the server combats that nicely. (I run psi, because it's the only open-source client I've found that actually checks the server's certificate against a pre-configured list. I have no idea what the default list is, since I just replace it with my own...) I'm not particularly worried about the server end. I and most of my Jabber correspondents use one of about four different Jabber servers. I run one myself; the other three are also very tightly administered. Sure, there could be a problem with any of them; given how bad typical endpoints are today, I'd guess that the servers are actually safer. I'm not even slightly worried about eavesdropping on the backbone. I assume NSA can do that if they really want to. But I *know* that it's hard enough that they're not going to waste their time without a reason, and I doubt if my IM conversations are high enough on their list. (They're pretty boring, as a rule...) I'm much more worried about implementation bugs. A previous version of psi had the bad habit of silently falling back to unencrypted mode if it couldn't find the local crypto library, and due to some glitches in my environment this could happen fairly easily. I was forced to resort to firewalling the unencrypted port on my machines... (The implementation has since been changed to make that failure much less likely.) If you don't trust your (or your correspondents') IM servers, it may be a different situation. I haven't read Google's privacy policies for IM; if it's anything like gmail, they're using automated tools that look at your messages and add to your behavioral profile. As Peter said, though, you can always run your own server or find one that you do trust. The protocol itself is quite nice, and was designed with due attention to privacy. (Aside: the Jabber RFCs were some of the best I dealt with while I was Security AD. They were remarkably easy to read, given their length and the complexity of the protocol.) Do I support e2e crypto? Of course I do! But the cost -- not the computational cost; the management cost -- is quite high; you need to get authentic public keys for all of your correspondents. That's beyond the ability of most people. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
In message [EMAIL PROTECTED], Chris Kuethe writes: On 8/26/05, Steven M. Bellovin [EMAIL PROTECTED] wrote: ... If you don't trust your (or your correspondents') IM servers, it may be a different situation. I haven't read Google's privacy policies for IM; if it's anything like gmail, they're using automated tools that look at your messages and add to your behavioral profile. As Peter said, though, you can always run your own server or find one that you do trust. Got a nice little surprise yesterday when I [ge]mailed someone, and moments later gaim beeps at me. Checking gaim, I see that suddenly these users had been added to my gaim/gtalk buddies list without my intervention. Grr Yup -- documented in the Googletalk pages. Anyway, I wouldn't be the least bit surprised if somewhere down the road a folder called archived gtalk shows up in gmail where you can search through all your old conversations. That wouldn't be a surprise at all -- a number of IM programs, including at least Gabber and Psi, keep local logs. Given Google's core competency of retaining searchable data, one would expect them to do that. But this underscores one of my points: communications security is fine, but the real problem is *information* security, which includes the endpoint. (Insert here Gene Spafford's comment about the Internet, park benches, cardboard shacks, and armored cars.) --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: e2e all the way (Re: Another entry in the internet security hall of shame....)
In message [EMAIL PROTECTED], Adam Back writes: On Fri, Aug 26, 2005 at 11:41:42AM -0400, Steven M. Bellovin wrote: In message [EMAIL PROTECTED], Adam Back writes: Thats broken, just like the WAP GAP ... for security you want end2end security, not a secure channel to an UTP (untrusted third party)! What is security? What are you trying to protect, and against whom? Well I think security in IM, as in all comms security, means security such that only my intended recipients can read the traffic. (aka e2e security). I don't think the fact that you personally don't care about the confidentiality of your IM messages should argue for not doing it. Fair enough you don't need it personally but it is still the correct security model. Some people and businesses do need e2e security. (It wasn't quite clear, you mention you advised jabber; if you advised jabber to skip e2e security because its too hard... bad call I'd say). On the contrary -- I did say that I support and use e2e security. I simply said that user-to-server security solves a lot of many -- most? -- people's security needs. Do I support e2e crypto? Of course I do! But the cost -- not the computational cost; the management cost -- is quite high; you need to get authentic public keys for all of your correspondents. That's beyond the ability of most people. I don't think it is that hard to do e2e security. Skype does it. Fully transparently. Really? You know that the public key you're talking to corresponds to a private key held by the person to whom you're talking? Or is there a MITM at Skype which uses a per-user key of its own? Another option: I would prefer ssh style cached keys and warnings if keys later change (opportunistic encryption) to a secure channel to the UTP (MITM as part of the protocol!). Ssh-style is definitely not hard. I mean nothing is easier no doubt than slapping an SSL tunnel over the server mediated IM protocol, but if the security experts are arguing for the easy way out, what hope is there. I'm more used to having to argue with application functionality focussed people that they need to do it properly -- not with crypto people. I'm not arguing for the easy way out; I'm saying that security is an engineering matter, and that there are tradeoffs, including in the human factors. People who click yes to every download aren't going to understand when to accept a key change notice. Btw, I regularly use 3 different machines when talking to my Jabber server. Is your client going to cache all 3 keys for me? Will all of my correspondents know when to click yes and when not to? My son sometimes uses AIM from public web browsers. What then? I'm sure you're itching to type that my keying material should be on a smart card of some sort, so that I could carry it with me and use the same key from any machine I choose. If so, you'd be 100% right. I'll note that for about 99.99% of people, that's just not feasible; they don't have a smart card and their OS doesn't have an interface that makes it easy to do the right thing. Heck, I don't have a smart card; I don't even know of any smart card readers that talk properly to NetBSD, my OS of choice. Here's the problem for a protocol designer. You want to design a protocol that will work as securely as possible, on a wide range of platforms, over a reasonably long period of time. What do you do? If you engineer only for e2e security, you end up in a serious human factors trap (cue Why Johnny Can't Encrypt and Simson Garfinkel's dissertation). Instead, I recommend engineering for a hybrid scenario -- add easy-to-use client-to-server security, which solves at least 75% of most people's threats (I suspect it's really more like 90-95%), while leaving room in the protocol for e2e security for people who need it and/or can use it, especially as operating environments change. This is precisely what Jabber has done. To sum it up in one sentence: design for the future *and* the present. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: MD5 Collision, Visualised
In message [EMAIL PROTECTED], Ben Laurie writes: I wrote some code to show the internal state of MD5 during a collision... http://www.shmoo.com/md5-collision.html Very nice, though you need to give a scale of rounds -- how many horizontal lines per round? --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ECC patents?
In message [EMAIL PROTECTED], Ben Laurie writes: Alexander Klimov wrote: But (potential) problem still persists: even if openssl implements ECC it does not save you from patent issues if they exist. It does if they are owned by Sun. It does if *all necessary patent rights* are owned (or licensed) by Sun. For obvious reasons, it's remarkably hard to get someone to say that they don't have a claim on some product. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Clearing sensitive in-memory data in perl
In message [EMAIL PROTECTED], Steve Furlong writes: On 9/11/05, Jason Holt [EMAIL PROTECTED] wrote: Securely deleting secrets is hard enough in C, much less high level language s. But, but..Java is the be-all end-all! Three years ago I advised a business/tech guy to avoid Java for crypto and related purposes. I'll revise that somewhat in light of greater experience and developments: Java is ok if you control the platform it's running on and if the programmers were very careful. In practice, that means I'd be willing to do the server-side programming in Java if I (or my employer or client) controlled the server. I'm not happy about doing client-side programming in Java for arbitrary users, but users in a controlled business environment is ok. From a user's perspective, I'd be _really_ cautious about using a crypto app written in Java. FWIW, lately I've been earning my daily bread with Java server-side programming. Fortunately for me, it's been mostly crap work, where it doesn't really matter if data leaks or someone cracks in. Considering that I don't control any of the J2EE or database servers and for the most part they're administered by poorly-trained monkeys, I'd have a really tough ethical call if my clients wanted me to do some work where security really mattered. There's an interesting tradeoff here: which is a bigger threat, crypto secrets lying around memory or buffer overflows? What's your threat model? For the average server, I suspect you're better off with Java, especially if you use some of its client-side security mechanisms to lock down the server. Under some circumstances, you could do a call-out to a C module just for the crypto, but it's by no means obvious that that's a major improvement. Again -- what is your threat model? --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
MIT talk: Special-Purpose Hardware for Integer Factoring
--- Forwarded Message Open to the Public DATE:TODAY * TODAY * TODAY * WEDNESDAY, Sept. 14 2005 TIME:4:00 p.m. - 5:30 p.m. PLACE: 32-G575, Stata Center, 32 Vassar Street TITLE: Special-Purpose Hardware for Integer Factoring SPEAKER: Eran Tromer, Weizmann Institute Factoring of large integers is of considerable interest in cryptography and algorithmic number theory. In the quest for factorization of larger integers, the present bottleneck lies in the sieving and matrix steps of the Number Field Sieve algorithm. In a series of works, several special-purpose hardware architectures for these steps were proposed and evaluated. The use of custom hardware, as opposed to the traditional RAM model, offers major benefits (beyond plain reduction of overheads): the possibility of vast fine-grained parallelism, and the chance to identify and exploit technological tradeoffs at the algorithmic level. Taken together, these works have reduced the cost of factoring by many orders of magnitude, making it feasible, for example, to factor 1024-bit integers within one year at the cost of about US$1M (as opposed to the trillions of US$ forecasted previously). This talk will survey these results, emphasizing the underlying general ideas. Joint works with Adi Shamir, Arjen Lenstra, Willi Geiselmann, Rainer Steinwandt, Hubert K?pfer, Jim Tomlinson, Wil Kortsmit, Bruce Dodson, James Hughes and Paul Leyland. --- End of Forwarded Message --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Amazon's
In message [EMAIL PROTECTED], Amir Herzberg writes: Amazon have this lovely service: if you tell if you forgot your pw, they send you to: https://www.amazon.com/exec/obidos/self-service-forgot-password-get-email-done /104-2901457-0883904 where they ask you to confirm your identity... using 5 last digits of a credit card you used with them. Nice oracle to find last 5 digits... making it quite easy to find the full number. It's actually an interesting tradeoff. The older scheme, as I recall, would mail you your password; knowledge of that (say, by intercepting the email) lets you at your account, which will display the last 5 digits of your credit cards. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
[Colloquium] ARMSTRONG LECTURE on Quantum Crypto and Optical Networks (Forwarded)
Date: Wed, 14 Sep 2005 18:30:22 -0400 (EDT) From: Dan Rubenstein [EMAIL PROTECTED] To: [EMAIL PROTECTED] The Department of Electrical Engineering at Columbia University invites you to attend THE ARMSTRONG MEMORIAL LECTURE Monday, September 19 - 3:00pm Davis Auditorium (Schapiro/Host) Host: Professor Osgood Unbreakable Secret Key Distribution? Quantum Cryptography and Optical Networks by Matthew S. Goodman, Ph.D., Chief Scientist and Telcordia Fellow, Telcordia Technologies Laboratory for Telecommunications Sciences Red Bank, NJ and Adelphi, MD Abstract: Manifestly quantum mechanical behavior has had tremendously important implications for the development of modern technology. In this talk we explore the impact of recent ideas and new approaches that quantum information is having on future secure communications for high performance optical networks. The talk will concentrate on quantum cryptography, which offers the promise of unconditional security for communications, and complements existing mathematically based cryptography, which is applied at higher networking levels. The talk will review the rapid progress in this field as well as some very recent experimental results from the Telcordia research group and its collaborations. We will describe the impact that this work is having on optical networking research and some early commercial activities and will speculate on its broader commercial implications. Light refreshments will be served. We look forward to seeing you there! ___ Colloquium mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/colloquium -- --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ECC patents?
In message [EMAIL PROTECTED], James A. Donald writes: -- Whyte, William: It hints that only some particular curves have been licensed. It could be that NSA has decided not to buy a license for the other curves, or it could be that operations on those curves aren't patented. The presentation doesn't give enough information to establish which. If the NSA paid anything significant for any of the curves, we would be told. Therefore the NSA paid nothing or almost nothing, and therefore if the NSA licensed anything, it would have licensed everything. I doubt that the NSA paid any money whatsoever for this license, making it profoundly unimpressive as evidence that *any* curves have a plausible valid patent. If the NSA paid real money, the patent holders would be sticking it in our face as a price setting precedent. We have been told. I downloaded Certicom's 2005 annual report (http://www.certicom.com/download/aid-503/Certicom2005AR.pdf). On p. 11, it says For the year ended April 30, 2004, revenue from IP totalled $25-million represented by a licensing contract for our Elliptic Curve Cryptography (ECC) technology by the NSA, --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Java: Helping the world build bigger idiots
In message [EMAIL PROTECTED], Peter Gutmann writes
:
Found on the Daily WTF, http://www.thedailywtf.com/forums/43223/ShowPost.aspx:
try {
int idx = 0;
while (true) {
displayProductInfo(prodnums[idx]);
idx++;
}
}
catch (IndexOutOfBoundException ex) {
// nil
}
As opposed to the C version:
int idx = 0;
while (true) {
displayProductInfo(prodnums[idx]);
idx++;
}
printf(Segmentation error; core dumped\n);
If it were input, it would print you are now 0wned...
No, Java isn't the solution to the world's programming problems. But
bounds-checking -- in any language! -- would be a very big help.
The first principle was security: The principle that every
syntactically incorrect program should be rejected by the
compiler and that every syntactically correct program should
give a result or an error message that was predictable and
comprehensible in terms of the source language program
itself. Thus no core dumps should ever be necessary. It
was logically impossible for any source language program
to cause the computer to run wild, either at compile time
or at run time. A consequence of this principle is that
every occurrence of every subscript of every subscripted
variable was on every occasion checked at run time against
both the upper and the lower declared bounds of the array.
Many years later we asked our customers whether they wished
us to provide an option to switch off these checks in the
interests of efficiency on production runs. Unanimously,
they urged us not to--they already knew how frequently
subscript errors occur on production runs where failure to
detect them could be disastrous. I note with fear and horror
that even in 1980, language designers and users have not
learned this lesson. In any respectable branch of engineering,
failure to observe such elementary precautions would have
long been against the law.
From Tony Hoare's 1980 Turing Award lecture.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Guideline for Implementing Cryptography In the Federal Government
http://csrc.nist.gov/publications/drafts/800-21-Rev1_September2005.pdf --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Java: Helping the world build bigger idiots
In message [EMAIL PROTECTED], Steve Furlong writes: On a related note, I've worked a bit with avionics and embedded medical software. The certification requirements for those bits of critical code might be helpful for crypto programming. Not quite. The name of the game is information security, and that's far more than crypto. Sometimes, in fact, the two conflict. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: PKI too confusing to prevent phishing, part 28
In message [EMAIL PROTECTED], Jerrold Leichter writes: Talking about users as being able only to hold one bit continues an unfortunate attitude that, if only users weren't so dumb/careless/whatever, we wouldn't have all these security problems. This is an important point. When *many* people are doing the wrong thing, the problem isn't the people, it's the mechanism they're being asked to use. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Venona not all decrypted?
Have a look at http://www.nsa.gov/publications/publi00039.cfm . The one-time pad was used to superencrypt a codebook; two different codebooks were used. Most of the successful decryptions were done by 1952; there was some additional help from a partial codebook recovered in 1953. Here's the key section of that monograph: The Translations and KGB Cryptographic Systems The VENONA translations from 1942 to 1943 messages occasionally are fragmentary and difficult to understand. The code itself was complex and difficult to exploit using pure analytic techniques. Moreover, the broad contextual sweep of the content of these messages vastly complicated the difficulty of reading these KGB systems. The cryptographic systems used by the KGBís First Chief Directorate involved a codebook in which words and phrases were represented by numbers. These numbers were then further enciphered by the addition of random number groups, additives taken from a so-called one-time pad. A one-time pad comprised pages of random numbers, copies of which were used by the sender and receiver of a message to add and remove an extra layer of encipherment. One-time pads used properly only once are unbreakable; however, the KGB?s cryptographic material manufacturing center in the Soviet Union apparently reused some of the pages from one-time pads. This provided Arlington Hall with an opening. Very few of the 1942 KGB messages could be solved because there was very little duplication of one-time pad pages in those messages. The situation was more favorable in 1943, even more so in 1944, and the success rate improved accordingly. In order to break into the system successfully, Arlington Hall analysts had to first identify strip off the layer of additive in order to attack the underlying code. These two levels of encryption caused immense difficulty in exploiting the codebook, and many code groups were, therefore, never recovered. The KGB messages from 1942 through 1943 and into 1944, as well as from earlier years, were based on one codebook version. The 1944 to 1945 messages were based on a new codebook. Given that intelligence scrutiny of the intercepts continued until 1980, I doubt there's any more to recover. That said, the NSA admits of the possibility: There are still gaps of two different types in the translated messages, as indicated by the words unrecovered or unrecoverable. The phrase unrecovered meant that the underlying Russian text in theory could be obtained, but the cryptanalysts did not have sufficient text to do so. Unrecoverable, on the other hand, indicates passages unaffected by the Soviet misuse of their own system which therefore could never be solved by cryptanalysts - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NSA Suite B Cryptography
In message [EMAIL PROTECTED], Sidney Markowitz writes: The possible twist that I see is if the NSA declares that any freely available open source software that interoperates with Suite B is by definition in support of US national security interests and therefore automatically gets one of their sublicenses. That would effectively remove the patent encumbrance for GPL code. There would still be patent restrictions on the code, but they would not apply to open source freely redistributable code, therefore would not get in the way of the GPL. I strongly suspect that Certicom would sue if NSA tried that. So it still comes down to what I think is the important point: BSD licensed Suite B code may be possible, GPL'd Suite B code is not possible unless Certicom makes appropriate free license to the patents available for software licensed under GPL. I think that that's a fair summary. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: semi-preditcable OTPs
In message [EMAIL PROTECTED], Trav is H. writes: I recall reading somewhere that the NSA got ahold of some KGB numeric OTPs (in the standard five-digit groups). They found that they contained corrections, typos, and showed definite non-random characteristics. Specifically, they had a definite left-hand right-hand alternation, and tended to not have enough repeated digits, as though typists had been told to type random numbers. Despite this, the NSA wasn't able to crack any messages. My question is, why? I think I know the reason, and that is that any predictability in a symbol of the OTP correlated to a predictability in only one plaintext symbol. In other words, there was no leverage whereby that plaintext could then be used to derive other symbols. Can anyone explain this better (or more accurately)? Is this lack of diffusion? Or does it have something to do with the unicity distance? Another possible answer is that it didn't matter because of how it was used. If you read the NSA monograph on Venona -- I posted a link a few weeks ago -- you'll see that the OTP in that case was used to superencipher a codebook, by adding the 5-digit OTP number to the 5-digit code value. Non-random digits in such a setting are more or less irrelevant, unless there is enough of a pattern that it helps you strip off the superencipherment. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
The Pentagon is block NSA patent applications...
http://www.newscientist.com/article.ns?id=dn8223feedId=online-news_rss091 --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Symmetric ciphers as hash functions
In message [EMAIL PROTECTED], Trav is H. writes: How does one properly use a symmetric cipher as a cryptographic hash function? I seem to be going around in circles. Isn't this is like asking a mechanic how to use a screwdriver as a hammer? Given that we seem to know much more about block cipher design than hash function design, finding a hash function that is provably as strong as a block cipher is a great idea. Reversing the situation (using the data as the key and a known plain- text) makes a plaintext attack seem like a joy etc.. This is exactly how traditional Unix crypt(3) implementations used DES, although they used a null string as the input and added some salt to prevent dictionary attacks. What exactly do you mean by plaintext attack? If we choose the plaintext, then we can compute the hash... what's the problem? All hashes I can think of work this way. Incidentally, does anyone know how crypt(3) used salt, and why it used so little instead of using a 64-bit IV in some mode with feedback? Have you read the Morris and Thompson paper? If not, see http://citeseer.ist.psu.edu/morris79password.html Briefly, though, the 12 bits of salt were used to permute the E-box in DES. They limited the salt to 12 bits because there was little need for any more. The salt served three purposes: discouraging hardware attacks based on off-the-shelf DES chips; rendering precomputed dictionaries prohibitively expensive; and forcing an attacker to attack individually each password in a file. If you have 500 passwords -- a lot for 1978 -- and 4K choices, the odds are high that you won't get much overlap in salt space. Even with 15K entries, a high figure even today, you're not going to increase the attacker's work factor by more than a few bits. As for the dictionary size -- they felt (probably correctly) that the size expansion was already large enough that that wasn't a feasible path for the attacker. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RSA-640 factored
http://mathworld.wolfram.com/news/2005-11-08/rsa-640/ --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: How broad is the SPEKE patent.
In message [EMAIL PROTECTED], James A. Donald writes: -- Does SPEKE claim to patent any uses of zero knowledge proof of possession of the password for mutual authentication, or just some particular method for establishing communications? Is there any way around the SPEKE patent for mutual authentication and establishing secure communications on a weak passphrase? It certainly doesn't claim EKE, by myself and Michael Merritt, since he and I invented the field. Of course, EKE is also patented. SRP is patented but royalty-free. Some of have claimed that it infringes the EKE patent; since I don't work for the EKE patent owner (Lucent), I've never tried to verify that. Radia Perlman and Charlie Kaufman invented PDM specifically as a patent-free method. However, the claim was made that it infringed the SPEKE patent. Since it wasn't patented, there was no one willing to spend the money on legal fees to fight that claim, per a story I heard. Have a look at http://web.archive.org/web/20041018153649/integritysciences.com/history.html for some history. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
cryptography and security-related papers from North Korea
I stumbled on the following link:http://cryptome.org/dprk/dprk-papers.htm --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ISAKMP flaws?
In message [EMAIL PROTECTED], Perry E. Metzger writes: Some articles have been appearing in various web sites about flaws in IPSec key negotiation protocols, such as this one: http://news.com.com/VPN+flaw+threatens+Internet+traffic/2100-1002_3-5951916.ht ml I haven't been following the IPSec mailing lists of late -- can anyone who knows details explain what the issue is? Broadly speaking, they're implementation bugs. The folks at University of Oulu are doing what developers around the world and across the industry should have been doing: they're writing test case generators that stress parsers. So far, they've been extremely successful against IKEv1, ASN.1, SNMP, and more. This should surprise no one and depress everyone. http://www.ee.oulu.fi/research/ouspg/protos/index.html is the home page for this project. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ISAKMP flaws?
In message [EMAIL PROTECTED], Paul Hoffman writes: At 10:14 AM -0500 11/15/05, Perry E. Metzger wrote: Some articles have been appearing in various web sites about flaws in IPSec key negotiation protocols, such as this one: http://news.com.com/VPN+flaw+threatens+Internet+traffic/2100-1002_3-5951916.h tml I haven't been following the IPSec mailing lists of late -- can anyone who knows details explain what the issue is? The advisory itself is at http://www.uniras.gov.uk/niscc/docs/br-20051114-01013.html?lang=en. Note that the abstract is Multiple Vulnerability Issues in Implementation of ISAKMP Protocol, with emphasis on Implementation of. It appears that this is *not* a problem with ISAKMP or IKE, but instead only a problem with some implementations. A summary would be when some IKEv1 implementations are sent certain malformed messages, they stop, reboot, or possibly do other bad things. Given that they started this research with sending malformed SNMP packets to SNMP-aware systems (with similar results), it is safe to extrapolate the results to implementations of nearly any protocol to varying extents. It is likely that this applies to IKEv2 as well, but using differently-malformed packets. It is also likely that it applies to some SSL/TLS implementations, of course using very different malformed packets. I mostly agree with you, with one caveat: the complexity of a spec can lead to buggier implementations. Sure, even relatively simple protocols can be implemented poorly, but complex ones have more places to go wrong. (It's instructive, I might add, to read RFC 1025, especially the part about dirty blows.) --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
the effects of a spy
Bruce Schneier's newsletter Cryptogram has the following fascinating link: http://www.fas.org/irp/eprint/heath.pdf It's the story of effects of a single spy who betrayed keys and encryptor designs. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ISAKMP flaws?
In message [EMAIL PROTECTED], Paul Hoffman writes: At 11:20 AM +0100 11/17/05, Florian Weimer wrote: These bugs have been uncovered by a PROTOS-style test suite. Such test suites can only reveal missing checks for boundary conditions, leading to out-of-bounds array accesses and things like that. In other words, trivial implementation errors which can be easily avoided using proper programming tools. Which proper programming tools would check for a logic path failure when a crafted packet includes Subpacket A that is only supposed to be there when Subpacket B is there, but the packet doesn't include Subpacket B? There are no programming tools that check for this, or for related issues: it has to be the implementer who has enough understanding of the protocol and enough time (and program space) to code against such issues. Decent test case generators. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
the early history of NSA
The Quest For Cryptologic Centralization and the Establishment of NSA: 1940-1952 http://www.fas.org/irp/nsa/quest.pdf --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
NSA declassifies some Vietnam-era SIGINT
http://www.nsa.gov/vietnam/ These are the documents related to the claim that NSA suppressed many of the intercepts relating to the so-called Gulf of Tonkin incident. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Clips] Banks Seek Better Online-Security Tools
In message [EMAIL PROTECTED], Jonathan Thor nburg writes: I would never use online banking, and I advise all my friends and colleagues (particularly those who _aren't_ computer-security-geeks) to avoid it. I do use it -- but never from a Windows machine. The OS I use is probably better, but it's *definitely* a much less attractive target for malware writers. Problems? I did have my credit card number stolen, but almost certainly not that way. The bank believes it was a random card number generator. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Clips] Banks Seek Better Online-Security Tools
In message [EMAIL PROTECTED], Janusz A. Urbanowicz writes: Bank statements come on paper or in S/MIME signed emails. This is interesting -- the bank is using S/MIME? What mail readers are common among its clientele? How is the bank's certificate checked? --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
secure links using classical (i.e., non-quantum) physics
http://arxiv.org/abs/physics/0509136 Totally Secure Classical Communication Utilizing Johnson (-like) Noise and Kirchoff's Law Authors: Laszlo B. Kish Comments: 14 pages; Google search terms: +totally +secure +communication Subj-class: General Physics Journal-ref: Manuscript featured by Science, vol. 309, p. 2148 (2005, September 30) An absolutely secure, fast, inexpensive, robust, maintenance-free and low-power- consumption communication is proposed. The states of the information bit are represented by two resistance values. The sender and the receiver have such resistors available and they randomly select and connect one of them to the channel at the beginning of each clock period. The thermal noise voltage and current can be observed but Kirchoff's law provides only a second-order equation. A secure bit is communicated when the actual resistance values at the sender's side and the receiver's side differ. Then the second order equation yields the two resistance values but the eavesdropper is unable to determine the actual locations of the resistors and to find out the state of the sender's bit. The receiver knows that the sender has the inverse of his bit, similarly to quantum entanglement. The eavesdropper can decode the message if, for each bits, she inject current in the wire and measures the voltage change and the current changes in the two directions. However, in this way she gets discovered by the very first bit she decodes. Instead of thermal noise, proper external noise generators should be used when the communication is not aimed to be stealth. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
