Matt Blaze wrote: > > > I imagine the Plumbers & Electricians Union must have used similar > > arguments to enclose the business to themselves, and keep out unlicensed > > newcomers. "No longer acceptable" indeed. Too much competition boys? > > > > Rich, > > Oh come on. Are you willfully misinterpreting what I wrote, or > did you honestly believe that that was my intent?
Sadly, there is a shared culture amongst cryptography professionals that presses a certain logical, scientific viewpoint. 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 . 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. But, even if a surprise to some, I think it is a fact that the crypto community looks like and acts as if a guild. > I'd encourage the designer of the protocol who asked the original question > to learn the field. Unfortunately, he's going about it a sub-optimally. > Instead of hoping to design a just protocol and getting others to throw > darts at it (or bless it), he might have better luck (and learn far > more) by looking at the recent literature of protocol design and analysis > and trying to emulate the analysis and design process of other protocols > when designing his own. Then when he throws it over the wall to the rest > of the world, the question would be not "is my protocol any good" but > rather "are my arguments convincing and sufficient?" This is where maybe the guild and the outside world part ways. 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. 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. 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 . He has, after all, an application to build. What *is* going to happen is this: builders will continue to ignore the guild. They will build their application, and throw any old shonk crypto in there. Then, they will deploy their application, in the marketplace, and they will prove it, in the marketplace. The builder will find users, again, in the marketplace. At some point along this evolution, certain truths will become evident: the app is successful (or not). The code is good enough (or not). People get benefit (or not). Companies with value start depending on the app (or not). Security is adequate (or is not). Someone comes along and finds some easy breaches (or not). That embarrasses (or not). And, maybe someone nasty comes along and starts doing damage (or not). What may not be clear is that the investment of the security protocol does not earn its effort until well down the track. And, as an unfortunate but inescapable corollary, if the app never gets to travel the full distance of its evolutionary path, then any effort spent up front on high-end security is wasted. Crypto is high up-front cost, and long term payoff. In such a scenario, standard finance theory would say that if the project is risky, do not add expensive, heavy duty crypto in up front. This tradeoff is so strong that when we look about the security field, we find very few applications that succeeded when also built with security in mind from the initial stages. And, almost all successful apps had little or bad security in them up front. If they needed it later, they required expensive add-ons. Later on. There are no successful systems that started with perfect crypto, to my knowledge. There are only perfect protocols and successful systems. A successful system can evolve to enjoy a great crypto protocol, but it would seem that a great protocol can only spoil the success of a system in the first instance. The best we can hope for, therefore, in the initial phase, is a compromise: maybe the builder can be encouraged to think about security as an add-on in the future? Maybe some cheap and nasty crypto can be stuck in there as a placemarker? The equivalent of TEA or 40 bit RC4, but in a protocol sense. Or, maybe he can encourage a journeyman of the guild to add the stuff in, on the side, as a fun project. Maybe, just maybe, someone can create Bob's Simple Crypto Library. As a stopgap measure, as a simple little thing that is so easy to use that even your average apps builder wouldn't get turned away. And just happens to be ammeniable to replacement later on with Alice's Full & Complex Crypto Library. It's pretty much a given that projects will get out there with inadequate security. The market process for apps dictates that. Although I haven't tested it, I believe it to be an economically sound result. The fact that this has little to do with crypto is ... irrelevant. That fact that the cryptographers guild may find this uncomfortable is ... tough. What remains uncertain is, when the time comes to upgrade the security and add some real strength to an application that cries out for help, will there be anyone there to help add the strength? "Why aren't you using SSL" is basically a warning sign to all developers that the man asking the question is a fully paid-up member of the guild. "Why did you do that?" is also not the right question. "What is your threat model?" is a far better start. "What do you have in place right now?" is more or less the question that Peter Guttman was asking, and that is also a good start. Even better would be a preamble that describes how we need to get the threat model down on paper so that an appropriate level of security can be put in place. > I suppose some people will always take an anti-intellectual attitude > toward this and congratulate themselves about how those eggheads who > write those papers with the funny math in them don't know everything to > excuse their own ignorance of the subject. People like that with > an interest in physics and engineering tend to invent a lot of > perpetual motion machines, and spend a lot of effort fending off > the vast establishment conspiracy that seeks to suppress their > brilliant work. (We've long seen such people in cipher design, but > they seem to have ignored protocols for the most part, I guess > because protocols are less visible and sexy). Well, the opposition to "the guild" is one of pro-market people who get out there and build applications. Some people used to call them entrepreneurs, but these days in the net, we think of them as just hackers, because anyone with a code editor can be an entrepreneur. They may sometimes say the wrong things about their own crypto and their own security constructs - such as TINC's "foolishly childish" attitude may have come across - but that's just their eternel optimism and innate marketing sense overriding any sense of absolute but irrelevant truth. That's just them being entrepreneurs. Don't however take home the wrong message. When they defend the crypto, that's because they have a strong sense of priorities. When they need better crypto, then they will know it. Because the market will tell them. > Rich, I know you're a smart guy with great familiarity (and > contributions to) the field, and I know you're not a kook, but > your comment sure would have set off my kook alarm if I didn't > know you personally. It's not the first time that entrepreneurs have been called kooks :-) It generally happens before they are successful, though. iang  I'm ignoring the placement of the apostrophe for the moment.  We can argue the detail, but my point here is that the barrier to entry is too high, so ignoring the guild is the most likely result. That said, here are some points. It's nice that the literature is open and available. What is not nice is how much there is of it. It's nice that there is a lot of code available, and complete protocols to boot. What is not nice is that there is no easy way to work out which code to use, and the protocols are not so easy to understand. It's nice that we have an open community that discusses these things. What is not nice is that, in trying to determine the one path, the advice of the community reduces to useless baubles like "use SSL" or "why did you do that?" It's great that the community has standards, but those standards seem to be excessive in the extreme. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]