FBI Confirms Magic Lantern Existence

The_THOMAS (and many others) writes: "A day after major anti-virus firms waffle on their support for 'Magic Lantern', and nine days after Thomas C Greene of The Register tried to throw cold water on it's existence, the FBI Confirms the 'Magic Lantern' Project Exist. Welcome to a Brave New World!"

Comments

Possiable solution (peer-to-peer key checking)

[macmouse]

Why hasn't anyone thought of this before?..

Its a bit insane but think about it..
This would ideally be applied to jxtra (www.jxta.org) - suns peer to peer protcal layor (different things can be put ontop, like a web browser, a IM message,file sharing, etc).

Have the a key/checksum on the file itself. Then to authenticate, connect to the p2p network. Each host would have their own UNIQUE key. The longer a machine is up the more trust. Nearby machines get the key as well.

So, to authenticate the program goes and finds a bunch of random machines, asks what their keys are and what the key is for the package file. Then, you check the machines keys with other machines to make sure they can be "trusted". This would be a cross between the gpg signing "web" and p2p networking.

So the machines that have been on longer can be trusted more. This is to prevent a machine at the isp to generate new keys on the spot (or use the same one over and over again). It would have to be around for a resonable amount of time (24 hours?).

So each time you check package x, at random a series of "hosts" are asked what their checksums are for package x. For the paranoid, could add some route/different isp checking as well. Let say it asks 20 machines. If all match, then odds are pretty good its correct. Also, each host's key would have to be unique and "trusted". Then you can go out onto 100's (even more?) of hosts to check.

True, (in theory) it would be possiable to fiter for those specific requests, generate a seperate key for a bunch of ip's RANDOMLY and have them authenticate with each other, but that would be quite difficult. In order to do that, they would essentially have your connection severed from the net, with no direct path and on a "virtual" network, in which case your screwed anyway.

It isn't the most efficent way, but probably about as secure as you could get. Well, without being the govenment itself ^_^.

Signatures on Debian packages

[Overfiend]

With all of that in mind, I decided to find out just how vulnerable I was. I set up a stock Debian 2.2r3 box... I went to the Debian box and typed 'apt-get update ; apt-get upgrade'. After a few routine prompts, none of which triggered security alerts, the box was rooted by my "custom" package.

Progeny Linux Systems wrote, tested, deployed, and submitted as patches to Debian, code to implement cryptographic package signatures. Some of the patches now exist in dpkg CVS, but Wichert Akkerman rejected others. Part of it had to do with a command that would prompt you (package maintainer) for your GPG passphrase and cache it so that it could be applied to each binary package (consider how tedious it would be to re-type the passphrase for each binary package in a package like XFree86, which has dozens; moreover, you're no *more* susceptible to a keystroke logger if the passphrase is cached). Anyway, this tool was written in C for security (locked memory pages), but Wichert wanted a version in Python instead, so he never accepted the code.

I never have quite figured that one out.

Anyway, since Progeny ceased development on its own distribution, not much work has been done on our signed package implementation. The code has already been publicly released; maybe it's time for people in the Debian community to take up the fight?

The specification, authored jointly by Ben Collins and John Goerzen, allows for multiple signatures per package. I wrote a policy administration tool called apt-checksigs that would let the user configure the strictness of signature checking on a per-repository basis.

Is anyone interested in this stuff?