Dnscrypt question

[ajp2k14]

@Voxel
I'm seeing this when I start Dnscrypt, is something wrong?

Mon Nov 27 13:28:06 2017 [WARNING] This system doesn't provide enough entropy to quickly generate high-quality random numbers
Mon Nov 27 13:28:06 2017 [WARNING] Installing the rng-utils/rng-tools or haveged packages may help.
Mon Nov 27 13:28:06 2017 [WARNING] On virtualized Linux environments, also consider using virtio-rng.
Mon Nov 27 13:28:06 2017 [WARNING] The service will not start until enough entropy has been collected.
Mon Nov 27 13:28:06 2017 [INFO] + DNS Security Extensions are supported
Mon Nov 27 13:28:06 2017 [INFO] + Provider supposedly doesn't keep logs

 

[Voxel]

@Voxel
I'm seeing this when I start Dnscrypt, is something wrong?

Mon Nov 27 13:28:06 2017 [WARNING] This system doesn't provide enough entropy to quickly generate high-quality random numbers
Mon Nov 27 13:28:06 2017 [WARNING] Installing the rng-utils/rng-tools or haveged packages may help.
Mon Nov 27 13:28:06 2017 [WARNING] On virtualized Linux environments, also consider using virtio-rng.
Mon Nov 27 13:28:06 2017 [WARNING] The service will not start until enough entropy has been collected.
Mon Nov 27 13:28:06 2017 [INFO] + DNS Security Extensions are supported
Mon Nov 27 13:28:06 2017 [INFO] + Provider supposedly doesn't keep logs

It is warning. You may just ignore it. It is working, right?

Just dnscrypt-proxy requires not less than 160 level of entropy, it is changed (increased) fast enough. Maybe it will cause small delay in service startup.

You can check current level of entropy by command in console:

cat /proc/sys/kernel/random/entropy_avail

Try to run this command several time.

Voxel.

 

[ajp2k14]

Yes, it's working. I got confused by dnscrypt.eu-dk which isn't working for me and so I thought the warning had something to do with that but most other server seem to work.

Thanks for the helpful support as usual..

 

[sfx2000]

@Voxel - there was a great thread regarding entropy - one item was haveged, which does help out much once the machine is up and running.

 

[Voxel]

@Voxel - there was a great thread regarding entropy - one item was haveged, which does help out much once the machine is up and running.

This thread?

https://www.snbforums.com/threads/entropy-pool.34992/

OK, thank you. Maybe I'll add to my fw, but currently I am fighting with minimization of fw size. I was able to assemble Samba4, but its size is 15MB... Strange limitation set in stock fw for R7800: more than 25MB fw file is not accepted.

Voxel.

 

[sfx2000]

Yep, that's the thread - haveged is pretty small as a binary for ARM...

$ ll /usr/sbin/haveged
-rwxr-xr-x 1 root root 18232 Jul 17 06:31 /usr/sbin/haveged
​

Within a couple of seconds of a reboot, it fills the pool pretty fast...

$ cat /proc/sys/kernel/random/entropy_avail
2101​

 

[Voxel]

Yep, that's the thread - haveged is pretty small as a binary for ARM...

$ ll /usr/sbin/haveged
-rwxr-xr-x 1 root root 18232 Jul 17 06:31 /usr/sbin/haveged
​

Within a couple of seconds of a reboot, it fills the pool pretty fast...

$ cat /proc/sys/kernel/random/entropy_avail
2101​

But what about size of /usr/lib/libhavege.so.* ? ;-)

Voxel.

 

[sfx2000]

But what about size of /usr/lib/libhavege.so.* ? ;-)

Voxel.

Still pretty small - this is Cortex-A53...

/usr/lib/arm-linux-gnueabihf $ ll libhave*
lrwxrwxrwx 1 root root 18 Jul 17 06:31 libhavege.so.1 -> libhavege.so.1.1.0
-rw-r--r-- 1 root root 107948 Jul 17 06:31 libhavege.so.1.1.0​

Anyways, maybe use entware/optware, and build it there...

I can appreciate the efforts/concerns with Samba4 - haveged is low hanging fruit, and much of the work has already been done with positive results for devices that can benefit.

Keep in mind that entropy is used for more that just crypto. The challenge/risk with haveged perhaps is that's pseudorandom - and that also an acknowledged risk with any embedded device that starts from a fixed point in time - e.g. no RTC and having to sync to NTP or user interaction - so a small period of time where the seed is constant.

FWIW - my side project on RK3288 (ARM Cortex-A17)...

sfx@tinker:~$ ll /usr/sbin/haveged
-rwxr-xr-x 1 root root 14088 Jul 17 13:31 /usr/sbin/haveged
sfx@tinker:~$ ll /usr/lib/arm-linux-gnueabihf/libhave*
lrwxrwxrwx 1 root root 18 Jul 17 13:31 /usr/lib/arm-linux-gnueabihf/libhavege.so.1 -> libhavege.so.1.1.0
-rw-r--r-- 1 root root 91568 Jul 17 13:31 /usr/lib/arm-linux-gnueabihf/libhavege.so.1.1.0
​

 

[sfx2000]

@Voxel - if you want to test haveged - nice little stress test while watching entropy_avail... (keeping in mind that haveged dumps into urandom)

dd if=/dev/urandom of=1GB.img bs=512K count=2000​

and then gzip that file, and you'll find it's pretty much random - e.g. file size should be very close to the source file - which means, it's pretty random. Also this makes for a really nice test file to ensure that applications are not trying to game throughput via compression.

Be mindful that one never symlinks /dev/random to /dev/urandom with kernels these days - that's a bad idea...

 

[Voxel]

$ ll /usr/sbin/haveged
-rwxr-xr-x 1 root root 12831 Dec 1 10:44 /usr/sbin/haveged

$ ll /usr/lib/libhavege.so.1.1.0
-rwxr-xr-x 1 root root 90343 Dec 1 10:44 /usr/lib/libhavege.so.1.1.0

$ ps ax | grep haveged
1680 ? Ss 1:00 /usr/sbin/haveged -w 1024 -d 32 -i 32 -v 1

$ cat /proc/sys/kernel/random/entropy_avail
3679

It is from my current beta version. Thanks for you hint.

Voxel.

 

[sfx2000]

Cool... just in case folks are wondering why my paths are different - science project based on debian stretch... so full glibc, systemd, apt, etc... userland is all armhf as all processors supported are capable of armv7-a hardfloat operation.

● haveged.service - Entropy daemon using the HAVEGE algorithm
Loaded: loaded (/lib/systemd/system/haveged.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2017-12-02 07:00:56 UTC; 15h ago
Docs: man:haveged(8)
http://www.issihosts.com/haveged/
Main PID: 1380 (haveged)
CGroup: /system.slice/haveged.service
└─1380 /usr/sbin/haveged --Foreground --verbose=1 -w 1024

Dec 02 07:00:57 tinker haveged[1380]: haveged: ver: 1.9.1; arch: generic; vend: ; build: (gcc 6.3.0 CTV); collect: 128K
Dec 02 07:00:57 tinker haveged[1380]: haveged: cpu: (VC); data: 16K (D); inst: 16K (D); idx: 12/40; sz: 16108/62084
Dec 02 07:00:57 tinker haveged[1380]: haveged: tot tests(BA8): A:1/1 B:1/1 continuous tests(B): last entropy estimate 8.00367
Dec 02 07:00:57 tinker haveged[1380]: haveged: fills: 0, generated: 0

 

[Voxel]

Keep in mind that entropy is used for more that just crypto. The challenge/risk with haveged perhaps is that's pseudorandom - and that also an acknowledged risk with any embedded device that starts from a fixed point in time - e.g. no RTC and having to sync to NTP or user interaction - so a small period of time where the seed is constant.

You know, my main area of work in Computer Graphics, so I realize the importance of random numbers generations (used e.g. in MC ray tracing).

Voxel.