Re: pgg symmetric encryption patch

[Ken Manheimer <ken.manheimer@gmail.com>]

i'm attempting to incorporate sascha's modified pgg in allout, instead
of using a combination of mailcrypt and crypt++, and encountering some
serious problems.  the problems include some fundamental problems with
pgg operation, independent of the patch, that are show-stoppers for
me.  i'd like to run my assessment of these things by you all and see
if you can help me understand them.  it's possible i'm mistaken about
some, i don't understand what appear to be the choices made.

all of my experiments involve the current pgg code found in the
gnu.org lisp/gnus CVS.  some of them (i'll try to be clear about
which) involve this pgg code with sascha's most recent symmetric-key
extensions patch (emacs-pgg-symmetric.patch-03) applied (by hand -
couldn't get it to work using 'patch').

1. my most serious concern is with the unpatched pgg code.  the text that
   it encrypts is altered from the original, in order to append \r carriage
   returns to the text (using pgg-as-lbt / pgg-convert-lbt).

   the problem with this is that decryption on unix-ish platforms with
   anything other than pgg will result in text that is different than the
   original.  for example, text that is encrypted with pgg-gpg and then
   decrypted directly using the gpg program (using the command-line, for
   instance) will be distorted in this way.  likewise if decrypted using
   mailcrypt in emacs, or pgp5 or pgp in any way, etc.

   this is not acceptable for my purposes (and i can't figure out where it
   would be acceptable, but i'm not familiar with the encryption concerns
   for message exchange, eg for email or news).

2. i also have some fundamental problems with the way unaltered pgg's
   passphrase caching system is wired.  i am not sure about my analysis,
   and would love to be corrected, and filled in about how it actually does
   work.  (the passphrase cache routines could really use some informative
   docstrings.)

   as far as i can tell, on decryption it keys on the value of
   pgg-default-user-id, rather than the actual recipients of the message.
   this is generally useless for any messages but those encrypted with the
   user's public-key.  and it depends on the user having set
   pgg-default-user-id, which seems like an unnecessary and complicating
   limitation.

3. this key caching problem of #2 is compounded in the context of sascha's
   patches, because i really can't figure what the right thing is.  plus,
   it's not hooked up quite right in the patches:

  - the patched version will use the prompt for the symmetric key even when
    doing a public-key decryption.

  - pgg-gpp-encrypt-symmetric-region does not do do any key caching.  this
    is the right thing modulo the pgg-default-user-id misorientation of the
    caching mechanism - but is unacceptable for my purposes, where users
    can particularly need the convenience of key caching for symmetric-key
    operation, in order to encrypt and decrypt multiple entries.

4. in the patched version, the symmetric encryption does not replace the
   original text with the encrypted text - it's only available in the
   hidden " *PGG output*" buffer, but not put in place.

5. last, another small problem with the unaltered pgg code.

   i stumbled and was confused when pgg failed to do a public-key
   encryption due to the default value of pgg-default-user-id.  only on
   reading the code did i learn i needed to set pgg-default-user-id to the
   identity of my primary key.  it may be that i should use my user login
   for that key's identity, so the default would work, i dunno.

it took me a while to unravel these problems, and i stopped at that
point - i don't think i can use pgg, as it stands, according to this
assessment.  i don't understand the reasons for the choices - maybe
just because i'm unfamiliar with the regular context where it's used. 
i may be mistaken about my assessment in some of these items, and
would welcome correction and/or clarification!

ken manheimer
ken.manheimer@gmail.com