Bill Stuart writes:
How can I insure a program, once put on FTP sites stays untampered with? ... On the other hand, without signatures, it's not too hard for a Bad Guy to store bogus files on the server and get them timestamped too - the user needs a good way to check for previous editions of the document in the timestamp file. With digital signatures, at least a given file has some internal consistency.
The holes: 1: Someone hacking the keyservers, substituting a key for all the people who signed, and modifing the archive to show that. That's why keyservers are inherently non-trustable; the trust comes from the Web of Trust connections you have, though a keyserver run by a widely-trusted person carrying only keys signed by him/her/it is stronger.
2: Someone breaking into my apt, sticking a keyboard monitor on, getting my passphrase and key. Yup. That's a problem with signatures.
Another, practical, problem with integrity checks (both signatures and timestamps) for files on public archive servers is that the receiver has to expect them and know how to verify them. Current ftp and www clients certainly don't have facilities to do this automatically, and neither do users have reason to suspect foul play if a timestamp or signature is missing for some file. It's somewhat analogous to the situation ten years ago when some nut was lacing over-the-counter drugs with poison and putting the packages back on the shelf. The major drug companies responded by including tamper-evident seals on their packages, but until consumers learned to expect the seals, all the bad guys had to do was remove the seal entirely before replacing the tainted packages. In the short term, given today's infrastructure, there's not a lot you can do. Of course, in the medium- and long- term, the best solution is to design good schemes and deploy them widely enough that people learn to expect them. -matt