Proposal: Personal Data Encryption (maybe SoC?)

Joe Pfeiffer jjpfeifferjr at comcast.net
Fri Mar 23 18:40:21 CET 2007


Gabriel Ambuehl writes:
>On Friday 23 March 2007 18:01:09 Joe Pfeiffer wrote:
>> >~/file1
>> >and ~/encrypted/file2
>> >seems a lot easier to implement AND use to me...
>>
>> Implement, yes (since it's already been done).  Use?  I don't think
>> so.
>
>You can actually use it right now, with almost every app (except for those 
>broken enough to use hardcoded filenames), without any hacking. Most of the 
>neat features mentioned above are app level anyhow which is very well 
>possible...
>
>Now, for a (IMHO) truly useful extension: find a way to cache writes and 
>encrypt them with a public key so that creating new files (for example 
>because you just received a SMS) can work while the phone is locked. Once the 
>phone is unlocked, decrypt the data and store it in the encrypted FS.

I'll need a phone to explore that...

>Maybe it's just me, but pefs seems vastly over engineered. Which is generally 
>a bad thing when it comes to encryption...

Hmmm...  I don't see a lot of over-engineering there; just what's
needed to support the use case that best matches my intuition of what
a user will find most straightforward (well, OK, allowing keys other
than a single password, maybe).  But then, as the guy who wrote the
description, I wouldn't be likely to.

Beyond that, I think we're at a real YMMV point; what I see as the
most straightforward approach for a user is something you see as too
much work to implement for not much (if any) benefit; what you see as
a straightforward way to work and an easy interface for a user I see
as awkward.  And since we're both spouting opinions, there's no way
to do a real comparison without a prototype.




More information about the community mailing list