On Sun, Aug 20, 2000 at 06:42:33PM -0500, Bojay Iversen wrote: > > > This might not be a wonderful idea. Putting the data to disk and > > having the plaintext on disk may not be a truly wonderful idea (ever > > heard of an electron scanning microscope?). > > You don't need a microscope. Second, this can easily be solved > by disabling the swap partition and then implimenting a ramdisk. > Actually, to enable one, you typically need only write the data > to the device and it will automagically allocate the required > space... atleast for linux.
No, people can *look* at *any data that has /ever/ been on any magnetic media* with a scanning electron microscope. It is extremely difficult if not impossible to remove the previous data. The easiest way to remove the previous data is to melt down your hard drive's platter with thermite. > But yes, I agree - if plaintext at /any/ point is, or can be, > written to disk, then you have defeated plausible deniability > for whether or not that data ever existed on the node. Actually, > you won't even be able to /implausibly/ deny it was ever there! :) > > However, since most data on the freenet network needs to be > decoded back into a useful format at some point (ie: plaintext), > I wouldn't consider this a freenet issue. No, just make a node (of course has to be written in a language such as C or C++) which locks all buffers which contain plaintext. This makes it far more of a pain for THE MAN to get the plaintext, because instead of simply looking at the disk with a scanning electron microscope, THE MAN has to rip open your RAM chips in a clean room and do a very thorough sodium diffusion analysis on the RAM chips. It would probably be much easier to grab the data from the swap than to do sodium diffusion analysis on RAM chips. > It's worth mentioning in the user documentation (if such docs > are ever written up in detail!) that a user requiring a high- > security node will need to create a ramdisk and place all > downloads there until it can be encrypted by a suitable utility. Of course (for both things). > Again, disabling the swap partition (or placing the swap file > on an encrypted disk.. which would be hideously slow) and ensuring > the encryption program used does not write any intermediate files > to physical media is of paramount importance. It goes without > saying that other standard security practices should be followed.. > like making sure /dev/kmem is properly protected. SysV also has > a feature[1] that any one, or any program, can overlay its data segment > onto any other system, granting both read and write access. Combined > with some signal handlers and maybe an atomic operation or two, one > could easily force both the freenet software and/or the encryption > program used to divulge sensitive information. This only underscores > the need to establish the framework of a high trust system - Wouldn't someone need to get at least an account on your box under their control, if not root to do this? I assume that the people who wrote SVR4 and the people who wrote Linux had the presence of mind to only allow root to enable sharing shared memory with other boxen. Also, doesn't shared memory have permissions, which makes it impossible for a user other than root to access another user's shared memory provided the author of the software using shared memory was sane enough to set the permissions so no other users (other than root, of course) could access the shared memory. > Freenet cannot (and should not) have the responsibility of securing > your system. No, but Freenet nodes and clients should be designed to be as secure as possible while still functioning properly. > ~ Signal 11 > [1] this feature goes by the name "shared memory".. quite useful > actually, and also quite dangerous if run as root, obviously. Why is shared memory dangerous if used as root? If what you said above is correct, other people would be able to access your shared memory from other boxen (which would be especially bad if you are root) (which should not happen if people the people who implemented shared memory had any sanity). -- Travis Bemann Sendmail is still screwed up on my box. My email address is really bemann at execpc.com. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 3262 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20000820/6a8adba1/attachment.pgp>
