<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 the symmetric component - but network admins will feel comfortable with a known standard protocol and whoever maintains your package (normally you) will usually sleep better at night knowing that people are stress-testing those essential components, and if any faults are found, you just have to download the fix and recompile rather than find and fix the problem yourself (particularly as a break in a popular library will make it to bugtraq while your program may *never* make it above the horizon for serious security investigators - while hackers may well target it if it is in use at a specific site they have an interest in) > 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. And they will turn up on bugtraq or in the cryptogram doghouse - not that that will matter to them, given they are probably making lots of money and if they have any sense, all the rights will be held by a limited company (so when the lawsuits start rolling in, they can dump the shell and start over with more insecure crap someplace else) they could always start issuing security packs as "upgrades" of course. another useful revenue stream :) > 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. Indeed so. however, if a programmer isn't willing to put the effort into writing *secure* code, how can be be willing to put the effort into writing his own comms/crypto code (instead of just dropping in a library and forgetting it?) > 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. Or use decent crypto up front from a library, and if the software takes off, look at optimizing the code for a later release. > 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. its an evolutionary thing. ten years ago, you could get away with dumping an insecure product onto the marketplace - few users would be on the internet, and even those who were would find few people on there to worry them. You just can't get away with that today - the second a new product is released, a thousand bored teenage hackers will have a warez copy of it wondering how to earn kudos or steal money by abusing it. Most ecosystems see the same thing - to start with, predators are poor hunters, but prey are easy targets. As prey gets better at avoiding capture, so predators get better at trapping them; all remain in balance, with each improvement in defense matched by an improvement in attack by the hunters, and vice versa. But drop one of the early prey into the same area, ten generations later, and they wouldn't manage to take more than a few steps before they died - conversely, drop an outdated hunter into the area and it would starve or become a scavenger on other people's kills (that is not a bad analogy for a Skript Kiddie btw :) > 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 question is - in the current much, much more hostile environment of the internet, how good is "good enough"? look upon it as the burglar alarm principle - most home security isn't really that good, but is "good enough". If you have lights on, a visible burglar alarm and security lights, and the house three doors down has lights out, no visible alarm and a window ajar - it doesn't matter that your house is far from impregnable - that you have unshuttered glass windows, possibly even older less secure window catches without locks - just that it is a hardened target compared to the other choices an attacker has. Even if your solution isn't fort knox, it can still be "good enough" relative to the value of your traffic and the likely attackers. Ok, it costs little extra for "good enough" to be upgraded to very good indeed, but as long as it is good enough you can manage to make your way along for a while and enter the arms race just like the rest of us :) > "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. How about "how much improvement did you get over SSL from your implementation, and what security risks did it introduce?" CIPE is a good example of such a tradeoff - they don't have any protection from UDP replay attacks - provided you can identify which packets are UDP of interest to you and resend them. Their CRC is also fairly weak, (but is inside the crypto envelope) and there are other tradeoffs, all listed in the documentation. As a replacement for IPSEC it is a no-hoper - and that is fine, as they don't *want* to be a replacement for IPSec - they are a lighter, more convenient tunnelling protocol, more bandwidth efficient and noticably easier to set up. If you are using UDP for something security-critical, you want to take a good look at *why* rather than blaming a non-udp-safe tunnel (provided you *know* the tunnel is not UDP-safe in advance) >> 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. One I have seen a lot is reference to a telephone conversation with the authors, where they admitted they didn't know about Microsoft's Automated patch download system. all that springs to mind is a query as to how many people actually *use* that - I know I don't trust it as far as I can throw it. Microsoft's patches have a nasty habit of: 1) requiring the original CD to be inserted 2) overwriting security patches already applied with older, insecure versions (there were a couple of "two of three" situations between service packs on NT where you could install any two of three patches - each backed out one of the others, and there was *no* correct order that would give you all patches applied; you were required to copy the effected dlls from the first patch away safe, copy them back after the last patch, then regsvr32 the things into compliance. luckily, the next service pack overwrote all three patches with a common update) 3) actually breaking existing functionality (for a competitors' package of course) by patching something apparently unrelated (I am sure there will be a few shudders at the mention of NT4 SP6 pre-6a) I don't let any patches *near* a production server until they test out lean in a test environment - preferably from a static CD copy so I can be sure I get the same version on the production server as the test. > 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. As an analogy "ok we built this car with no brakes; so far we are doing fine just switching off the engine and coasting to a stop, and if the market tells us brakes are important we will add them" It is surely better to be warned about the lack of brakes by an interested observer (no matter how condescending it sounds) than to wait for the fatalities and *then* think about adding them? > It's nice that the literature is open and available. What > is not nice is how much there is of it. Indeed. really, crypto needs to be more accessable - there is a *lot* of cross-referenced information out there, mostly in forms where you gradually glean a snippet of knowledge (shared between those posting these pages) here and there until you have enough base knowledge to understand what the web of interconnected and often back-patting pages actually mean. Perhaps a "basic crypto for programmers - how to use crypto and how to decide when crypto is needful" book or website is a good idea. I am probably not up to writing one though, or I would :) > 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?" SSL is a nice catchall wrapper - ok, its overkill in most cases, but that is the price for flexability. I am not so happy it is biassed towards X509, as that is very much linked to the business models of CAs and standards organisations... --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]