Mailing List Archive

On Sat, 29 Nov 2008 09:21, nmav@gnutls.org said:

> I CC to gcrypt-devel since this might be gcrypt related.
> Could it be that newer versions from 1.4.1 ignore the control:
> gcry_control (GCRYCTL_ENABLE_QUICK_RANDOM, 0);

Can you please send me the example code?


Salam-Shalom,

Werner


--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Just verified that I do not have this issue when I use libgcrypt
1.4.1. 1.4.2 also seems to have this problem.

Thanks,
Teran

On Tue, Dec 2, 2008 at 17:47, Werner Koch <wk@gnupg.org> wrote:
> On Sat, 29 Nov 2008 09:21, nmav@gnutls.org said:
>
>> I CC to gcrypt-devel since this might be gcrypt related.
>> Could it be that newer versions from 1.4.1 ignore the control:
>> gcry_control (GCRYCTL_ENABLE_QUICK_RANDOM, 0);
>
> Can you please send me the example code?
>
>
> Salam-Shalom,
>
> Werner
>
>
> --
> Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
>
>

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Werner Koch wrote:
> On Sat, 29 Nov 2008 09:21, nmav@gnutls.org said:
>
>> I CC to gcrypt-devel since this might be gcrypt related.
>> Could it be that newer versions from 1.4.1 ignore the control:
>> gcry_control (GCRYCTL_ENABLE_QUICK_RANDOM, 0);
>
> Can you please send me the example code?

It it the certtool program from gnutls (src/certtool.c) the
generate_private_key function. This after all calls:
pk-libgcrypt.c: _rsa_generate_params (bigint_t * resarr, int
*resarr_len, int bits)

gcry_sexp_build (&parms, NULL, "(genkey(rsa(nbits %d)))", bits);
gcry_pk_genkey (&key, parms);

regards,
Nikos

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Sat, 29 Nov 2008 09:21, nmav@gnutls.org said:

> I upgraded to gcrypt 1.4.4 and I notice the same delay, and strace shows
> that /dev/random is being used even with this flag.

What you do in certtool is to call

if (info.quick_random != 0)
gcry_control (GCRYCTL_ENABLE_QUICK_RANDOM, 0);

very early. In fact as the first call to libgcrypt. At that point the
library is not initialixed and thus it has not checked whether it is in
FIPS mode; thus the default is used which is the more restrictive FIPS
mode:

/* This may be called before full initialization to degrade the
quality of the RNG for the sake of a faster running test suite. */
void
_gcry_enable_quick_random_gen (void)
{
if (fips_mode ())
; /* Not used. */
else
_gcry_rngcsprng_enable_quick_gen ();
}

As you see the flag can't be set in this case. What you need to do is
to set this flag during initialization: That is after a first call to
gcry_check_version. This is how it is done in by libgcrypt regression
tests.

Anyway, using this flag is strongly discouraged. It is only useful for
testing. gpg for example refuse to use a key if the random number
generator is in this mode and the User ID of the key is not flagged as
insecure. That is a bit paranoid but older version of libgcrypt even
did not used a strong RNG in the quick mode.

If you want to use not so strong keys, you better use the transient-key
feature available since 1.4.2:

@item transient-key
This is only meaningful for RSA keys. This is a flag with no value. If
given the RSA key is created using a faster and a somewhat less secure
random number generator. This flag may be used for keys which are only
used for a short time and do not require full cryptographic strength.

Usage example:

err = gcry_sexp_build (&key_spec, NULL,
gcry_fips_mode_active ()
? "(genkey (RSA (nbits %d)))"
: "(genkey (RSA (nbits %d)(transient-key)))",
p_sizes[testno]);

You may use that even with older Libgcrypt versions, however it is
ignored then. The fips mode test is required because this flag is
refused by gcry_pk_genkey in fips mode.


Shalom-Salam,

Werner


--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Werner Koch wrote:
> On Sat, 29 Nov 2008 09:21, nmav@gnutls.org said:
>
>> I upgraded to gcrypt 1.4.4 and I notice the same delay, and strace shows
>> that /dev/random is being used even with this flag.
>
> What you do in certtool is to call
>
> if (info.quick_random != 0)
> gcry_control (GCRYCTL_ENABLE_QUICK_RANDOM, 0);
[...]
> you see the flag can't be set in this case. What you need to do is
> to set this flag during initialization: That is after a first call to
> gcry_check_version. This is how it is done in by libgcrypt regression
> tests.
> Anyway, using this flag is strongly discouraged. It is only useful for
> testing. gpg for example refuse to use a key if the random number
> generator is in this mode and the User ID of the key is not flagged as
> insecure. That is a bit paranoid but older version of libgcrypt even
> did not used a strong RNG in the quick mode.

Why is this? As far as I understand the only difference was that it uses
/dev/urandom instead of /dev/random.

> If you want to use not so strong keys, you better use the transient-key
> feature available since 1.4.2:
>
> @item transient-key
> This is only meaningful for RSA keys. This is a flag with no value. If
> given the RSA key is created using a faster and a somewhat less secure
> random number generator. This flag may be used for keys which are only
> used for a short time and do not require full cryptographic strength.

Is this stronger than using /dev/urandom?


regards,
Nikos



_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Thu, 4 Dec 2008 19:52, nmav@gnutls.org said:

>> gcry_control (GCRYCTL_ENABLE_QUICK_RANDOM, 0);

> Why is this? As far as I understand the only difference was that it uses
> /dev/urandom instead of /dev/random.

Because this has always been the case. QUICK_RANDOM was and is just a
testing hack.

>> @item transient-key

> Is this stronger than using /dev/urandom?

It is not a matter of being stronger but of being a feature.
transient-key is suposed to be used for one-off keys and other keys
which are not that valuable. In general it is always better to use the
defaults for generating a key; see onl the recent BSD problems with
their RNG. This would not have been the case with a blocking one.


Shalom-Salam,

Werner


--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Werner Koch wrote:

>>> gcry_control (GCRYCTL_ENABLE_QUICK_RANDOM, 0);
>
>> Why is this? As far as I understand the only difference was that it uses
>> /dev/urandom instead of /dev/random.
>
> Because this has always been the case. QUICK_RANDOM was and is just a
> testing hack.

I don't understand. The issue for certtool that was reported was that it
was blocking in /dev/random and taking a lot of time to produce any
output. This was the reason I've put QUICK_RANDOM there.

>>> @item transient-key
>
>> Is this stronger than using /dev/urandom?
>
> It is not a matter of being stronger but of being a feature.
> transient-key is suposed to be used for one-off keys and other keys
> which are not that valuable.


> In general it is always better to use the
> defaults for generating a key; see onl the recent BSD problems with
> their RNG. This would not have been the case with a blocking one.

I don't think so. Block for indefinite time (can be even hours) does not
offer anything unless you can wait. If you want to generate keys and you
don't care if this will be today or tomorrow it's ok. In all other cases
you will not use this rng, it is broken by design[0].


regards,
Nikos

[0]. Also being blocking does not protect from being a bad algorithm. As
far as I know there are known issues to the blocking linux rng (were
discussed some years ago in gnutls-dev) and they still cannot gather any
entropy from network devices because its state can be compromised!

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Fri, 5 Dec 2008 08:17, nmav@gnutls.org said:

> I don't understand. The issue for certtool that was reported was that it
> was blocking in /dev/random and taking a lot of time to produce any
> output. This was the reason I've put QUICK_RANDOM there.

Right, it is blocking because it needs to generate random numbers and do
do this we need to gather entropy from physical sources. If the
bandwidth of these sources is that small it just takes a long time. If
the box is idle it may even not finish at all. Recall that a computer
is a deterministic machine and that it is hard to extract unpredictable
events from a deterministic machines (actually impossible, but
fortunately a general purpose computer is not completely deterministic.)

Ask the user to work on the box to give it a chnace to collect entroy.
For example "find /usr -type f | xargs cat >/dev/null" gets the disk to
work and thus floods the box with interrupts.

> I don't think so. Block for indefinite time (can be even hours) does not
> offer anything unless you can wait. If you want to generate keys and you

I disagree: If you want a secure key, you need to invest something, be
it time to wait for sporadic interrupts, keep on working on the box or
even install a hardware RNG.

> [0]. Also being blocking does not protect from being a bad algorithm. As
> far as I know there are known issues to the blocking linux rng (were
> discussed some years ago in gnutls-dev) and they still cannot gather any
> entropy from network devices because its state can be compromised!

And thus your solution is to give up on it and use a a deterministc
source like /dev/urandom? If /dev/random blocks, /dev/urandom will only
return a sequence of bytes which is predictable if you know the initial
state of the RNG.

It al depends on what you want. The default for Libgcrypt is to make
sure that there is really strong random available for key generation and
to do with a not so strong (read /dev/urandom) for session keys etc. If
you don't want that (transient-key) gives you a way to degrade random
quality for key generation.


Salam-Shalom,

Werner


--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Fri, Dec 05, 2008 at 09:13:24AM +0100, Werner Koch wrote:
> It al depends on what you want. The default for Libgcrypt is to make
> sure that there is really strong random available for key generation and
> to do with a not so strong (read /dev/urandom) for session keys etc. If
> you don't want that (transient-key) gives you a way to degrade random
> quality for key generation.

It's my understanding that (transient-key) only works for RSA. Can it
be made to work for DSA as well? We hit this problem in libotr.

Thanks,

- Ian

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Fri, 5 Dec 2008 14:14, linux@paip.net said:

> It's my understanding that (transient-key) only works for RSA. Can it
> be made to work for DSA as well? We hit this problem in libotr.

Done. SVN trunk revision 1371; will go into 1.4.4. Sample code:

rc = gcry_sexp_new (&key_spec,
transient_key
? "(genkey (dsa (nbits 4:1024)(transient-key)))"
: "(genkey (dsa (nbits 4:1024)))",
0, 1);



Shalom-Salam,

Werner

--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Werner Koch wrote:

>> I don't understand. The issue for certtool that was reported was that it
>> was blocking in /dev/random and taking a lot of time to produce any
>> output. This was the reason I've put QUICK_RANDOM there.
> Right, it is blocking because it needs to generate random numbers and do
> do this we need to gather entropy from physical sources. If the
> bandwidth of these sources is that small it just takes a long time. If
> the box is idle it may even not finish at all. Recall that a computer
> is a deterministic machine and that it is hard to extract unpredictable
> events from a deterministic machines (actually impossible, but
> fortunately a general purpose computer is not completely deterministic.)

There are many parts in a typical PC that can feed a prng with
non-deterministic data. Typical examples are the network card and sound
card (mic etc), hard disks, memory accesses, interrupts, thermal sensors
etc. Those provide lots of information that can feed a prng even on
unattended system.

There are two problems with the linux prng:
1. It needs to block when it thinks it does not have enough randomness
2. It does not use all available random data sources because its state
could be compromised by a malicious or broken source.

Fortuna [0] is a suitable PRNG replacement, because it has none of these
issues. It can work even with some sources being malicious and will use
a block cipher to produce large series of data without compromising or
its state.

[0]. http://en.wikipedia.org/wiki/Fortuna_(PRNG)

> Ask the user to work on the box to give it a chnace to collect entroy.
> For example "find /usr -type f | xargs cat >/dev/null" gets the disk to
> work and thus floods the box with interrupts.

The problem is that programs should be able to run both interactive and
not.

Moreover the blocking interface makes it's easy to prevent someone from
creating a key... Just cat /dev/random, or open many tcp connections to
a linux host.

>> [0]. Also being blocking does not protect from being a bad algorithm. As
>> far as I know there are known issues to the blocking linux rng (were
>> discussed some years ago in gnutls-dev) and they still cannot gather any
>> entropy from network devices because its state can be compromised!
> And thus your solution is to give up on it and use a a deterministc
> source like /dev/urandom? If /dev/random blocks, /dev/urandom will only
> return a sequence of bytes which is predictable if you know the initial
> state of the RNG.

/dev/urandom is not deterministic it just has worse PR.
/dev/random is the SAME as /dev/urandom with the exception that it
blocks when it THINKS randomness gathered is not enough. If it thinks
wrong (like when I control one source of randomness) it exactly the same
as /dev/urandom.


regards,
Nikos

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Fri, 5 Dec 2008 21:06, nmav@gnutls.org said:

> There are many parts in a typical PC that can feed a prng with
> non-deterministic data. Typical examples are the network card and sound

Please read Peter's papers on this subject. In particular, network
traffic does not yield any usable entropy.

> 1. It needs to block when it thinks it does not have enough randomness

Right, that is the correct behaviour. Actually I believe that current
linux even estimates a too high entropy.

> 2. It does not use all available random data sources because its state
> could be compromised by a malicious or broken source.

Currect behaviour.

> Fortuna [0] is a suitable PRNG replacement, because it has none of these

Well, as you say, this is a PRNG. It needs to be seeded. And the seed
is the most problematic part. Almost all evaluations are handwaving the
problem. The use of a continuously seeded PRNG is a pragmatical
solution towards these problems. IIRC, NIST's special publication
800-90 suggest to re-seed a PRNG as ofthe as possible. FIPS 140-2
allows and suggest for re-seeded. For a real entropy source you need a
*reliable* hardware entropy source.

> Moreover the blocking interface makes it's easy to prevent someone from
> creating a key... Just cat /dev/random, or open many tcp connections to
> a linux host.

So what? You are under attack and you still want to create a key on
that attcked box?

> /dev/urandom is not deterministic it just has worse PR.
> /dev/random is the SAME as /dev/urandom with the exception that it
> blocks when it THINKS randomness gathered is not enough. If it thinks

That is simply not true. Read the 2006 paper by Gutterman, Pinkas and
Reinman on the Linux RNG.

Yes, I have a pretty conservative POV on entropy gathering.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel