Lots of thoughts on bridge
Everyone who's confused about the threat model for bridge shuffle creation should check out http://www.iacr.org/newsletter/curr/bridge.html There are three major things which could be gotten out of using cryptographic technology - 1) The ability to print a short seed in a newspaper/online so that people can reproduce all the shuffles without having to communicate the position of every last card individually. 2) A process which makes it impossible for the producer of shuffles to build ones which look the way they want rather than random. 3) An interface which makes it very difficult to accidentally use shuffles intended for a different tournament. I'll start with my thoughts on (1). Someone pointed out that it isn't necessary to have a cryptographically large number of bits in the seed - it just has to destroy any obvious statistical pattens in the data, which using a cryptographically strong pseudo random number generator will do, and have enough possibilities that the humans playing in the tournament are unlikely to ever have seen a hand before. Forty bits is a reasonable number for that, even if it causes some people existential angst (sorry Lewis.) The reason to pick a number as low as 40 is that it makes the number of keystrokes necessary to enter it as small as possible. I suggested earlier that five bits can be encoded in a single character by using letters and digits without 0,O,6 and G. Using that technique, 40 bit is eight characters. I think it would be prudent to include an error correcting code with that of another four characters, designed so that if any two characters were entered wrong it could correct them and if three characters were entered wrong it could complain. That way there would be considerable margin for error when communicating and tying in codes, and the chances of any random bunch of characters being accepted would be very small, without creating a particularly bad keystroking burden. I think it makes sense to by convention express the characters in groups of four - like this: GN8G DB3R Q4RS. That way it would even be practical to read a seed off on the radio. I don't know off the top of my head how to do an ECC like that, does anybody have a good online reference? It seems like it should be a pretty standard non-cryptographic ECC. It makes sense to use a single seed not just for one hand but for an entire tournament, or at least one day of a tournament (I have no idea if tournaments are multi-day or not.) One could generate all the shuffles directly off the stream which comes form the seed, but generating hand number 20 on a PDA might start to take a while. I think a much more reasonable way of doing that is to treat the stream generated by the original seed as a series of seeds for individual hands, that way it takes about the same amount of time to generate any hand number, no matter how late it is. Some anonymous person posted code for generating shuffles based on RC4. Unfortunately, I think we really want to avoid using encryption-based technlogy anywhere in this thing, because of export laws from the US and local laws other places. It would make a lot more sense to use a PRNG based on SHA1 or RIPEMD160. Reducing the size of the seed impacts the way in which pre-publication of the seed material is done, but doesn't make it impossible. What it does limit is the number of different participants which can contribute to the seed generation process without making it practically inauditable. I think having three contibutors of seed material and a single independent collator (probably whoever's running the tournament) is emminently reasonable for the bridge tournament threat model. Given that list of participants, I think it would be best to implement the system without pre-publication and auditing first, and add that on later. Even without the auditing, a breach would require collusion on the part of one of the entropy providers and the collator, which is still a huge improvement over how things are done now. With auditing the threat model is greatly improved, but that's something which can be done later without any change to the system built beforehand, and it's important to get something working without excess difficulties. As for auditing's effect on (3) above, I think for the time being that can be done by using software with a UI which makes it very difficult to send the wrong seed to the wrong place. The easiest way to do that is to attach a description of the use of a seed to the seed and never, ever separate them. That's essentially what allowing for auditability would enforce, but it should be done from the beginning just for usability reasons. -Bram
Word needed for Entropy
I've been guilty of sloppy use of English, occasionally, and one such sloppiness that I run into occasionally is with the word "entropy" for cryptographic purposes. What we need is a word or very short phrase to capture the full phrase: "the conditional entropy of a measurement given all the information about the measurement that an attacker is expected to acquire, under the threat model for which the present use is being designed." In casual language, I might call this "undiscoverability", but it's far too large a word. - Carl -- Carl M. Ellison [EMAIL PROTECTED] http://www.pobox.com/~cme PGP: E0414C79B5AF36750217BC1A57386478 & 61E2DE7FCB9D7984E9C8048BA63221A2 ``Officer, officer, arrest that man! He's whistling a dirty song.'' [Jean Ellison]
Re: so why is IETF stilling adding DES to protocols? (Re: It's official... DES is History)
At 07:43 AM 6/26/99 -0700, David G. Koontz wrote: >DES isn't secure how? Certainly it isn't absolutely secure, and >probably never has been. Is it secure enough to keep a cracker from >grabbing passwords flying by? In most cases yes. The effort for >individuals to break DES is significant in terms of hardware, money >and time. PC week has a description of DARPA's requirements for a COTS DARPA-managed 50-user VPN with remote capabilities (and a 24/7 help desk...) "DARPA requires 128 bit keys, because security is more important than standards compliance". dh
Re: so why is IETF stilling adding DES to protocols? (Re: It's official... DES is History)
I agree strongly that having weak crypto in a system is more dangerous than on crypto. The major barrier to crypto these days is not math or computer science, it's usability. Weak crypto creates a usability nightmare. Consider it from a user's perspective, mine. I trade stocks online. My broker supports https:// connections. Recently I upgraded Netscape. For some reason, the strong crypto versions of Netscape tend not to come out for Linux. For a month I traded using a 40 bit cypher. I never noticed. I finally remembered to fix my browser (thanks, Fortify) and started trading again with my 128 bit cypher. Secure! Then one day DNS failed and the certificate for an affiliated website popped up. I was shocked to see that the certificate was being used with a 40 bit cypher. I have no idea what info has been leaked out that channel. The point is that in Netscape, it is very hard to tell if a given link is 40 bit or 128 bit. Sure, with enough poking around looking at page info you could probably figure it out. Or maybe someone knows if the little padlock means something like the little key used to. But I'm a crypto-sophisticated person, and I don't know. What about people who don't understand the technology at all? Programs like Netscape do their users a disservice by giving them weak crypto. Sure, companies are under all sorts of commercial pressures, and they make decisions based on marketing needs, not sound design. But surely the development side of the Internet, the IETF and the providers of first implementations, can do better? [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/
Re: so why is IETF stilling adding DES to protocols? (Re: It's official... DES is History)
On Fri, Jun 25, 1999 at 02:32:44PM -0700, James A. Donald wrote: | > Despite your contempt for Netscape and Microsoft, they do, | > in fact, sell strong crypto products where they are able | > to. If the CEOs of these companies went to their boards of | > directors and told them that they were going blow off the | > entire international market because they didn't want to put | > export grade crypto into their products, they'd be out of | > their jobs faster than you could say "stockholder lawsuit." | | PGP neither crippled its product, nor did it blow off the | export market. Instead it vigorously worked around the | existing laws. Microsoft has made some effort to get around | these laws, but seemed to lose interest. Perhaps Bill Gates | was the recipient of a little talk. Netscape does not seem | to have made any effort to get around these laws. That is not the case. Netscape published a good deal on what they were going through, spent substantial sums on lobbying (there was a while when Netscape's counsel, (Peter Haber)? was one of the most prominient voices on this subject), got conditinal access crypto put in, and shipped a browser or two with a "POLICY-BEGINS-HERE"" bug that could be fixed with a text editor. To say Netscape didn't achieve what we all wanted them to would be correct. To assert that they didn't try is revisionist history comprable to the work done by Winston Smith. Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume
Re: so why is IETF stilling adding DES to protocols? (Re: It's official... DES is History)
On Fri, Jun 25, 1999 at 06:48:49PM +0200, Ulf Möller wrote: | > I'll assert that deploying DES today is WORSE than deploying no crypto | > at all, because of the deployed lifetime of a new product, and the | > associate removal of pressure to deploy an effective cryptosystem. | | OpenSSL supports strong crypto. DES support is there only to allow our | users to talk to crippled American browsers and the like. Those we | don't deploy. | | Besides, as the developers of open source software we can hardly | exercise pressure on our users. I don't develop OSS, but I'll suggest that if you require the user to compile with -DAMAZINGLY_BROKEN_CIPHERS_NSA_LOVES, you cause them to at least consider this issue, rather than naively assume that all the non-snake oil, outside the US crypto in OpenSSL is secure. This is pressuring your users to do the right thing, or at least consider the issues. Do you think it would substantially hurt your uptake? Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume
Re: so why is IETF stilling adding DES to protocols? (Re: It's official... DES is History)
Lucky Green writes: > OpenSSL is a library. It should support whatever the standard supports and > whatever users and/or authors of the lib desire to be in the lib. That may > include broken or null-ciphers. But the user should have to take positive > action to get at the broken ciphers. I believe by default, OpenSSL should > ship with the weak ciphers disabled. And there should be a clear warning: > "Not secure, don't fool yourself, do not use, etc]". > > Offering ROT-13 in a library you one maintains is one thing. That's it! Include a whole range of ciphers, all the way from ROT-13 through Caesar through Enigma through an exportable 40-bit code through DES through IDEA through blowfish. Make it clear that the security one gets is the security one chooses, and include an analysis of the history and security of the various ciphers. I mean, it's foolish to impose your threat model on other people, just as it would be foolish for someone with a higher threat model impose her security requirements on you. I mean, one high threat model says "No back channels", so all data must travel through a hardware one-way interface. No. Would you like to be told that your chosen level of security is insufficient for that threat model, therefore you must take special steps to enable a cipher sufficient for your threat model? -- -russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | Government schools are so 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Re: so why is IETF stilling adding DES to protocols?
Tom Weinstein <[EMAIL PROTECTED]>: > "William H. Geiger III": >> [...] Netscrape, Micky$loth, & RSADSI may have no problem selling >> false security to their customers, [...] > Despite your contempt for Netscape and Microsoft, they do, in fact, > sell strong crypto products where they are able to. Unfortunately, though, often the cryptgraphically weak products are used even though strong ones should be available; a prominent example is the TLS server at www.microsoft.com. If they don't bother to use real cryptography themselves, why would their customers act differently?
Re: so why is IETF stilling adding DES to protocols? (Re: It's official... DES is History)
Lucky Green wrote: > > OpenSSL is a library. It should support whatever the standard supports and > whatever users and/or authors of the lib desire to be in the lib. That may > include broken or null-ciphers. But the user should have to take positive > action to get at the broken ciphers. I believe by default, OpenSSL should > ship with the weak ciphers disabled. And there should be a clear warning: > "Not secure, don't fool yourself, do not use, etc]". Its funny you should say that, because I was just working around to the same conclusion myself. I anticipate resistance from both users and some of the other developers, because it will break almost every out-of-the-box installation, and it will be argued that the "user experience" is far more important that this piffling security stuff. Sigh. Ah well, here goes. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: so why is IETF stilling adding DES to protocols? (Re: It's official... DES is History)
> Besides, as the developers of open source software we can hardly > exercise pressure on our users. In FreeS/WAN we do. The code we ship only runs secure ciphers in secure modes. You actually have to know enough to go in and change the code to run insecurely. (Or, of course, you can get your IPSEC from a different distribution, in which case you get what you get and our reputation isn't at stake.) This caused some grousing and grumbling from the lousy-crypto crowd, but virtually all the real users found that, hmm, indeed if they asked their other vendors for 3DES instead of DES, hmm, it was available. So now they're all running 3DES VPNs instead of DES VPNs. FreeS/WAN may have a lot fewer users than OpenSSL does, though; we guess the number is in the hundreds, not the thousands. We're only on the 1.0 release. John
RE: so why is IETF stilling adding DES to protocols? (Re: It's official... DES is History)
I consider there to be a number of seperable issues: 1) Should the IETF support a weakened cipher? 2) Should DES be an acceptable weakened cipher? 3) Are there other reasons to use DES? 4) Is the legacy code issue going to be crippling? The answer to (1) is much harder to answer when 56 bits are on offer than when its only 40. Even in '94 the insecurity of 40bits was quite apparent. The principle barrier to attacking SSL at the time was the secrecy of the cipher. 56 bits are a significant obstacle to all but a few very well equiped attackers, 40 bits are not much of a challenge these days. Remember that the cipher is not necessarily the weakest link in the chain. If I had to develop an attack against an application with a 56 bit cipher I would only try brute force attacks against ] the key as an extreeme last resort. Ubiquitous deployment of 56 bits would have a significant increase in effective security. While I could see the point of a principled stand rejecting 40 bits I don't think that this is the time to draw a line in the sand. The fact is that at this point 40bits are deployed and the priority should be to displace that deployed base. The second part is somewhat subtler. Not all 56 bit ciphers are the same. I would much rather use a 128 bit cipher and expose part of the key than use a cipher with only 56 bits of key. While the difficulty of attacking one key by brute force is not changed the difficulty of compiling an 'attack dictionary' is considerably increased. Consider that every HTTP communication to a home page starts with the sequence "GET / HTTP/1.1" - and there are surely other strings which provide useful known plaintext. Salting the password provides considerable additional security. There are still good reasons to use DES - in some cases it is required by regulation. Finally I don't buy the legacy code argument. In the first place as has already been pointed out the 40 bit legacy code is already there. I would much rather face the problem of a 56 bit legacy base than a 40 bit legacy base. Also it is not necessary to deploy an entire new client infrastructure just to upgrade the strength of the cryptography. Microsoft already ship their domestic cryptography as a patch. Several enterprising folk have developed scripts to patch Netscape clients. For SSL the issue is even simpler. All the clients have been shipping with 'server gated crypto' code for some time. If the server certificate has the 'enable 128 bits' flag set even an export client performs 128 bit encryption with no bits sent in the clear for the benefit of Mr Freeh. The one reason for trying to stop the use of 56 bits would be if there was a concern that the compromise might be too widely acceptable and reduce pressure on the administration sufficiently for 56 bits to become a permanent state of affairs. I don't play the kind of politics where you reject the compromise to make people dependent on you delivering the whole loaf. On the other hand I have seen others do so many times. Sooner or later the nonsense on stilts that is the US crypto policy will collapse of its own accord. I don't see the need to fear that any compromise would become permanent. Phill
Re: so why is IETF stilling adding DES to protocols? (Re: It's official... DES is History)
On Fri, Jun 25, 1999 at 01:34:22PM -0700, Tom Weinstein wrote: > I think your view only makes sense if you are only interested in > protecting yourself against entities who have $100,000 (or $50,000, > or whatever) to build a DES cracking machine. If, on the other > hand, you're also worried about 12 year old kids who pass around > lists of credit card numbers, then exportable crypto is useful to > you. While the first group may be more scary to you, most people > only care about the second group. Which is not to say that you're > wrong about your priorities, but other people, rightly or wrongly, > have different ones. I did some calculations on this. When I tracked the cracker scene back in 1992 or so, an account collector would typically have accounts on 1000 to 2000 different systems, sustained. I would be surprised if the kiddies of today have much less. This is a large enough number of systems to make attacking 40-bit encryption *very* feasible. For a relatively small site taking credit card orders, it is enough to make it feasible to attack *all* transactions. Not that I would worry overmuch about it - it is also trivial to calculate the check digits on a credit card, and most of them are given out in series. It is also trivial to get hold of the exiry date - just call up a credit card charger the 24 required times, keying in the next two years worth of expiry dates and a small charge. Eivind.
Re: write code outside US (Re: so why is IETF stilling adding DES to protocols?)
This is the last I'm going to say on this topic. It takes too much energy, and I have real work to do. Adam Back wrote: > Tom Weinstein writes: > > But that's not all, I have heard it claimed that most of the browsers > in existance, inside and outside the US are 40 bit, many of the > webservers inside and outside are, with the net result that probably > 90+% of all SSL traffic is encrypted with 40 bit ciphers. This is because it's so difficult to get a domestic version. We tried very hard to get strong crypto out as far as we could, but we drew the line at what the law allowed. As a corporation, we had to be careful about stepping over that line, because we were at the mercy of the government to get export licenses. I'm very encouraged by the progress in the Bernstein case, and whenever we talked to the lawyers, that was always an issue. > I wonder why it never occured to anyone at Netscape to write their > crypto outside the US? (I'd have thought perhaps some of those > ex-cypherpunk types who we all know are/were working there in roles > such as the 'Electronic Munitions Specialist' etc. would have been > familiar with the concept) As a matter of fact, it did occur to us. It turned out that there were a lot of problems with doing it. It's a lot easier for a company like PGP to do it because their only product is the one they are giving away. The same goes for Sameer. For a company like Netscape that sells a wide variety of products, it's a lot harder. > I mean if Sameer can do it, and Sun Micro can do it, and RSADSI can do > it why can't Netscape? Not like Netscape is short of a few bob to > open an office somewhere. Sun caught all kinds of hell from the Commerce Department, too. If you aren't familiar with this, you should talk to some of the people who were involved. Even as it was, we were under a lot of scrutiny for SSLeay and Fortify, which we had nothing to do with. > Netscape, and many other US companies *have* been losing money to > non-US companies *because* the US companies have been putting 'export > grade crypto into their products'. I certainly won't argue with this because it's true. Just because we didn't fight it the way you might have wanted us to doesn't mean we weren't aware of the problem. -- What is appropriate for the master is not appropriate| Tom Weinstein for the novice. You must understand Tao before | [EMAIL PROTECTED] transcending structure. -- The Tao of Programming |
Re: NPR story on crypto...
Vin McLelland wrote: >Nice article in USAToday, Will! > >You might find it useful to note -- and I'm open for correction on >this from anyone -- that the US Government's Bernstein brief is, I believe, >the first time the Govt has openly acknowledged that the export control >issue is all about sigint -- listening to the legal communications of >citizens and officials of other national, allied and friendly. There's more brewing on this with PECSENC, if not PEC. Recall that PECSENC has been directed by the President to come up with recommendations for a more publicly acceptable crypto policy by September under the rubric "Liberalization 2000:" Quote from a proposed Federal Register notice by PECSENC: The PECSENC has designated an encryption export control experts' group to evaluate and propose an agenda of plausible, incremental reforms as early as next year. The experts' group will consider proposals from the PECSENC, from industry, and from the public. It will recommend proposals it finds worthy of the PECSENC's consideration. The proposals will be considered independently by the PECSENC and modified, adopted, or rejected as the PECSENC chooses. This is from a report on the May 14 PECSENC meeting: http://jya.com/pecsenc051499.htm There may be more news of this from the PECSENC meeting today on when the public is to be engaged in this "liberalization" policy. What's intriguing is whether PECSENC, now headed by an ex-NSA honcho, is going to bite NSA's sigint bullet, and recommend that strong encryption is better for the public interest than natsec snooping, what with the world now getting its hands on means of strong protection for conventional telecommunications of text and to a lesser extent voice. This would correspond with the CRISIS report of 1996, which recommended liberalization on strong crypto and the development of other (unnamed) technologies for snooping and law enforcement. The rapid advance of technologies for identification, interception and surveillance other than those for text and voice transmissions could replace the need for weak crypto. There are some pretty amazing things being done with Hidden Markov Modeling to track patterns for identification, based on a survey of some 300 patents utilizing the invention in a wide host of applications.
