Proposal: Personal Data Encryption (maybe SoC?)

Andreas Kostyrka andreas at kostyrka.org
Wed Mar 21 21:44:17 CET 2007


* Joe Pfeiffer <jjpfeifferjr at comcast.net> [070321 20:58]:
> Tim Newsom writes:
> >
> >On Wed, 21 Mar 2007 9:34, Joe Pfeiffer wrote:
> >> Tobias Gruetzmacher writes:
> >>
> >> Right -- these look like good approaches, but to a different problem.
> >
> >/please excuse my direct manner.. Its just how I write (smile)
> 
> Likewise -- it's hard to see somebody smile by email, and I never
> intend to offend.
> 
> >What do you mean by different problem? Maybe I don't fully
> >understand.
> 
> Near as I can tell, these approaches require you to partition up your
> maching into an unencrypted area and an encrypted jail -- maybe
> through a physically separate device, maybe through a separate
> partition, maybe through a file that's mounted as a filesystem.  I
> don't want that -- I want to be able to specify encryption on a
> file-by-file basis, in a manner that comes as close as possible to
> being generic across all applications without code changes to those
> applications.
> 
> At the moment, I'm wandering around the source code for __libc_read() and
> __libc_write() to see if there's a good way to hijack a program's
> read() and write() calls, so if they are to a file that's marked as
> encrypted the data can go through encrypt() on the way....

Yes, you can in theory do that. E.g. use a LD_PRELOAD library.
BUT, here come the pitfalls:

a) you need to keep extreme exact file positions. Or use lseek on
every read/write to get your place in the file.

b) mmap.

c) from my experience, stdio.h, C++ streams and unistd.h read/write
reach a different site for the kernel syscall. That might have changed
or have been an artifact of LD_PRELOADing into the app.

So encryptfs sounds way more useful for that usage.

Andreas




More information about the community mailing list