On Tue, Jan 19, 2010 at 5:17 PM, <[email protected]> wrote: > On Mon, 18 Jan 2010 23:12:17 +0100, Dan Kaminsky said: > >> I can quantify this with the rate of change of complexity of a system. > > Well, if you're talking *rate* of change... > >> If you add one kilobyte of complexity to Windows (consuming literally >> 8192 bits extra space on the DVD), you have not done much to the >> difficulty of breaking Windows. If you add one kilobyte of complexity >> to an RSA key (literally, adding another 4096 bits to p and q >> respectively), you most assuredly have done much to to the difficulty >> of breaking this particular RSA key. > > Adding 8K to the acres of bits of already on the DVD is proportionally smaller > than adding even 1 bit to a 4096-bit RSA key.
Fine. Double the number of bits on the DVD. > And I'll submit the notion that if it's the *right* 8192 bits, it can add > immensely to the difficulty. I'd have to go back and check, but the stack > address randomization bits added to the Linux kernel were actually quite > tiny, but added a lot to the difficulty. > Yes, but the fact that it *matters* which bits are changed is the whole point. <cryptotangent> If you look inside any credible cryptographic function, you'll almost never see constructs where the internal grammar of the cipher changes with the key. It's not that it's technically infeasible: One could certainly build a Context Free Grammar in which incoming bits randomly shuffled cryptographic primitives in ways that remain reversible given the key. But you don't see this, outside of really awful Dan Brown novels. Why*? Because *systems* have constraints that *keys* must not. A cryptosystem is still a system, one that defends against cryptanalysis, chosen plaintext, and so on. In a valid cryptosystem, all keys after a known filtering stage are equally secure. If you are changing the system, then some keys will emit safer systems than others. An attacker will thus attempt to keep poking your cipher until it inevitably hits an unsafe mode. Windows is a system. Linux is a system. Some bit patterns do interesting things. Others crash. The point of secrecy is to *isolate* the unknown data *from* the stuff that must not only be partially known, but must meet constraints. The point of obscurity is that the known data is somehow so complicated, that the constraints are so obtuse, that it could never be understood. And then some Bulgarian shows up... </cryptotangent> --Dan * OK, it's also pretty annoying to implement in hardware. _______________________________________________ Fun and Misc security discussion for OT posts. https://linuxbox.org/cgi-bin/mailman/listinfo/funsec Note: funsec is a public and open mailing list.
