Re: GPGME

[Daiki Ueno]

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).

I remember that the problem of encrypt.el was that the data format is
not interoperable and the algorithm used is not interchangeable though
the API might be neutral.  I guess you need a minimal encryption
function which employs the standard GPG message format (RFC4880).

> 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?

If your statement in <address@hidden>:

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

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

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

  key1 val1 encrypted hexdata

where hexdata is decrypted to:

  key2 val2 key3 val3

Regards,
-- 
Daiki Ueno