-----BEGIN PGP SIGNED MESSAGE-----
At 02:41 AM 5/17/00 -0700, John Gilmore wrote:
...
>Microsoft didn't care
>about the actual security they provide their users ("Having at least
>some encryption is better than nothing" is wrong and dangerous,
>leading to a false sense of security when you are actually
>vulnerable).
I understand the sentiment behind this statement, and I would have
agreed a year ago, but I think this is wrong for most peoples' threat
models. Having some not-trivially-breakable crypto is better than
nothing for preventing untargeted attacks, where someone's just
looking at the traffic that goes by, checking for anything
interesting. That's honestly the right threat model for most people
to worry about.
A targeted attack is different. In that case, someone is willing to
spend real resources to read certain traffic you're sending or
receiving. Those resources might be time on a DES cracker, or just
time on a network of desktop machines during off hours, cracking 40
bit RC4. But the resources cost something, and that imposes a limit
on how many people can be targeted.
Now, I totally agree, there's no good reason (other than stupid
export-control laws) to use breakable crypto when strong crypto will
work just as well. But even relatively weak crypto, widely deployed,
would do an enormous amount to improve most peoples' privacy. (Of
course, this is subject to all the obvious caveats about having a
false sense of security, vulnerability to eavesdropping twenty years
from now, of recorded messages, etc.)
...
>There have been allegations that NSA influenced Microsoft's
>encryption support (one reason that NSA could afford to relax export
>controls could be that they've already subverted the highest volume
>US products). It's pretty well acknowledged that NSA did this to
>Crypto AG's hardware products decades ago, and has been reading the
>traffic of those who depended on those products. An eavesdropper
>doesn't need to break the encryption if they can break the user
>interface and make it lie about whether it is really encrypting.
Maybe, but if you can dumb down the crypto someone's using, why dumb
it down to 56 bits (which is too short, but still a lot of work to
break)? Why not dumb down the PRNG, or make the thing leak key bits
in its IV, or something? I mean, once you are in a position to
weaken someone's crypto, why settle for 56 bits, rather than leaving
them with no security at all against your eavesdroppers, or some
trivial amount. You could make this really subtle; maybe you always
generate 128-bit outputs from your PRNG, and use the first 64 bits as
IV and the second as a DES key (ignoring parity bits). You could
make the second 64 bits a function of (say) 16 random bits and the
first 64 bits, and I suspect you could do this, with some PRNG
constructions, in a way that would be *very* hard to see in the code.
(Keys still have full entropy if looked at by themselves, and key,IV
pairs have 80 bits of entropy, so you need to examine about 2^{40}
key,IV pairs to detect this in a straightforward test.)
I guess one possibility is that you might want to just make sure you
can brute-force interesting traffic. Another possibility is that
you're counting on interaction between the dumbing-down; the PRNG has
about 1/2 bit of entropy per bit of output, plus you use single-DES,
thus you can break the thing with 2^{28} work, while attackers who
haven't analyzed the PRNG have to do 2^{56} work. Still another is
that this is just another example of Microsoft not being particularly
interested in security, as opposed to impressive-looking feature
lists, shipping the product on time, fixing most of the visible bugs,
etc. At some point, it's impossible to distinguish incompetence,
malevolence, or simple lack of interest in security.
> John
- --John Kelsey, [EMAIL PROTECTED]
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.1 Int. for non-commercial use
<http://www.pgpinternational.com>
Comment: foo
iQCVAwUBOSLYsiZv+/Ry/LrBAQG8nwP9FucP/1HrXgxlILoFlI/sWFbgUpbfgm8n
iyW1GeQpyvVqOjj9qy+0VVOiaA3jH3NoSOIBtTv3yY9hibPn8RY62BbquCCCt63l
mOysZa/nCg28+rT7pJk/Y+FngAW4p4d79ICdryMvaLRSlXSdnCPbftfjzjGb2CCL
gVkg1kRHbRY=
=eKQc
-----END PGP SIGNATURE-----
