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.
