Re: odd /dev/random behavior with dd ?

[Havard Eidnes]

> Hi, 'dd' seems to behave different if the 'if' is /dev/random
> than if it is anything else, e.g. /dev/zero:
> 
> # sh
> # dd if=/dev/zero of=zero.out bs=65536 count=1
> 1+0 records in
> 1+0 records out
> 65536 bytes transferred in 0.001 secs (65536000 bytes/sec)

rnd(4) says:

 Applications should read from /dev/urandom, or the sysctl(7) variable
 kern.arandom, when they need randomly generated data, e.g. key material
 for cryptography or seeds for simulations.  (The sysctl(7) variable
 kern.arandom is limited to 256 bytes per read, but is otherwise
 equivalent to reading from /dev/urandom and always works even in a
 chroot(8) environment without requiring a populated /dev tree and without
 opening a file descriptor, so kern.arandom may be preferable to use in
 libraries.)

I guess the behaviour of kern.arandom is also enforced for
/dev/random.  "Whoever needs more than 256 bits to seed their
crypto algorithm?"

/dev/urandom does not, and as long as the rnd subsystem is
initialized, it should be equivalent to /dev/random if I
understand correctly.

Regards,

- Håvard

odd /dev/random behavior with dd ?

[Michael Cheponis]

Hi, 'dd' seems to behave different if the 'if' is /dev/random than if it is
anything else, e.g. /dev/zero:



























*# sh # dd if=/dev/zero of=zero.out bs=65536 count=11+0 records in1+0
records out65536 bytes transferred in 0.001 secs (65536000 bytes/sec)# ls
-l zero.out-rw-r--r--  1 root  wheel  65536 Jan  4 21:30 zero.out# dd
if=/dev/random of=random.out bs=65536 count=10+1 records in0+1 records
out32 bytes transferred in 0.001 secs (32000 bytes/sec)# ls -l
random.out-rw-r--r--  1 root  wheel  32 Jan  4 21:30 random.out# dd
if=/dev/random of=random.out.2 bs=65536 count=20480+2048 records in0+2048
records out65536 bytes transferred in 0.054 secs (1213629 bytes/sec)# ls -l
random.out.2-rw-r--r--  1 root  wheel  65536 Jan  4 21:31 random.out.2#
uname -aNetBSD arm64 9.99.102 NetBSD 9.99.102 (MIKE64) #0: Wed Oct 26
22:54:20 UTC 2022  mac@arm64:/usr/obj/sys/arch/evbarm/compile/MIKE64 evbarm*



Am I doing something stupid?

Thanks!
Mike