Tobias Gruetzmacher wrote:
Hi,
Am Mon, 19 Mar 2007 12:28:28 +0100 schrieb Sven Neuhaus:
With regards to encryption - it'd be great if microSD cards can contain
dm-crypt'ed partitions. It's probably rather trivial to add this.
Partitions are a major usability nightmare IMHO. That is the reason my
proposal focused on encfs/ecryptfs, which both are "layered" encryption
"file systems". This removes the requirement to set a fixed size for the
encrypted space and makes it easy to use standard tools to backup the
encrypted data.
Greetings, Tobi
Just wanted to throw my $.02 into the mix. I think the most important
aspect of this is ease of use...KISS. Some of the ideas floating around
are over the top. It might give you warm fuzzies to have some "super
cool" encryption scheme, but it will be completely pointless if you make
it so difficult to use that (normal) people don't use it.
There is a big difference between what is needed for keeping nuclear
launch codes and your shopping list secure. Since it is much more
likely that you will be storing your shopping list rather than
top-secret documents, lets focus on encryption schemes that are more
target for that use. Also, *most* times that a phone is lost/stolen
people are just going to want to wipe it then sell on eBay, not "hook up
a debug board and do a memory dump." Seriously, where are you at that
crooks are THAT tech savvy??? Please let me know so I can stay far far away.
Now to contribute something productive, rather than just complain on the
list. Here are two ideas that if used together be simple and effective.
1) I do like the gesture based approach as that is something that can be
easily input using one hand (remember, KISS). However, that may not go
over as well for a non-phone interface. So, having an intermediate
layer that transform "gestures" to a key-phrase would be a great idea.
Then you can have a preference to either input your password/key-phrase
directly OR you can launch the gesture analyzer and that will handle the
inputting of your password/key-phrase.
2) The sudo style of access could also be useful. Whenever "private"
data (still not sure the best/most user friendly approach to determining
what is and isn't) is accessed, you are required to put in a password
(via method above) and it will last for a pre-determined amount of time.
Just the combination of those two ideas would probably suffice for +90%
of users needs. Then, if someone was actually carrying nuclear launch
codes, then a secondary more robust implementation could either replace
or supplement. But your grandmother would still be able to (hopefully)
figure out that scheme.
_______________________________________________
OpenMoko community mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/community
