GPG guide/Public Review

From LibrePlanet
< GPG guide
Revision as of 12:23, 3 June 2014 by Fried (talk | contribs) (Feedback)
Jump to: navigation, search


This page was a featured resource in June 2014.


Welcome, and thanks for offering to try out the FSF's draft guide to email encryption

Instructions

Follow the draft guide to using GnuPG. **Please don't edit any of the pages except this one.** It's still in development, so it may be missing bits or have parts that say "coming soon." In the final version, this text will be interspersed with beautiful and informative graphics.

Please leave your feedback as bullets in the feedback section. Make sure to include: what step your feedback refers to (unless it's more general), how experienced you are with GPG, and what operating system you are using.

For example:

  • I couldn't find the "Key Management" menu item mentioned in step 3 of section 2. I'm using Windows 8 and I've used GPG a little bit before. Zakkai 18:30, 22 May 2014 (EDT)

Unless you're already a Free Software Foundation member, you'll need to make an account on this wiki to leave feedback. If you find that someone else has already said what you want to say, just add your name after theirs.

When you are done, please, make a note here of your username and how far you got by typing four consecutive tildes in a bullet on a new line in the contributors section. Semantic MediaWiki will automatically insert your username.

Contributors

We'd love to give you credit for your work. If you'd like to be attributed in the final version of the guide, please send an email to campaigns@fsf.org with the name you'd like to be attributed with and your username on this Wiki, so that we can verify your contribution.

  • Zakkai 16:33, 22 May 2014 (EDT) did the whole guide (wrote it, in fact)
  • Adietric 13:03, 30 May 2014 (EDT) - Did all sections with FossaMail (32-bit) on Windows 8.1, comments below.

Feedback

  • Please provide a more detailed explanation of the web of trust. I think it would help if there were some drawings or graphs to help teach the concept. I'm an experienced GnuPG user running Debian. Kojakr 18:20, 23 May 2014 (EDT)
    • I completely agree, graphics would be awesome. Soong 08:06, 1 June 2014 (EDT)
  • I'm concerned that the Windows workflow might not work well. I hope lots of people test this on Windows. I'm an intermediate GnuPG user running Trisquel GNU/Linux. Zakkai 18:17, 23 May 2014 (EDT)
  • Is an 8-letter password current best practice for crypto key passwords?

Here are some guidelines that suggest at least 12 characters:

http://en.wikipedia.org/wiki/Password_strength#Guidelines_for_strong_passwords

Here is a guide to the amount of time it takes to break passwords of various lengths:

http://www.lockdown.co.uk/?pg=combi&s=articles

Passphrases may be slightly better than passwords:

https://www.schneier.com/blog/archives/2012/03/the_security_of_5.html

Althought as I understand it entropy is the real guiding factor.

--Robmyers 20:53, 23 May 2014 (EDT)

    • I agree, more than 8 letters would be a better suggestion. Maybe we can include a link to diceware and and a sentence along the lines of "If you have difficulties coming up with secure passwords that are easy to remember, have a look at diceware. Just get the word list, grab five dice, and generate a password from at least five words from the list. This is both secure and easy to remember."
  • Please don't ask people to support Mozilla financially. They are currently attacking user freedom with their DRM infection vector for Firefox. --Robmyers 20:53, 23 May 2014 (EDT)
  • The article recommends making it "a part of your online identity"---this is fine/ideal (as it allows the creation of a web of trust), but a necessary prerequisite is knowing how to properly protect a private key. Average users will likely go for convenience, but especially on Windows systems, maleware is prevalent---if the system holding the private key is compromised, then the private key should be considered compromised and should be revoked. Considering that most users will be unaware of a compromise, more emphasis should also be placed upon the password strength, including links to resources (e.g. what was posted above); otherwise, all parties involved have a false sense of security and the compromised identity can be used for impersonation. Mgerwitz 23:33, 23 May 2014 (EDT)
  • How many people read email on the web or on their devices? Should the Guide include instructions or recommendations of apps for devices? How might a webmail user read/send encrypted email? Lpb 09:01, 24 May 2014 (EDT), GNU/Linux and GPG user.
  • Intro: "emails that are coded" - "encrypted" would be clearer, IMHO. Adietric 07:28, 30 May 2014 (EDT)
    • seconded Soong 08:06, 1 June 2014 (EDT)
  • Intro: "surveillance agent or thief" - maybe phrase it more neutral: "make sure that only the intended recipient can read it". Adietric 07:28, 30 May 2014 (EDT)
    • seconded, especially since I don't know what a thief would take - if they take the whole computer, then they have the private key as well and if they can somehow make a copy of the key, then it is not theft Soong 08:06, 1 June 2014 (EDT)
  • Intro: "when you need to send something sensitive" - I think it's a bad idea to train users to think of encryption only for "sensitive" communication. I'd remove this whole paragraph. Adietric 07:28, 30 May 2014 (EDT)
    • seconded Soong 08:06, 1 June 2014 (EDT)
  • Intro: "you'll actually do it more often" - Personally, I hardly ever sign my email. Maybe let the users decide and drop this sentence. Adietric 07:28, 30 May 2014 (EDT)
    • exactly, plausible deniability may be a reason to not sign unencrypted mail
  • Section 1: It seems that Enigmail is not compatible with the 64-bit version of FossaMail (Enigmail was "disabled" right after installation). Adietric 12:14, 30 May 2014 (EDT)
  • Section 2a: "the Enigmail set-up wizard automatically uploaded it to a keyserver" - which one? I checked all the ones included in Enigmail, but my key wasn't there. Consequently Adele failed to find my key later on. (Next I tried using "Key Management -> Send Public Keys by Email", since the reply said "If you send me your public key along with another encrypted message", but unfortunately Adele doesn't support attachments. It only works if the public key is sent in the message body, probably not suitable for many users.) Adietric 12:46, 30 May 2014 (EDT)
  • Section 3a: You may want to show Adele's full key ID, in case some joker uploads a conflicting key. Adietric 12:46, 30 May 2014 (EDT)
    • seconded Soong 08:06, 1 June 2014 (EDT)
  • Section 3b: You should mention that the subject line will not be encrypted. Adietric 13:03, 30 May 2014 (EDT)
  • Section 3b: "Notice the bar" - maybe include more information, where is the bar usually, what does it say? Adietric 12:46, 30 May 2014 (EDT)
  • Section 4a: "Upload Public Keys and hit OK" - you should mention that users expose information about their contacts by doing that. (Might not be their intention.) Maybe add a section 4b on how to create local signatures. Adietric 09:39, 1 June 2014 (EDT)
  • Section 4a: "always make sure it actually belongs to them" - you should include information on how to do that properly. This would be a good time to introduce fingerprints, IMHO. Adietric 09:39, 1 June 2014 (EDT)
  • Section 5: Maybe add instructions for how to configure FossaMail/Thunderbird to save drafts to the "Local Folders" account, since they won't be encrypted if the user didn't click on the key icon. Adietric 09:39, 1 June 2014 (EDT)

A few comments from Srevilak 20:22, 29 May 2014 (EDT):

  • Perhaps add a step 1.b.1: If you're using Mac OS X, download GPGTools. I've never tried to set up Enigmail + GPG tools on a macintosh, but I do know that GPGTools has good integration with Apple Mail. GPGTools is probably the most accessible distribution of GnuPG command line tools for macintosh.
  • Step 2.a: "In your email program's menu, select OpenPGP -> Setup Wizard". Perhaps this should explicitly say "In Thunderbird's program menu". (Thunderbird has an OpenPGP menu, but other mail programs may not)
  • Step 2.a: "The program will take a little while to finish the next step". Perhaps say "OpenPGP's Wizard" rather than "the program".
  • Step 2.a: "After creating your key, the Enigmail set-up wizard automatically uploaded it to a keyserver". "Uploads" (rather than uploaded) may be the correct tense here.
  • Section 3a: "Check the first result (Key ID starting with 9) and hit OK." It might be nice if the tutorial included Adele's fingerprint. Introducing the concept of fingerprints here sets you up to elaborate in Section 4. "it requires a way to verify that a person's keypair is actually theirs." Fingerprints are the best way to do that verification.
    • Agreed, how to view your own fingerprint and check other people's fingerprints should appear somewhere in the guide. Adietric 13:03, 30 May 2014 (EDT)
  • Step 3.c: "After you click send, Enigmail will ask you for your password. It will do this any time it needs to use your public key". I think it should read: "After you click send, Enigmail will ask you for your password. It will do this any time it needs to use your PRIVATE key"
  • Section 3, Step 3.b: "-- not even you -- can decrypt it." This is correct. However, Enigmail has the useful feature "encrypt to self" activated by default. This means a new user will be confused if they can decrypt the mail after all. Soong 08:06, 1 June 2014 (EDT)
  • Naming of sections: I suggest leaving all the "Section X, Part X" out so the guide looks less complicated. Soong 08:06, 1 June 2014 (EDT)
  • Maybe the final guide could be a little more condensed. I know there are many details that are important when it comes to encryption, but maybe it would be possible to keep the main guide down to a few simple steps and link to additional information. That way, a user who has never used email encryption before can conquer the topic more easily. They can do step one in one day and read the additional info and then move on instead of being overwhelmed by having all that information in one place. Also, it could be split up between operating systems to thin it out even more. Soong 08:06, 1 June 2014 (EDT)
    • Definetely in favor of dividing it by operating system for the parts that relate to the actual set up.