[liberationtech] PassLok updated based on feedback from LiberationTech

[Francisco Ruiz]

Thanks for the excellent feedback, folks. I have taken to heart your
recommendations and updated PassLok. The version number is still 1.2
because keys and messages remain compatible.

The updates include, in addition to bug fixes (thanks everyone):

1. Visual aids (triangles) to cue users about titles that can be expanded
into a help section (thanks, Karl).

2. The Make Lock function has been given its separate button. Same for the
make ID function.

3. Some boilerplate has been added to the source for filters to recognize
the code as freeware (thanks hellekin).

4. A revamped Key strength meter, which won't give a perfect score until
the user has appended his/her email to the Key. This is to combat a
powerful attacker (like the NSA) who might be able to make a rainbow table
containing public keys for a whole dictionary's worth of likely private
keys (Thanks, Michael; not quite the same as adding a random salt, but I
think this achieves the objective without inconveniencing the user too
much).

You can get the program from http://passlok.com, which sends you to
https://passlok.site44.com

I have a few more questions to ask those kind enough to check out PassLok:

1. PassLok includes a function to display QR codes, which I added so that
users could exchange Locks (public keys) from smartphone to smartphone
while offline. But this makes the code larger by 30kB and, according to
some, makes harder the job of those inspecting the source code. Is it worth
keeping the QR-making ability?

2. In the updated version, I have attempted to thwart a rainbow table
attack by encouraging users (through help text and the key strength meter)
to add their email address to their private Key. The best way to achieve
the objective, however, would be to add a random salt in the public key
generation process, which would be appended to the public key. When a user
wants to use his/her private key, he/she would have to fetch the public key
from whatever location it has been published, and enter it along with the
private key. Would the increased security be worth the hassle to the user
and additional complexity of the program, though?

3. Some users are confused by having both symmetric and asymmetric
encryption available, so they end up encrypting messages with their private
keys, which no one else has. Would it be better to hide or eliminate the
symmetric encryption mode, so this doesn't happen? Can you offer a better
solution?

4. Then, there is the issue of authenticating the code so users have some
assurance that it has not been modified by an attacker. Currently the
PassLok help file directs users to do a "view source" in their browsers and
take a SHA256 hash of the source (whether using the ID function of Passlok
itself or an external utility), and compare it with the hash published in
the help.html file (obviously, it must be a separate file). Now, an
attacker might be able to modify the help file as well as the main file.
Should the two files reside in completely different servers? I think it
might be better to quickly replicate both files to several mirrors, but I
don't know how to go about that. Any other strategy that might work better?

Thank you very much.

-- 
Francisco Ruiz
Associate Professor
MMAE department
Illinois Institute of Technology

PL12lok=KpYv+bqJ7pq0eqC664UlIcwfl1P8f8p12NUqFdg2bQ2gTQTBuOo09BQs3GGiYOQUuQmtnoceAxJoSzjvYEYOM0q=PL12lok

get the PassLok privacy app at: http://passlok.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20130730/83824360/attachment.html>