So are machines with large RAM and no swap partition more secure then? Logic says it should be BUT! there can always be a but cant there, who knows if there is one in this case? Respectfully Eric Brackenbury PS: How does one configure an install of this nature and is it a no brainer as they say? On Wed, 2009-04-22 at 12:00 -0400, linux-request [ at ] lists [ dot ] oclug [ dot ] on [ dot ] ca wrote: > Send Linux mailing list submissions to > linux [ at ] lists [ dot ] oclug [ dot ] on [ dot ] ca > > To subscribe or unsubscribe via the World Wide Web, visit > http://oclug.on.ca/mailman/listinfo/linux > or, via email, send a message with subject or body 'help' to > linux-request [ at ] lists [ dot ] oclug [ dot ] on [ dot ] ca > > You can reach the person managing the list at > linux-owner [ at ] lists [ dot ] oclug [ dot ] on [ dot ] ca > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Linux digest..." > > > Today's Topics: > > 1. Re: encryption and security (John C Nash) > 2. Re: Re: encryption and security (Stephen Gregory) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 21 Apr 2009 18:14:50 -0400 > From: John C Nash <nashjc [ at ] uottawa [ dot ] ca> > Subject: [OCLUG-Tech] Re: encryption and security > To: linux [ at ] lists [ dot ] oclug [ dot ] on [ dot ] ca > Message-ID: <49EE455A [ dot ] 60604 [ at ] uottawa [ dot ] ca> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > > Can I ask Stephen G and others to volunteer so we can have an OCLUG > panel on encryption and security? Could make a lively meeting and bring > in outsiders. > > I make no claims in this area. My background is number crunching and > statistics, but I did teach risk management for many years. I'll still > be happy to argue that > > 1) ccrypt offers a cross-platform solution that is usable by a much > wider variety of folk than GnuPG, which (to deliberately pour gasoline > on a debate fire) I will claim is geeky enough to scare folks away. > Truthfully, it has to be easier for all of these tools. ccrypt is not > easy enough either, but I find it much friendlier than GnuPG. And, of > course, I don't want to install anything. > > 2) The memory clearing issue is sufficiently important that I would like > to see it addressed, even if it is difficult. In the script I proposed, > my solution -- proposed in order to get reaction, by the way -- was as > follows: > - create a tmpfs in RAM on a machine with no swap (apologies: I > forgot to mention that I run my machines with large RAM and no swap > partition). > - run encfs on this so material in the decrypted area is somewhat > protected. (The ccat or ccrypt -c options are better for just viewing, > but maybe there are other applications for the tmp disk idea.) > - close the encfs > - scrub the "disk" which is RAM > - release the RAM by unmounting the tmpfs "disk" > > Let's see if we can build a meeting program from something along these > lines. > > As an aside, I've found fusermount seems to fail more than it works. > Will have to look into that. > > Cheers, JN > > > > > ------------------------------ > > Message: 2 > Date: Tue, 21 Apr 2009 19:22:33 -0400 > From: Stephen Gregory <oclug [ at ] kernelpanic [ dot ] ca> > Subject: Re: [OCLUG-Tech] Re: encryption and security > To: John C Nash <nashjc [ at ] uottawa [ dot ] ca> > Cc: linux [ at ] lists [ dot ] oclug [ dot ] on [ dot ] ca > Message-ID: <49EE5539 [ dot ] 4080501 [ at ] kernelpanic [ dot ] ca> > Content-Type: text/plain; charset=ISO-8859-1 > > John C Nash wrote: > > > 1) ccrypt offers a cross-platform solution that is usable by a much wider variety of folk than GnuPG > > I see no difference: > > $ ccrypt foo > or > $ gpg --symmetric foo > > $ ccrypt --decrypt foo > or > $ gpg foo > > For this purpose there is no need for gpg public keys etc. > > > 2) The memory clearing issue is sufficiently important that I would like > > to see it addressed, even if it is difficult. In the script I proposed, > > my solution -- proposed in order to get reaction, by the way -- was as > > follows: > > - create a tmpfs in RAM on a machine with no swap (apologies: I > > forgot to mention that I run my machines with large RAM and no swap > > partition). > > - run encfs on this so material in the decrypted area is somewhat > > protected. (The ccat or ccrypt -c options are better for just viewing, > > but maybe there are other applications for the tmp disk idea.) > > - close the encfs > > - scrub the "disk" which is RAM > > - release the RAM by unmounting the tmpfs "disk" > > But as soon as the file is displayed to the user the decrypted data is > in ram. The above doesn't change that. Because it is such a hard problem > I am not sure that clearing ram is worth persuing. If an attacker is in > a a position to dump the ram then they could also install a keyboard > logger, install trojan versions of ccrypt or libc, or a trojan kernel. > > If you were writing your own program you could over write the ram used > to store the clear text. There may also be a system call to lock the > memory page used from moving to swap. But the clear text will still end > up in the video ram. > > > ------------------------------ > > _______________________________________________ > Linux mailing list > Linux [ at ] lists [ dot ] oclug [ dot ] on [ dot ] ca > http://oclug.on.ca/mailman/listinfo/linux > > > End of Linux Digest, Vol 52, Issue 12 > *************************************