encrypt file in batch mode

[Werner Koch]

On Mon,  4 Nov 2019 18:10, Tony Lane said:

> was made with the unix philosophy in mind. Perhaps it would've been
> better to write the gpg-agent as a shared library to be called by the
> core instead. Well, we're probably too far down down the rabbit hole

The process boundary has security advantages and is one of the reasons
why this is not just a shared library.  Or why gpg is not a shared
library itself.  By splitting GnuPG into an OpenPGP part (gpg) and a
private key handling part (gpg-agent) we have a couple of benefits:

- We reduce the amount of code and of linked other shared libraries which
  come in touch with the sensitive private key material.
- The gpg-agent does not need to care about the complicated OpenPGP
  protocol (or gpgsm not about the more complicated CMS/X.509 protocol).
- No user interface required.
- Exploitable bugs in gpg must not immediately compromise private keys.
- We can can store/cache data in memory and do not need to load and
  process it each time.  A shared library won't allow this.  The cache
  is even encrypted so that we could extend it to store that encryption
  key in some kind of secure element to limit the expose of that key and
  thus the cache.
- Auditing the code and reasoning about the operation it is much easier
  given the well defined interface between the modules.
- Using SELinux or similar systems allows to run the gpg-agent in a mode
  where only gpg-agent may access the files storing the private keys.
- The gpg-agent could be run under a different uid and this way take
  advantage of the even stronger uid separation of most OSes.
- The gpg-agent can be run on an entirely different machine and thus
  work similar to a HSM.


Shalom-Salam,

   Werner

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20191105/421147b0/attachment.sig>