help-gnutls
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-gnutls] Alternate random device for certtool


From: Teran McKinney
Subject: Re: [Help-gnutls] Alternate random device for certtool
Date: Thu, 27 Nov 2008 18:02:05 +0000

Thanks for getting back to me.

I previously checked which random device it was using with strace, but
have done a couple additional tests since.

sega01[~]$ time strace certtool -p --outfile /dev/null 2>&1 | grep random
access("/dev/random", R_OK)             = 0
access("/dev/urandom", R_OK)            = 0
open("/dev/urandom", O_RDONLY)          = 4
open("/dev/random", O_RDONLY)           = 5

real    0m32.772s
user    0m0.234s
sys     0m0.011s

It opens urandom, but opens random afterwards and times out if it
cannot get enough data from it. ie:
select(6, [5], NULL, NULL, {3, 0})      = 0 (Timeout)

I ssh into the systems that I would need to do this on, and most are
headless. I noticed how easy it was to generate data for /dev/random
by moving the mouse, but without it generating entropy is much more
difficult. Grepping strace for random with the --disable-quick-random
flag on gives the same two access lines and two open lines for the
random devices, as well as the text about "This may take several
minutes" which only comes up when that flag is used. I can also get
the same speeds when using and not using the flag (with a consistent
level of mouse-induced entropy), so I am quite sure that it is
gathering most of the data from /dev/random instead of /dev/urandom.

Perhaps Debian uses a patch for certtool?

Thanks,
Teran (sega01)

PS: I have checked this with two different distributions, though one
is a fork of the other (however it is quite different and completely
rebuilt). I have the same effect on both.

On Thu, Nov 27, 2008 at 17:27, Daniel Kahn Gillmor
<address@hidden> wrote:
> On Wed 2008-11-26 19:04:52 -0500, Teran McKinney wrote:
>
>> I am using Gnutls 2.6.2, but have had no luck generating certificates
>> with certtool. I found that it uses /dev/random instead of
>> /dev/urandom
>
> How are you determining that it uses /dev/random?
>
> I'm using gnutls 2.6.2 from debian's experimental repository, and it
> seems to be pulling from /dev/urandom unless i pass it the
> --disable-quick-random flag.  It does apparently check to make sure
> that /dev/random is readable, but it doesn't open the file unless it
> needs to:
>
> address@hidden:~$ time strace certtool -p --outfile /dev/null 2>&1 | grep 
> random
> access("/dev/random", R_OK)             = 0
> access("/dev/urandom", R_OK)            = 0
> open("/dev/urandom", O_RDONLY)          = 4
>
> real    0m5.453s
> user    0m5.284s
> sys     0m0.020s
> address@hidden:~$ time strace certtool -p --disable-quick-random --outfile 
> /dev/null 2>&1 | grep random
> execve("/usr/bin/certtool", ["certtool", "-p", "--disable-quick-random", 
> "--outfile", "/dev/null"], [/* 15 vars */]) = 0
> access("/dev/random", R_OK)             = 0
> access("/dev/urandom", R_OK)            = 0
> open("/dev/urandom", O_RDONLY)          = 4
> write(2, "This might take several minutes d"..., 88This might take several 
> minutes depending on availability of randomness in /dev/random.
> open("/dev/random", O_RDONLY)           = 5
>
> real    1m5.935s
> user    0m4.668s
> sys     0m0.036s
> address@hidden:~$ dpkg -l gnutls-bin libgnutls26
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: 
> uppercase=bad)
> ||/ Name           Version        Description
> +++-==============-==============-============================================
> ii  gnutls-bin     2.6.2-1        the GNU TLS library - commandline utilities
> ii  libgnutls26    2.6.2-1        the GNU TLS library - runtime library
> address@hidden:~$
>
>           --dkg
>
> _______________________________________________
> Help-gnutls mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/help-gnutls
>
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]