Need non-writable --homedir

[Josef Wolf]

On Mon, Sep 11, 2006 at 03:27:59PM -0500, Robert J. Hansen wrote:
> Josef Wolf wrote:

> 1.  /dev/random isn't available on all platforms.  GnuPG's random number
>     generator is.

Don't most unices have /dev/random nowadays?  I never planned to run this
thing on a windows box :)

> 2.  /dev/random is exhaustible.  This is a Bad And Wrong for crypto
>     applications.

Hmm, the only drawback I see is a slowdown.  The application will just
hang and wait for more entropy to arrive.  But I don't see how security
would be compromised by emptying /dev/random.  Or will gpg fall back
to something bad in such a situation?  Would it be better to have a
random_seed lying around there?  Isn't it better to be slow than
unsecure?

How many random data does gpg consume when encrypting?

> 3.  /dev/random is, as I understand it, an ad-hoc design.  Many people
> who need crypto software need vetted, certified designs (even if the
> software itself isn't certified).  E.g., some people may require ANSI
> X9.17 RNG.  With a software RNG, it's fairly easy to just drop in
> whatever RNG you need.

Ough... I always thought /dev/random has the highest possible quality.
How can a RNG be more random than real entropy?

> > Does --no-random-seed-file force /dev/random to be used?
> 
> Platform-dependent.  Obviously, --no-random-seed-file won't force
> /dev/random to be used if you're on a system that has no /dev/random
> (e.g., Win32).  You need to tell us the precise system environment
> before we can really answer these kinds of questions.

Sorry, forgot that.  It is supposed to run on linux.

> > sendbackup runs gnutar as root and gpg as backupclient.  To make sure
> >  that backupserver at server is not able to request unencrypted data, I 
> > need to make sure that backupclient is not able to modify the 
> > keyring.
> 
> I'm having a cognitive disconnect here.  How does the _client's_
> inability to modify the keyring affect the _server's_ ability to request
> unencrypted data?

The server has shell access via ssh to backupclient at client.  He can
create its own keyring and replace the one on client's account.  The
requested backup is encrypted with backupserver's key now.  The attack
is similar to a MITM attack.  This is why I want the keyring be modifiable
only by root at client.

Basically, I want the setup to be secure even if backupclient's account
should be compromised.  I think this strategy will not do any harm.