It's 2014. Are we there yet?

[Sam Gleske]

On Wed, Apr 9, 2014 at 3:23 PM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net>wrote:

> Hi Sam--
>
> [offlist for now, see why below]
>
> On 04/09/2014 01:29 PM, Sam Gleske wrote:
> > I've written a document for my family and regularly link it on facebook
> > encouraging friends and family to use it.  Warning to PGP experts, the
> > terminology is dumbed down and the concepts are filtered so not
> everything
> > is technically correct but explained in a way that the user can
> > understand.  Also, it's a few pages of text and mostly screen shots.  I
> > tried making it fun somewhat so bear with the imagery.
> >
> > http://www.pages.drexel.edu/~sag47/privacy_for_everyone.pdf
>
> I'm really glad to see popularization of these tools.  thank you for
> writing this up.  i also really like your tinfoil hat photograph :) But...
>
> i read your disclaimer above, but the document (sha1sum
> 6dac22e5fa1095638149a537d6a3b641ad2dd551) has dangerously misleading
> directions.  I strongly recommend you take it down for now while we
> figure out what to do about it.
>
> I haven't reviewed the whole document yet, but page 15 is particularly
> troubling.  the problem is that you describe the concept of key
> validity, but associate it with key ownertrust.
>
> key validity is "does this key belong to a person whose name and e-mail
> are indicated in the User ID?"
>
> key ownertrust is "am i willing to rely on identity certifications made
> by the holder of this key?"
>
> These are entirely separate questions.  I may know for sure that my
> boss's key belongs to my boss, but i don't want her to be able to create
> a new key that appears to belong to my husband, certify it, and send me
> mail that would then appear to come from my husband.  Even worse, i
> wouldn't want my mail to my husband to be encrypted to this bogus key,
> because my boss could then read the contents of the mail.
>
> There are other problems with the text, including (from a quick skim,
> not exhaustive, ordered from trivial to security-critical):
>
>  * page 17 is far too much information about a useless-at-best feature
> (see [0])
>
>  * the document recommends the use of pgp.mit.edu instead of the
> standard pool.sks-keyservers.net
>
>  * the document discourages the creation of revocation certificates
>
>  * page 11 seems to assume that "asking their key ID" is sufficient to
> verify identity, though this is distinctly not the case [1].  this is
> seriously insecure.  I can send you a new OpenPGP key show private half
> i control, but with your user ID and your keyID later if you need
> convincing. :/
>
> I recommend you read the riseup/debian OpenPGP best practices document
> [2] and the GnuPG DETAILS document and consider trying to align your
> document with the information and recommendations in those materials.
>
> I've left this message offlist for now, because i'm hoping you'll follow
> up on the message publicly and make it clear what your plan is with this
> document;  If you'd like, either you or i can post these concerns
> publicly, and we can have the discussion on-list.  But i think a quick
> note from you asking people not to rely on the current draft of that
> document while you revise it for clarity and correctness would be great.
>
> let me know what you think.  sorry to send you a lengthy critique, and i
> hope it doesn't discourage you from continuing to spread the word about
> encryption.  It's just important to avoid making recommendations that
> give people a sense of security that turns out to leave them vulnerable
> in hidden ways.
>
> All the best,
>
>         --dkg
>
> [0] https://www.debian-administration.org/users/dkg/weblog/98
> [1] https://www.debian-administration.org/users/dkg/weblog/105
> [2] https://we.riseup.net/debian/openpgp-best-practices
>
>

I agree with your concerns.  In reality I only started using GPG a few
weeks ago which would explain my amateurish approach I suppose.  There is a
source document written in openoffice...

http://www.pages.drexel.edu/~sag47/privacy_for_everyone.odt

Also, I have created sha1 files... just append *.sha1 to the file name e.g.
http://www.pages.drexel.edu/~sag47/privacy_for_everyone.odt.sha1

For now I have removed the PDF since I have widely distributed the link to
the PDF so that people don't download it and receive misinformation.

The odt file remains.  I'm open to editing the document for clarity and
fact checking.  Once, an acceptable revised copy is well received on the
list then I'll recreate a PDF and upload it again.

SAM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140409/b7a44055/attachment-0001.html>