Re: anonymous DH MITM
Steven M. Bellovin wrote: In message [EMAIL PROTECTED], Ian Grigg writes: M Taylor wrote: MITM is a real and valid threat, and should be considered. By this motive, ADH is not a recommended mode in TLS, and is also deprecated. Ergo, your threat model must include MITM, and you will pay the cost. (Presumably this logic is behind the decision by the TLS RFC writers to deprecate ADH. Hence, talking about ADH in TLS is a waste of time, which is why I have stopped suggesting that ADH be used to secure browsing, and am concentrating on self-signed certs. Anybody care to comment from the TLS team as to what the posture is?) What's your threat model? Self-signed certs are no better than ADH against MITM attacks. I agree. As a side note, I think it is probably a good idea for TLS to deprecate ADH, simply because self-signed certs are more or less equivalent, and by unifying the protocol around certificates, it reduces some amount of complexity without major loss of functionality. (AFAIK, self-signed certs in every way dominate ADH in functional terms.) Until you understand your threat model, you don't have any grounds to make that decision. I think we are in agreement on that!? MITM is certainly possible -- I've seen it happen. The dsniff package includes a MITM tool, as do many other packages; at the Usenix Security conference a few years ago, someone intercepted all web-bound traffic and displayed a page All your packets are belong to us. An appropriate security model for a security conference might be to put a sign up at the door saying All your assumptions are belong to us At least that way everyone would be in tune with the nature of the conference. Anything that happens at the Usenix Security Conference is, in my book, ruled out of ones regular, commercially relevant threat model. Same goes for demos in a Uni student lab. We all know it's possible. The question is, should we worry about it? And, following on from Perry's method, should we impose our own fears on others? A threat must occur sufficiently in real use, and incur sufficient costs in excess of protecting against it, in order to be included in the threat model on its merits. Anyone on the same LAN (switched or unswitched) could have done the same. If you're not on the same LAN, a routing attack or a DNS attack could result in the same thing, and those are happening, too, in the wild. I know a couple of instances were posted maybe 6 months back. What we need really is some sort of repository of MITM attacks in the wild. Costs would be very useful too. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
On Wed, 1 Oct 2003, Ian Grigg wrote: M Taylor wrote: Stupid question I'm sure, but does TLS's anonymous DH protect against man-in-the-middle attacks? If so, how? I cannot figure out how it would, Ah, there's the rub. ADH does not protect against MITM, as far as I am aware. DH is an open protocol; it doesn't rely on an initial shared secret or a Trusted Authority. There is a simple proof that an open protocol between anonymous parties is _always_ vulnerable to MITM. Put simply, in an anonymous protocol, Alice has no way of knowing whether she is communicating with Bob or Mallory, and Bob has no way of knowing whether an incoming communication is from Mallory or from Alice. (that's what anonymous means). If there is no shared secret and no Trent, then nothing prevents Mallory from being the MITM. You can have anonymous protocols that aren't open be immune to MITM And you can have open protocols that aren't anonymous be immune to MITM. But you can't have both. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Reliance on Microsoft called risk to U.S. security
On Wed, Oct 01, 2003 at 07:02:00PM -0700, bear wrote: Heh. You looked at my mail headers, didn't you? Yes, I use pine - primarily *because* of that property. It treats all incoming messages as text rather than live code. A protocol for text (as opposed to live code) requires compliant clients (ie, clients that don't do anything other than display the recieved messages). As such, it's at least somewhat a social issue. While I agree that text is far safer than html or a .exe, do you run Pine on a dumb terminal, or in a window? If the latter, escape sequences which most folks would class as text can lead to remote compromise. There have been occasional bugs in terminal emulators, in X and others. TERM=vt100 is in some sense defining an interpreted programming language, albeit a limited one. That absolute safety is impossible does not excuse software from our favorite vendor whose security model is all but impossible to fathom, so I'm not at all disagreeing with your point. I use Mutt. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Reliance on Microsoft called risk to U.S. security
From: bear [EMAIL PROTECTED] Heh. You looked at my mail headers, didn't you? Yes, I use pine - primarily *because* of that property. It treats all incoming messages as text rather than live code. BUGTRAQ in the last 3 years lists over 80 mails on pine - including reference to this recently: http://www.idefense.com/advisory/09.10.03.txt which also appears in candidates on cve.mitre.org. (Mitre seem to take unreasonable time in converting candidates to definite problems unless I'm misunderstanding their website.) [HTML mail] can cause your machine, specifically, to make network connections to get graphics, style sheets, etc, and will not display That could include web bugs for spammers. I agree it's ridiculous to read mail in a browser but a conventional MUA has risks too. I write all mail to disk and view it with my favourite text editor. This is convenient with practice. Now I only want MUAs for sending mail (it's worth it to get the correct references in my reply headers). I use this script on one of my accounts where I accept HTML mail (reluctantly from a hotmail user). http://www.notatla.org.uk/SOFTWARE/text_lover_mail_filter.plx The HTML conversion is done by lynx (confined by SubDomain). This practice can result in running mimencode -u and metamail -w on a few things. It's not that common for a non-text message to get past my procmail rules and have me choose to read it. This is all pretty simple but certainly not mass-market. I must order a told you so rubber stamp for when my monocultural acquaintances get hacked. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Don't kill the messenger (was: Re: Reliance on Microsoft called risk to U.S. security)
On Wednesday 01 October 2003 22:02, bear wrote: No, it is not. You can make a hyperdocument that is completely self-contained and therefore text, but that is not how HTML is normally made. HTML can cause your machine to do things other than display it, and to that extent it is code, not text. A small nit: HTML is, in fact, text. The effects you describe are the result of a client taking certain actions based on the text/html MIME type. That's the reason you use Pine (and I use Kmail). These clients (and others... yay, elm!) don't take unbidden actions to render HTML mail or cause executable attachments to execute. You can't rely on saving an HTML document and being able to read it years or decades later, because with hypertext, maybe the part you're interested in (or need for evidence) isn't even on the page you saved. True, but again, that's a property of HTML. That the HTML document was transmitted through mail is a side issue. It's not that email has been overloaded, through the use of MIME, to carry content other than text/plain. The problem is that certain MUAs have been built to take some default actions based on the MIME types received, and those clients have become (for whatever reason) popular among mail users of a, shall we say, non-technical bent. The fact that sending HTML (and other code) through SMTP was not considered a violation of SMTP has allowed a generation of mail readers to become common that encourage mail viruses, macroviruses, worms, and other malicious code. If we are interested in security, we need some kind of protocol where we as a group just draw a line and say nothing but text through this port. SMTP is *already* such a protocol. Base-64 encoding (and UUENCODE before it) was designed to address the 7-bit gateway through which email once passed. MIME only describes and encapsulates non-textual content. (the first M originally stood for 'multimedia', not 'multipurpose') Some mail clients have evolved (or been designed *cough*outlook*cough*) to be infection vectors, but that's not the fault of the base transport protocol. It's the result of poor security decisions in the client design process. This is not to demonize MIME, either. Some applications, like PGP signatures, are elegant uses. Much better than the X-PGP-Signature header I was helping develop 10 years ago. There's nothing intrinsically wrong with extending mail to carry arbitrary content. The problem appears when the MUA is able to take some risky action with that content, whether automatically or through unwise user action. Grandma clicks on everything. Mail as a vulnerability is a client issue and a training issue. That said, I also despise HTML mail for all the reasons you describe. But between the September That Never Ended and the release of Mosaic, it's really no surprise that eye candy has become an imperative. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Monoculture
slightly ranting, you might want to hit del now :) Ian Grigg wrote: What is written in these posts (not just the present one) does derive from that viewpoint and although one can quibble about the details, it does look very much from the outside that there is an informal Cryptographers Guild in place [1]. I don't think the jury has reached an opinion on why the cryptography group looks like a guild as yet, and it may never do so. A guild, of course, is either a group of well-meaning skilled people serving the community, or a cartel for raising prices, depending on who is doing the answering. To me it seems more like a academic community - particularly the way many can't handle the concept of good enough but look for theoretically perfect solutions that may be unworkable in the Real World. And yes, I *am* an outsider - I dabble a little, and I am a programmer, but I am the first to admit my math skills are nowhere near adequate to make any meaningful contribution to the field. It seems to me there is no more a cryptography guild than a linux guild - yes, you get advocates who foam at the mouth if you say the wrong thing, but the majority seem more interested in getting it to work. From my POV as a programmer, learning the field consists of identifying the available building blocks (hash, symmetric, asymmetric), standards (openpgp, x509, ssl, ssh, ipsec) and prior implimentations (paying particular attention to what had to be patched due to discovered vunerablities, so as to avoid the same errors in my own code) It also seems the crypto community is very open to questions, very hostile to statements - so often knowing how to phrase something to them is as important as the content of the question. Stating I am doing $FOO will not be as productive as If I were to do $FOO what vunerabilities would that introduce? - remembering that any good advice you get back for free would have probably cost you weeks of study or possibly thousands of dollars trying to obtain a security certification for your solution later on. Just ignore any posts of because it isn't done that way unless they give a good reason why your way isn't better (note as good isn't good enough - you always need a good reason to stray from a tested and known path, and it is often worth putting up with a few minor inconveniences to stay on it) Oh - and make sure you can recognise a good reason when you see it ::) The guild would like the application builder to learn the field. They would like him to read up on all the literature, the analysies. To emulate the successes and avoid the pitfalls of those protocols that went before them. The guild would like the builder to present his protocol and hope it be taken seriously. The guild would like the builder of applications to reach acceptable standards. I would certainly expect a house builder to know how to lay bricks - but if he insisted on designing the house too, I would expect him to know how to do that (and not just start putting up walls and hoping it will all work out later. Design requires a fair understanding of what you are designing and what the capabilities and limitations of the materials are - this is why SAs get paid more than their programming teams (not that I like that given I am a programmer not a SA). If you aren't willing to learn how to do that, you can still follow someone else's design - or take a modular approach and just drop pre-built units (normally libraries) into those parts of the code that need them. Libraries can be surprisingly good - if the designer put in enough effort, they can have sufficient inline M/C for the timing-critical parts that they are noticably more efficient than implimenting your own code in a medium or high level language. And, the guild would like the builder to take the guild seriously, in recognition of the large amounts of time guildmembers invest in their knowledge. That does tend to happen - in any community, you get those who get used to being authorities, and react badly to being challenged. At least in this community most of them have the sense to back down when proved wrong :) None of that is likely to happen. The barrier to entry into serious cryptographic protocol design is too high for the average builder of new applications [2]. He has, after all, an application to build. Indeed so - that is why using a prebuilt standard (or better yet, a library) as your base is such a good idea. However, a lot of programmers don't like doing that because they feel it is either cheating or means all their hard work is going to be dismissed as just an implimentation of someone else's idea rather than something original and novel. However, the odds of someone rolling their own protocol getting something more efficient or effective as work that has already been done are low - and if the package you put together is sufficently good, no users will care it uses SSH (protocol) for comms or someone else's AES library for
RE: Monoculture
perry wrote:
We could use more implementations of ssl and
of ssh, no question.
...more cleanly implemented and simpler to use
versions of existing algorithms and protocols...
would be of tremendous utility.
jill ramonsky replied:
I am very much hoping that you can answer both (a)
and (b) with a yes, in which case I will /definitely/
get on with recoding SSL:
Is it possible for Bob to instruct his browser to
(a) refuse to trust anything signed by Eve, and
(b) to trust Alice's certificate (which she handed
to him personally)? (And if so, how?)
how it's done depends on the browser:
in Moz 1.0: Edit Preferences... Privacy Security
Certificates Manage Certificates
{Authorities, Web Sites}
in MSIE 5: Edit Preferences.., Web Browser
Security Certificate Authorities
(there seems to be no way to tell MSIE 5 to
trust Alice's server cert for SSL connections,
except to tell MSIE 5 to trust Alice's CA.)
in NS 4.75: Communicator Tools Security Info
Certificates {Signers, Web Sites}
- don davis, boston
-
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: VeriSign tapped to secure Internet voting
Schu stressed that several layers of security will prevent hackers from accessing the system. VeriSign will house the security servers in its own hosting centers. The company will ask military personnel to use their Common Access Cards--the latest form of ID for the military--to access the system and cast a vote. Civilians will use digital signatures. So how will these civilians get a certified public key, and how will the private key be protected? Is there a special policy for the issuance of these kind of certificates? --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Monoculture
Thanks everyone for the SSL encouragement. I'm going to have a quick re-read of Eric's book over the weekend and then start thinking about what sort of easy to use implementation I could do. I was thinking of doing a C++ implentation with classes and templates and stuff. (By contrast OpenSSL is a C implementation). Anyone got any thoughts on that? Also - anyone thinking of using something like this - could you post (in another thread maybe) suggestions as to what kind of simple interface you actually want? As in, what you want it to do? All suggestions gratefully considered, but in the light of comments in this list, I will /not/ turn it into bloatware just to satisfy all demands. (OpenSSL can do that). Finally - I'll need some help setting up a sourceforge thing as I've never set up an open source project before and don't really know how to go about that. Some advice on licensing wouldn't go amiss either. (GPL? ... LGPL? ... something else?) Re Don's comments below: This seems to me to a /serious/ flaw in the design of MSIE. What if Alice doesn't /have/ a CA because she can't afford their fees? (or she doesn't trust them, or for any other reason you might care to think of). In fact, if I've understood this correctly, if Alice uses MSIE, she can't even tell her browser to trust her own website, despite being in possession of not only her own public key, but her own secret key as well! What is it with MSIE that it would prefer to trust someone other than Alice about the authenticity of Alice's site !!!??? Okay guys - _this is a serious question_. Alice has a web site. Alice has a web browser which unfortunately happens to be MSIE. Alice wishes to view Alice's web site using Alice's browser (which is not on the same machine as the server). Alice does not wish to trust ANYONE else, but she does trust herself absolutely. How does she get the browser to display the padlock? I wouldn't be at all surprised if the answer turns out to be It can't be done. (That may not be a problem if other browsers don't have this design flaw, of course, since Alice can tell all of her friends don't use Microsoft). Jill -Original Message- From: Don Davis [mailto:[EMAIL PROTECTED] Sent: Thursday, October 02, 2003 1:26 PM To: Jill Ramonsky Cc: [EMAIL PROTECTED] Subject: RE: Monoculture Is it possible for Bob to instruct his browser to (b) to trust Alice's certificate (which she handed to him personally)? (And if so, how?) how it's done depends on the browser: in MSIE 5: Edit Preferences.., Web Browser Security Certificate Authorities (there seems to be no way to tell MSIE 5 to trust Alice's server cert for SSL connections, except to tell MSIE 5 to trust Alice's CA.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Speciality film heads meet to respond to MPAA
Paul Kocher quote at the bottom... Cheers, RAH --- http://www.hollywoodreporter.com/thr/article_display.jsp?vnu_content_id=1991585 The Hollywood Reporter Oct. 02, 2003 Speciality film heads meet to respond to MPAA By Gregg Kilday The MPAA may have hoped to create a nonproliferation treaty with its ban on awards-season screeners, announced Tuesday, but instead it set off a veritable bomb that sent shock waves throughout the film community. The heads of most of the studio-based specialty film companies met Wednesday in an unprecedented summit at the Four Seasons Hotel in New York to formulate a response. Bingham Ray, president of United Artists, MGM's specialty film division, took the lead in organizing the gathering, which brought together top executives from all the studio-affiliated labels except Fox Searchlight and the newly formed Warner Independent Pictures. (Fox Searchlight execs were later updated on the proceedings.) Those present or participating by phone are said to have included Miramax Films' Harvey Weinstein, Focus Features' David Linde and James Schamus, Sony Pictures Classics' Tom Bernard, and Fine Line's Marian Koltai-Levine. The group, with Ray acting as its spokesman, is expected to issue a statement today or Friday. Ray was unavailable for comment Wednesday. It was the beginning of a dialogue, said one indie exec, who received reports of the meeting. All of the indie companies have been getting a lot of questions and concerns from film critics, foreign distributors, foreign partners, exhibitors, artists -- writers, directors, actors -- and talent agencies, and there has been a lot of discussion. Another source close to the situation said: I think it was a historic meeting with some pretty incredible minds. It was really more of a study group. They were asking a lot of questions. One approach that the group could take was suggested by a separate statement released Wednesday by Michelle Byrd, executive director of the IFP/New York. Signed by 33 filmmakers, producers and executives, the statement condemned the MPAA ban. This last-minute policy change will seriously diminish the diversity and quality of independent films immediately and the mainstream film industry in the long run, the statement read. Oscar consideration is a primary motivating factor behind the funding of riskier films, those of more serious content, films with ambitious narrative aspirations. Lacking Oscar potential, these films will not be made. It noted that the least likely people to pirate -- Academy members and other insiders -- will suffer the most, particularly since most piracy comes from outside the U.S. and is the result of in-theater taping. The group proposed in the statement that all screeners (both DVD and VHS) ... be watermarked and individually numbered so they can be traced and the perpetrators prosecuted. Among those lending their names to the statement, which was still growing at press time, were directors Robert Altman, Bill Condon, Peter Hedges and John Waters; actors Selma Blair, Hilary Swank, Chloe Sevigny and Tracey Ullman; producers Anthony Bregman, Lee Daniels, Ted Hope, Ross Katz, John Penotti and Christine Vauchon; and execs Johnathan Sehring and Ed Pressman. Byrd explained that Hope, producer of American Splendor, brought his concerns first to her and others, such as Greenestreet Films' John Penotti, and Focus' Linde quickly weighed in. The chief challenge facing independents is always one of access, she said. Access to screens, distributors and, in this case, Academy voters. We want to ensure that these films are given a fighting chance in terms of recognition. Meanwhile, in other fallout from the MPAA decision: The MPAA issued a clarification to its member companies on one point. Although a number of Oscar consultants believed the ban, as originally stated, would have allowed them to distribute DVDs of films that would be available in the home video market -- for example, Disney/Pixar's Finding Nemo or the Universal release Seabiscuit -- the MPAA shut down that loophole. It has been reported that some subsidiaries believe it is OK to send out screeners if the film has been released in home video form, the clarification said. This is incorrect. The policy is no screeners of any kind are allowed to be sent. It was found that DVD mastering facilities such as Cinram, Deluxe, Sonopress, Technicolor and Warner Bros.' WAMO have been working for months with the studios to develop and implement forensically trackable DVD technologies specifically for the upcoming awards season. We've been working with the studios for the past year in developing antipiracy technologies, said a disc replication manager, who wished to remain anonymous. About six to eight months ago, two studios actually came to us and said, 'Hey, we foresee this being a problem, can you help us develop a solution?' The studios are very aware
Re: Reliance on Microsoft called risk to U.S. security
| Can be relied on to _only_ deliver text is a valuable and important | piece of functionality, and a capability that has been cut out of too | many protocols with no replacement in sight. While I agree with the sentiment, the text/code distinction doesn't capture what's important. Is HTML text or code? Well ... it's actually neither. There is a set of tags in HTML that is perfectly safe. Setting fonts and font colors, describing a table ... all kinds of stuff like that isn't text, but it can't hurt you either. (Whether these are *useful* in mail is a whole other question) On the other hand, embedded references that reach out over the network are inherently dangerous, since the very act of autonomously opening a connection to a system of someone else's choosing is something I, personally, don't want my mail reader doing, ever. Text is code, too! A plain ASCII message received by Pine is run through the Pine Interpretation Engine - the Pine MUA under another name. Some character sequences cause entries to be made into a list of subject lines. Others may trigger automatic refiling. Most cause bits to be written to a terminal window. Those bits in turn are really code, interpreted by my xterm (or whatever), causing it do to all kinds of complicated things that ultimately light some pixels on my screen. The real distinction is: Which of *my* resources are *you* able to manipulate by sending me mail? I'm willing to give you complete access to send characters to the terminal in which pine runs ... well, almost. There's a long history of security holes *in terminals* - e.g., escape sequences that load the WRU buffer, and then a control character that causes the WRU to send back qyy|rm *\n! You have to carry this analysis *all the way through all the levels of interpretation*. Way back, when I worked on designing terminals at DEC, we were aware of the security issues and it was a design rule that there was no way to send characters to the terminal and have exactly those read back automatically. (Usually, you couldn't read it back at all. Otherwise, they were wrapped up in a format that would be innocuous to all but very strange programs - e.g., as a hex string.) It was fun evaluating competitor's terminals against that design rule - almost all of them failed. (It was not so much fun telling marketing that no, we would not implement that particular feature even though the competition had it.) Anyhow ... if you consider the entire *system*, then the rule is that I will give you complete access to write a certain safe subset of ASCII characters, or a safe subset of ASCII characters plus escape sequences. That's why mail clients have long filtered out certain characters. (An MUA that talks direct X calls has no reason to filter anything, since writing a text string directly with X goes into an interpreter that can change *only* the bits on the screen.) A resource-based model gives you some basis for deciding which parts of HTML are acceptable, and which are not. Given such a model, it's perfectly possible to write a safe HTML interpreter. Of course, you lose some features - that's life. Life would also be much easier if you never had to lock your door because no one would ever think of stealing. BTW, a resource model has to change with time. The traditional view has been that I grant anyone full write access to the end of mail file - i.e., anyone can send me as much mail as they like. These days, I really *don't* want to grant that access to spammers - and spam blocking techniques are all about how to control the SMTP interpreter I present to the outside world to protect my disk resources. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Return of the death of cypherpunks.
--- begin forwarded text Status: U From: James A. Donald [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Wed, 1 Oct 2003 23:37:08 -0700 Subject: Return of the death of cypherpunks. Sender: [EMAIL PROTECTED] -- When a mailing list is full of crap, it dies, even though the regulars set killfiles to silence the offending posters. The reason is, no new people arrive. New people subscribe, see nothing but crap, unsubscribe. A mailing list or newsgroup needs a strong personality who is a prolific poster who keeps discussions on track, issues lots of good stuff, and reprimands trolls and nuts. That person, of course was Tim May. (past tense) It also needs a continual stream of new people, who bring new ideas, and unfamiliar ways of recognizing old ideas. The relentless mass spamming by professor rat and Jim Choate keeps new comers away, since 99% of the posts to the list is from people who hate the ideas that the list was created to further, and seek to shut it down, to prevent thought about and discussion of such ideas, and Tim May has succumbed to terminal grumps on discovering that the crypto transcendence is not coming soon. So when is the crypto trancendence coming? When does an encryption enabled internet start to undermine the power of the state? Well it is a little like web groceries. During the Dot.com hype, lots of web grocery companies popped up, and made about a cent on the dollar. They vanished, but, surprise surprise, there are now some real web grocery firms, and they are making a little bit of money. Darknet (frost over freenet) is going tolerably well, mostly in its Japanese incarnation, the repression being stronger in Japan. The Japanese experience tells us that any repression short of communist levels of repression will make darknet stronger, not weaker. The big threat to frost over freenet is the natifying of the net which makes more and more people into clients, not peers. Theoretically frost over freenet serves even those behind NATs, but really it does not, and cannot. Private money on the internet remains a small, non anonymous, backwater. There is no Chaumian anonymity. There is some trust us anonymity, located on offshore islands, controlled by people quite susceptible to US pressure. Account based money without true names or the mark of the beast is a tiny but profitable business. E-gold is probably the largest player, with about two million dollars a day changing hands, and twenty thousand micropayments a day (payments of less than a dollar) Two million a day is one five hundred thousandth of the turnover on the US$, and it is not growing very fast. Of course e-gold is just one of several, but it probably a large portion of the total. Suppose no-true-name account based money grows at thirty percent a year, which seems plausible. In due course some substantial portion of it will be chaumian. Then the US$ goes into crisis in 2060. As Adam Smith put it, There is a lot of ruin in a nation.. Even if we suppose that the institutions of the crypto trancendence undergo remarkably rapid growth, the kind of growth that the dot bombs predicted in their business plans, the crypto trancendence does not hit until around 2025. But right now today, the internet is undermining the power of the state. The Japanese government went as far as democracy can go, and perhaps a bit further, to shut down file sharing. The result: Widespread adoption of software based on freenet. Cypherpunks 1, state 0. We have a long way to go, but we are going. Oh yeah, and once again I declare the mailing list that gave the name of this movement to be dead, though the fact that I am still posting on it would seem to prove it is alive, though breathing its last. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG dcuOonOpNgPgqZpgbJF0j6ClGa0j1it1Uk51kc/Q 4Nnby2D6L0GGqj2rwXsyWpY1xoKh901QBG9bsYjxG --- end forwarded text -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
Bear wrote: DH is an open protocol; it doesn't rely on an initial shared secret or a Trusted Authority. There is a simple proof that an open protocol between anonymous parties is _always_ vulnerable to MITM. Put simply, in an anonymous protocol, Alice has no way of knowing whether she is communicating with Bob or Mallory, and Bob has no way of knowing whether an incoming communication is from Mallory or from Alice. (that's what anonymous means). If there is no shared secret and no Trent, then nothing prevents Mallory from being the MITM. You can have anonymous protocols that aren't open be immune to MITM And you can have open protocols that aren't anonymous be immune to MITM. But you can't have both. I'd like to see the proof. I think it depends on what you mean by MITM. Take the Chess Grandmaster Problem: can Alice and Bob play a game of chess against one another while preventing Mitch (the Man In The CHannel) from proxying their moves to one another while taking the credit for being a good chess player? To make it concrete, suppose we limit it to the first two moves of a chess game. One player is going to make the first move for White, and the other player is going to make the first move for Black. Now, obviously Mitch could always act as a passive proxy, forwarding exactly the bits he receives, but in that case he can be defeated by e.g. DH. To make it concrete, suppose that the first player includes both his move and his public key (or his public DH parameters) in his message, and the second player encrypts his message with the public key that arrived in the first message. Mitch wins if the first player accepts the second player's move (the first move for Black). The players win if the first player accepts a different move that the second player didn't make. (This is the case where Mitch is no longer doing the Chess Grandmaster Attack, but is instead just playing two games of chess, one game with the first player and another game with the second player.) If the players reject a message and end the protocol, then neither Mitch nor the players win -- it is a tie. (A denial-of-service situation.) Now, you might intuitively believe that this is one of those situations where Mitch can't lose. But there are several protocols published in the literature that can help the players against Mitch, starting with Rivest Shamir's Interlock Protocol from 1984. The funny thing is that all of these published protocols seem to require a constraint on the game of chess. For example, the Interlock Protocol works only with full duplex games where both sides are making a move at the same time. You can't obviously apply it to chess, although you *could* apply it to a full-duplex game like chess variant Bughouse, or, um, children's card game War. Or a Real-Time Strategy computer game where both players are sending moves to one another simultaneously. Now, you might go back to the beginning of this message and say Well, Chess Grandmaster isn't MITM!. In that case, I would like to see a definition of what exactly is this MITM which can't be countered in the no- shared-trust setting. I'm not saying that there isn't such a thing -- indeed I can think of a definition of MITM which satisfies that requirement, but I'm not sure it is the same definition that other people are thinking of. Anyway, it is a funny and underappreciated niche in cryptography, IMO. AFAIK nobody has yet spelled out in the open literature what the actual theoretical limitations are. Regards, Zooko http://zooko.com/log.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Monoculture
On Thu, Oct 02, 2003 at 02:21:29PM +0100, Jill Ramonsky wrote: Thanks everyone for the SSL encouragement. I'm going to have a quick re-read of Eric's book over the weekend and then start thinking about what sort of easy to use implementation I could do. I was thinking of doing a C++ implentation with classes and templates and stuff. (By contrast OpenSSL is a C implementation). Anyone got any thoughts on A C++ implementation will be much less useful to many potential users; perhaps the most underserved set of potential SSL/TLS users is in the embedded space, and they often can't afford to, or won't, carry a C++ runtime around with them. We learned this lesson with FreSSH and threads. I would strongly recommend a C implementation with an optional C++ interface, if C++ is the way you want to go. Also, I'd consider, for simplicity's sake, at least at first, implementing *only* TLS, and *only* the required ciphers/MACs (actually, using others' implementations of the ciphers/MACs, even the OpenSSL or cryptlib ones, is probably not just acceptable but actually a _really good idea_.) The major problems with OpenSSL are, from my point of view, caused by severe overengineering in the areas of: 1) Configuration 2) ASN.1/X.509 handling 3) Tightly-coupled support for the many diverse variants of SSL/TLS. As far as what OpenSSL does, if you simply abandon outright any hope of acting as a certificate authority, etc. you can punt a huge amount of complexity; if you punt SSL, you'll lose quite a bit more. As far as the programming interface goes, I'd read Eric's book and then think hard about what people actually use SSL/TLS for in the real world. It's horrifying to note that OpenSSL doesn't even have a published interface for a some of these operations. For example, there is no simple way to do the most common certificate validation operation: take a certificate and an optional chain, and check that the certificate is signed by an accepted root CA, or that each certificate in the chain has the signing property and that the chain reaches that CA -- which would be okay if OpenSSL did the validation for you automatically, but it doesn't, really. From my point of view, a _very_ simple interface that: 1) Creates a socket-like connection object 2) Allows configuration of the expected identity of the party at the other end, and, optionally, parameters like acceptable cipher suite 3) Connects, returning error if the identity doesn't match. It's probably a good idea to require the application to explicitly do another function call validating the connection if it decides to continue despite an identity mismatch; this will avoid a common, and dangerous, programmer errog. 4) Provides select/read operations thereafter. Would serve the purposes of 90+% of client applications. On the server side, you want a bit more, and you may want a slightly finer-grained extended interface for the client, but still, you can catch a _huge_ fraction of what people do now with only the interface listed above. Thor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Monoculture
Perry E. Metzger [EMAIL PROTECTED] writes: Guus Sliepen [EMAIL PROTECTED] writes: In that case, I don't see why you don't bend your efforts towards producing an open-source implementation of TLS that doesn't suck. We don't want to program another TLS library, we want to create a VPN daemon. Well, then you might consider using an existing TLS library. It is rather hard to make a protocol that does TLS things that is both safe and in any significant way simpler than TLS. Several people have now suggested using TLS, but nobody seem to also refute the arguments made earlier against building VPNs over TCP, in http://sites.inka.de/~bigred/devel/tcp-tcp.html. I have to agree with many things in the paper; using TCP (as TLS does) to tunnel TCP/UDP is a bad idea. Off-the-shelf TLS may be a good security protocol, but it is not a good VPN protocol. Recommending TLS without understanding, or caring about, the application domain seem almost arrogant to me. Admittedly, you could invent a datagram-based TLS, but this is not widely implemented nor specified (although I vaguely recall WTLS) so then you are back at square one as far as security analysis goes. Thanks, Simon - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Monoculture
Simon Josefsson [EMAIL PROTECTED] writes: Several people have now suggested using TLS, but nobody seem to also refute the arguments made earlier against building VPNs over TCP, in http://sites.inka.de/~bigred/devel/tcp-tcp.html. Well, I agree, the most reasonable thing to do is to use ipsec, but if people aren't going to use ipsec they should at least use a protocol that isn't insecure. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Reliance on Microsoft called risk to U.S. security
Peter has raised a number of important points. Let me start by saying that I do not see a strong distinction between a file to be viewed and a program. Both are instructions to the computer to perform some actions. While we might think the renderer showing us flat ASCII text is quite trustworthy, our degree of trust in an HTML should be less, and we shouldn't trust a Word format renderer at all (thanks to Word Macro viruses). At 9:21 PM -0700 9/30/03, Peter Gutmann wrote: Bill Frantz [EMAIL PROTECTED] writes: The real problem is that the viewer software, whether it is an editor, PDF viewer, or a computer language interpreter, runs with ALL the user's privileges. If we ran these programs with a minimum of privilege, most of the problems would just go away. This doens't really work. Consider the simple case where you run Outlook with 'nobody' privs rather than the current user privs. You need to be able to send and receive mail, so a worm that mails itself to others won't be slowed down much. I do not envision running either programs or viewers under the privileges of the mail agent. Since I am not really a Unix person, let me take a stab at a design and let the people who know what they are doing take stabs at it. What we need is an environment of very limited privilege to use to confine our untrusted code. Specifically: * No ability to make connections to other services, either over the network or locally. (I think this item requires a kernel change.) * Very limited access to the file system. We might take the view that since we control all the ways the confined process can send data out of the system, it can have full read-only access to the file system without risking anything important. I am told we can build general limits of file system access with chroot, but I am also told that processes can break out of these limits. This is an area where I would love to learn more. * We can pass in the privileges we think the process should have via open file handles. These will probably include the ability to render on a portion of the screen, and the ability to get mouse and keyboard focus. (We need a way for trusted code to mediate these accesses so the user can have a secure attention function.) * Strict control of other communication paths I haven't thought of. :-) In addition everyone's sending you HTML-formatted mail, so you need access to (in effect) MSIE via the various HTML controls. An HTML renderer should be able to run in the above environment. Further, you need Word and Excel and Powerpoint for all the attachments that people send you. For viewing Word etc. documents, the applications should run in the above environment. The interesting case is where someone has sent you something like a Word document and asked you to mark it up. Everything should proceed well in the above until it comes time to save a local copy or mail the changed document back. http://www.combex.com/papers/darpa-report/html/ describes the Powerbox pattern for allowing the user to specify an output file for a confined process such as we are discussing. I would think the best way to return such a file in Unix would be as an open file handle. However I don't know of a way for a program to call a service with greater privilege than it has and accept a return value unless that service is part of the kernel. Perhaps some Unix experts can come up with ideas. As for mailing the document back, if the mail agent gave the confined program read-write access to a copy of the file, the confined program could write its output over the input and the mail agent could then make that file available to the user when the confined program returns, and the user could include it in the reply email. They need access to various subsystems like ODBC and who knows what else as an extension of the above. Since most users do not have these facilities running on their machines, I suspect that most Word/Excel/Powerpoint files would render quite well from a confined process. I would say that having random, perhaps hostile, files able to update my local data bases is a violation of my security policy. As you follow these dependencies further and further out, you eventually end up running what's more or less an MLS system where you do normal work at one privilege level, read mail at another, and browse the web at a third. This was tried in the 1970s and 1980s and it didn't work very well even if you were prepared to accept a (sizeable) loss of functionality in exchange for having an MLS OS, and would be totally unacceptable for someone today who expects to be able to click on anything in sight and have it automatically processed by whatever app is assigned to it. UIs have changed considerably since the 1980s. It turns out that modern UIs make it much easier for users to run programs with only the privileges they need than the UIs of the 80s. (See the email thread at
Re: anonymous DH MITM
bear wrote: You can have anonymous protocols that aren't open be immune to MITM True. And you can have open protocols that aren't anonymous be immune to MITM. True. But you can't have both. False. In fact, it is possible to prove the existence of at least one open and anonymous protocol that is immune to MITM in any given, feasible scenario (ie, given a threat model). Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Monoculture
At 8:32 PM -0700 10/1/03, Matt Blaze wrote: It might be debatable whether only licensed electricians should design and install electrical systems. But hardly anyone would argue that electrical system designers and installers needn't be competent at what they do. (Perhaps most of those who would advance such arguments were electrocuted or killed in fires before they had a chance to make their case). In most of the US, a homeowner can install electrical systems in their house. However, their installation must be up to code, and inspected by a government inspector. The analog for crypto protocols seems to be obvious, although the inspector part seems to be more ad hoc and community based. (But there's no building permit either.) Cheers - Bill - Bill Frantz| There's nothing so clear as | Periwinkle (408)356-8506 | vague idea you haven't written | 16345 Englewood Ave www.pwpconsult.com | down yet. -- Dean Tribble | Los Gatos, CA 95032 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
crypto licence
Guus Sliepen wrote: Some advice on licensing wouldn't go amiss either. (GPL? ... LGPL? ... something else?) I'd say LGPL or BSD, without any funny clauses. With crypto code, we have taken the view that it should BSD 2 clause. The reason for this is that crypto code has enough other baggage, and corporates are often the prime users. These users are often scared very easily by complex licences. We'd tended to vacilate somewhat with applications, between various Mozilla/Sun community models, but with the underlying crypto, always as free as possible. If you wanted to be in the GPL community, then LGPL. GPL itself will infect any apps, so unless you have a really great belief that you want those users and no others, stick to LGPL. Mind you, those have been our experiences. It's quite plausible that we'd have attracted a bigger developer base simply by going GPL. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
