Re: GPGME

[Ted Zlatanov]

On Wed, 29 Jun 2011 05:36:02 +0900 Daiki Ueno <address@hidden> wrote: 

DU> Ted Zlatanov <address@hidden> writes:
>> Are there any alternatives?  Maybe you remember our discussion years ago
>> about encrypt.el, where I proposed a neutral API with at least some
>> symmetric ciphers implemented in ELisp and C in the Emacs core
>> (essentially what Lars was requesting).

DU> I remember that the problem of encrypt.el was that the data format is
DU> not interoperable and the algorithm used is not interchangeable though
DU> the API might be neutral.

Is that a problem, if the intent is to provide an Emacs facility?

DU> I guess you need a minimal encryption function which employs the
DU> standard GPG message format (RFC4880).

I'm not sure that would benefit any Emacs users since EPA/EPG already
provide so much functionality for this and the GPG message format
doesn't seem to have any obvious benefits for simple data encryption.

>> Could something like that work
>> within the EPA/EPG structure, so some special invocation of
>> `epg-encrypt-string' could bypass the external callout to GPG?

DU> If your statement in <address@hidden>:

DU>   The decoding will happen late, probably in the funcall to obtain the
DU>   secret (and it will set some scoped variables to cache the data)

DU> is true, epg-encrypt-string is not necessarily to be optimized in that
DU> way, I think.  How about implementing your side first and profiling
DU> before the optimization?

That's not a performance optimization.  We decode late to avoid
prompting the user for a passphrase before the password is actually
needed.

I'm asking if, instead of a new package, we can use `epg-encrypt-string'
to provide symmetric encryption without calling GPG externally.  It can
provide it in any format and with any symmetric cipher you think would
make sense.  But if you don't think so, then we need a new package to
provide that functionality.

DU> One suggestion to reduce the number of calls to epg-encrypt-string is
DU> that, I would suggest encrypt the key name as well.  For example,

DU>   key1 val1 encrypted hexdata

DU> where hexdata is decrypted to:

DU>   key2 val2 key3 val3

But if we do that, we have to decrypt the hexdata in order to know it
has key2 and key3.  The benefit of the GPG tokens for netrc field
encryption is that you know all the keys, so you can search for "must
have key X" with confidence, without prompting the user, and without
extra decryption overhead at search time.  Obviosly if you search for
"must have key X with value Y" that doesn't work, but typically we don't
encrypt things that we search for.  Right now we only encrypt the
password in any case.

Ted