3 ms·
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
by sigstoat 19y ago
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.)
- almost 19y agoAs 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.
- sigstoat 19y agoi'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.
- almost 19y agoYou 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.