But, see, people like not having strong identities on the internet, and where it matters, reputation and identity get built up organically already (i.e., I don't need Utu to know who the idiots are in my favorite IRC channels).
As a practitioner, I'm going to chime in and agree completely.
Shaw has created a merit badge sash of crypto exotica: Needham-Shroeder key exchange (oh, sorry, "ISO IEC 48798783 without the Helsinki vulnerability"), a bizarro block cipher mode, a custom PRNG, and no explanation whatsoever of the motivation behind his choices. Of course, this is all just libtomcrypt under the hood, which probably explains the showy idiosyncrasy.
You'd be able to take something like this more seriously if Zed "So Fucking Awesome" Shaw had ever contributed any findings against TLS, or even SSH. But that would be Hard, Harder than "fighting the cargo cults" --- people much more demonstrably competant than Shaw have already shaken the bugs out of TLS.
Generally, I find Shaw's arguments and reasoning about security unconvincing. For instance, there's a place in that article where he argues that "binary protocols have fewer buffer overflows" --- he might as well just write "I don't pay attention to vulnerability research". He seems to believe that Ragel, an obscure regex-modeled lexer, is a talisman against vulnerabilities. His "Hate" protocol assumes that attackers originate from single sources, not from armadas of compromised machines.
Sigstoat isn't the first person to comment on this "top 10 list of signs of bad security" --- this is a point Schneier makes, often.
Being cryptic is bad -- in "secure code" and just about everywhere else. Unfortunately, that's not the point the commenter made at all.
As to your praise of the notion that the author of an open, civilian protocol is making his protocol less secure by revealing what hash functions he's using, well, I'm just going to say that I'm a practitioner too and I've never heard of openness about the algorithms involved as a sign of bad security. Indeed, I've never heard Schneier once make that point, much less hear him make it often and I read Cryptogram almost every month. Sorry, but I'm calling bull on that one.
The only folks who get a pass on not revealing their algorithms are NSA cryptographers who create Type 1 National Security systems and that's only because they have a large, knowledgeable community of cryptographers within the organization that does their peer review, thus obviating the need for vetting their protocols with the greater academic community.
You just spent 3 grafs kicking a straw man, which you'd know if you'd read the article. This is a discussion about an article. The source code for the software the article is about was published in 2005. Nobody argued that he should have kept his algorithms secret; they argued that bragging about them in an article didn't make him look more competant.
Also, you already said you weren't a practitioner; which is it? Your use of the term "Type 1 National Security systems" allows me an educated guess, but you could clear it up.
Let's see, I replied to someone's comment with a valid criticism. I just read the entirety of Zed's piece and, lo and behold, my argument against the comment still stands. (Whether or not Zed's protocol still stands is an open question.) Meanwhile, you've been attacking a strawman the whole time.
Now you're trying to personally attack me. I'm not sure what your problem is or what you're trying to prove, but I am a practitioner.
(You won't find my name in that last document, as authors and supporting researchers are not listed on FIPS.)
I'm not going to ask about your credentials because, frankly, they don't interest me. You've jumped the shark and I'm done responding after this. Don't make this thing personal; you've got a problem with my comment, do us all a favor and keep it there. You trying to start a pissing match with me is boring for everyone and ultimately wastes both of our time. Chill.
You're right. I'm infinitely more irritated at the mentality conveyed by Shaw's document, that "security" is a combination of using the most "advanced" crypto constructions and using parsing tools to avoid superficial overflows than I am at you for arguing with people about a post you didn't bother to read.
Just a note on ragel: it can be used to create lexers, but that is not its distinguishing characteristic. It is a parser generator for regular languages.
Because this is a more interesting conversation than the grandparent comment --- what's the difference between a lexer generator and a parser generator for regular languages? What can I do with Ragel that I can't do with a (probably clumsy) application of Flex?
I don't mean to snipe at Ragel, just Shaw's use of it as an amulet against vulnerabilities.
You can define a full grammar for a language and embed actions in arbitrary places. It is compiled to a very fast DFA. Think of it as a yacc for regular languages.
Zed's advocacy for Ragel is really about using parser generators to implement internet-facing parsers.
All due respect, but thinking that a system's security relies on people not knowing what ciphers and hash functions the system uses is on the top 3 list of signs that you're clueless about security. It'd be difficult to have made a more ironic post than slamming someone for "not understanding security" with a "security through obscurity" argument. ;)
Maybe what sigstoat wanted to say is that telling so much detail about that could be a sign that he doesn't know much about it. You don't talk about loops all the day when talking about programming, as they are the fundamentals any decent programmer understands and can imagine by himself (and when there is ambiguity, any programmer can check some extra documentation or even the code later to know about the details). I don't know much about security so I could be wrong, but that's what I think he could have meant.
To your point, though, a security protocol implementation document that makes use of secure hashes, encryption schemes, and the like isn't typically considered credible unless it states precisely what building blocks it uses. For instance, it's not enough to say you're going to use "random numbers." You need to say how you're going to seed and generate your pseudo-random numbers. The details matter.
Had the document spent time explaining what CBC means or how AES is implemented, that would have been the security equivalent of talking too much about loops or Quicksort.
If Zed Shaw was interested in having people review his weird chat protocols, he'd probably:
* Document them without the "mixture of humor, ranting, code, and specification language." The "specification language", presuming it's not in something Zed invented (like Stackish franken-sexps), would do nicely.
* Use well-understood, well-tested primitives, and where he deviates (ECC might be mainstream, but CCM and Needham-Schroeder public key exchange aren't), explain why.
* Describe things in terms of the cryptosystem and the goals, instead of using the least intelligible, most intimidating acronyms he can come up with (seriously, "ISO/IEC 11770-3 Mechanism 6"?).
You're exactly wrong, of course. Zed's using CCM, and an evaluator would want to know what properties his system expects to achieve from doing so. Talking about CBC (or CBC-MACs) would make him look more savvy. Instead, we get "I’ve decided to send it back as Er(Nr) but I’m not sure of the security of this."
I should be clear; I haven't read Zed's documentation and neither approve nor disapprove what he wrote. My reactions are strictly to the notion that a protocol creator shouldn't mention specifics in a security document -- that's flat out wrong.
Until the snarky bit at the end there, I agreed with you 100%.
Ah, the Internet, where people act tough when they're safe behind their computer screens. You're really cool, getting so riled up about encryption schemes and commenting habits that you're typing swear words at me on a forum.
<shaking my head>
I'll say in advance, don't blame me for the downmods -- I didn't contribute a single one.
well, you don't have to speculate, as that was basically my meaning.
(where'd you get security through obscurity? christ.)
good designs don't hard code silly stuff like block ciphers and prngs. those come and go. you let the two sides negotiate what cipher they want to use, and design the overarching protocol to be as secure as the ciphers being used. (see ssh.)
As I understand it this opens you up to a lot of extra possibility for vulnerabilities. Each new combination of block cipher, prng and hmac etc has the possibility of interacting in unforeseen ways. Maybe it's better to specify all these things so that the system can be evaluated as a whole. At least that's the impression I've got from Practical Cryptography which I'm currently reading.
i'd be fascinated to see a reference to the literature of an interaction between cipher/hash/prng (and two) that caused them to be insecure, when the cipher/hash/prng alone didn't become considered insecure in and of itself.
and i would be at least slightly curious for a pointer into where practical cryptography makes that point.
ssl, pgp and ssh are all examples of software which is generally accepted as secure, which does not mandate particular algorithms up front. see nearly every piece of snake oil out there as an example of software which does talk about their algorithms and bit counts up front.
You may be right, I'm very far from being an expert in these things. That is what I understood from what I was reading though, if I get time this evening I'll see if I can find the place.
All due respect, but the "security through obscurity" argument went out the window when Shaw published his source. His propaganda is fair game, and sigstoat is right.
