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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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. _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
