encrypt file in batch mode
wk at gnupg.org
Tue Nov 5 08:57:23 CET 2019
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.
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 227 bytes
Desc: not available
More information about the Gnupg-users