Looking for GnuPG-compatible library for server application
Bernd R. Fix
bernd at wauland.de
Sun Oct 21 01:16:14 CEST 2012
-----BEGIN PGP SIGNED MESSAGE-----
Am 20.10.2012 23:31, schrieb Nicholas Cole:
>> But to be honest: I am not sure if gpg2 (with the mandatory
>> gpg-agent instance to handle private keys) is suitable at all for a
>> server environment where there are some 20'000 *private* keys (and
>> counting). - From our experience gpg2 does not scale well with
>> increasing number of private keys (although I have to admit that
>> the project uses a very early GnuPG-2.1 implementation and not the
>> latest from the unstable branch).
> Pure curiosity on my part, I'll freely confess. But what sort of
> application requires a server to handle 20,000 private keys?
It is a kind of "closed user group social network" application where all
exchanged and stored information needs to be encrypted and is only
visible within a group of users.
The application was designed last year somewhat in a haste and had to be
online within three month, so some design decisions were guided by that
timeframe and not by "best pracice"; for example encryption takes place
on the web server and not in the client's browser (a design decision
that will hopefully be revised somewhen in the future - but for now we
have to deal with it the way it is).
Although the keys are stored on the server, access to the private keys
is only possible with a passphrase supplied by the client - as promised
the server application does not store or log passphrases (something the
user has to believe the project, even when the appication source code
will be available as open-source soon).
> Would there be any way to sensibly generate different keyrings, so
> that gpg2 only ever had to deal with smaller groups of keys?
Since the predecessor of the current GnuPG-2.1 still used a single
secure keyring file to store keys (which does not scale at all!), the
server application already splits that up for operations involving the
private key (each key has its own keyring actually, stored in a
hierachical directory structure) and ignores the associated trustdb
completely on all operations.
Postfach 65 04 43 H O L L A N D
22364 Hamburg/Germany S T I F T U N G
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the Gnupg-devel