Einladung: How secure asymmetric encryption to yourself? @ Sa 21. Mär. 02:00 – 03:00 (GnuPG Users)

[Gordian Klein]

Sie wurden für den folgenden Termin eingeladen.

Titel: How secure asymmetric encryption to yourself?
Hi!

gerry_lowry (alliston ontario canada) schrieb:
> Sven Radde wrote, in part:
>
>     "... there are more usable ways of managing one's passwords
>          than storing them in a GnuPG file".
>
> I'm curious what "more usable ways" there are that Sven and others
> can recommend.

/First of all, @Listowner: Let me know if this should be taken off-list
because it's too OT.../

I mean tools like Keepass/KeepassX, PasswordSafe, or similar (even the
Firefox password manager can encrypt stored passwords with 3DES and a
master password). I also mean a Truecrypt volume or loopback container
for storing the password file. For Linux, encfs or ecryptfs come to
mind, too.

The reasons are as follows: With GnuPG, you have encrypted one file. To
be secure, you must now delete the original copy, which is not easy in
itself, although recent research [1] seems to show that a single
overwrite is sufficient for secure wiping. Didn't we have a discussion
about secure deletion not too long ago?

Now, to access your encrypted passwords, you need to decrypt the file,
resulting in an unencrypted version of it on your drive. When you are
done, you have to securely delete it again. If you have modified the
file, you have to remember to encrypt it between having saved the
changes and deleting it.

Of course, you can set the thing up in a way that the unencrypted file
is written to a RAM-only disk, but keep hibernation and swapfile issues
in mind.

You can also have GnuPG output the data to the console only, if you just
have to read a password (I have no idea if there are possibilities that
console output find its way into logfiles or similar, though). Depending
on the size of your password file, you have quite a number of lines
written to the console where you have to find the password that you need
for the moment. If you'd format the file like:
purpose1 -> password1
purpose2 -> password2
you could do something like "gpg passwords.gpg | grep purpose2" to find
the password you need.

As mentioned, some shellscripts could automate the process (create a
ramfs mountpoint, decrypt the password file to there, grep it to find a
desired password, or launch a text editor, re-encrypt the file after the
editor closes, unmount the ramfs).

KeepassX, e.g., supports organizing your password file into groups,
adding metadata such as URLs to the passwords, comfortable hotkeys,
integrated random password generator, password entropy estimation etc.
The main difference, though is the transparent way to access your
passwords (this is also true for Truecrypt and the other mentioned
encrypting filesystems): Enter the master-password, work with the
password file(s), lock the storage again. Done. No unencrypted copy on
disk, ever (apart from the abovementioned swapfile and hibernation).

Given these tools I also disagree with the notion that "frequently used
passwords reside in one's memory" (although I remember quite some
passwords, myself). Password-reuse is one of the greatest problems with
passwords (and, btw, becomes quite infeasible once you have to deal with
varying complexity-policies, different expiration-intervals etc) and
passwords you have to remember tend, in general, to be weaker than those
that you don't have to remember.
With Keepass, you can have a different 20-character pseudo-random
password for every stupid web forum (not to mention the more important
things). It just doesn't matter whether your password is "123" or
"las2ieu7hxalm5iuemalie" if it's just pressing "Ctrl-Shift-A" to
auto-type username and password into the login form.

I do not mean to endorse specific pieces of software here, nor do I mean
to belittle GnuPG. But I think you need the right tool for right task.
And GnuPG IMHO has its strengths not in providing protection to
frequently accessed (and modified) files.
If you need to archive a backup copy of your passwords on a remote
server, that's a wholly different issue, though. GnuPG will do an
excellent job there and digital signatures are even a bonus.

cu, Sven

[1] http://www.springerlink.com/content/408263ql11460147/ --
unfortunately only the abstract is free for general access

_______________________________________________
Gnupg-users mailing list
Gnupg-users at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Wann: Sa 21. Mär. 02:00 – 03:00 Berlin
Kalender: GnuPG Users
Wer:
     * Gordian Klein- Organisator
     * GnuPG Users
     * gerry_lowry (alliston ontario canada)

Termindetails:  
http://www.google.com/calendar/event?action=VIEW&eid=X2M0bzM4ZTlpNnBnbThiYjVjb3BqY2I5azc1aWplYjlwNmRoM2FiOWs2MWozZWQzMzY5aDMwYzlnNjggZ251cGctdXNlcnNAZ251cGcub3Jn&tok=MjgjZ29yZGlhbi5rbGVpbkBnb29nbGVtYWlsLmNvbWE4ZDVjMmRjZmE0ZWNkNTBiMGI1M2VhZjUxNzA2NDEyN2MzOTNlM2E&ctz=Europe%2FBerlin&hl=de

Einladung von Google Kalender: http://www.google.com/calendar/

Diese E-Mail wurde an gnupg-users at gnupg.org gesendet, da Sie ein Teilnehmer  
dieses Termins sind.

Lehnen Sie diesen Termin ab, um keine weiteren Nachrichten zu diesem Termin  
zu erhalten. Sie können sich alternativ für ein Google-Konto unter  
http://www.google.com/calendar/ anmelden und Ihre  
Benachrichtigungseinstellungen für Ihren gesamten Kalender steuern.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20090922/8a9081f5/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 5770 bytes
Desc: not available
URL: </pipermail/attachments/20090922/8a9081f5/attachment-0001.icz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 5859 bytes
Desc: not available
URL: </pipermail/attachments/20090922/8a9081f5/attachment-0001.bin>