/dev/random: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen VersionsunterschiedZum nächsten Versionsunterschied →
VisuellWikitext
Zeile 92: Zeile 92:
= Wikipedia EN =
= Wikipedia EN =
[[File:Hexdump of dev urandom.png|upright=1.5|thumb|256 byte hex dump of /dev/urandom]]{{Short description|Pseudorandom number generator file in Unix-like operating systems}}
[[File:Hexdump of dev urandom.png|upright=1.5|thumb|256 byte hex dump of /dev/urandom]]{{Short description|Pseudorandom number generator file in Unix-like operating systems}}
In [[Unix-like]] [[operating system]]s, '''{{mono|/dev/random}}''' and '''{{mono|/dev/urandom}}''' are [[special file]]s that serve as [[cryptographically secure pseudorandom number generator]]s. They allow access to environmental noise collected from [[device driver]]s and other sources.<ref>{{cite web
In [[Unix-like]] [[operating system]]s, '''{{mono|/dev/random}}''' and '''{{mono|/dev/urandom}}''' are [[special file]]s that serve as [[cryptographically secure pseudorandom number generator]]s.  
* They allow access to environmental noise collected from [[device driver]]s and other sources.<ref>{{cite web
| url=https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/char/random.c?id=refs/tags/v3.15.6#n52
| url=https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/char/random.c?id=refs/tags/v3.15.6#n52
| title=Linux Kernel drivers/char/random.c comment documentation @ 1da177e4
| title=Linux Kernel drivers/char/random.c comment documentation @ 1da177e4
Zeile 98: Zeile 99:
| date=2005-04-16
| date=2005-04-16
| access-date=2014-07-22
| access-date=2014-07-22
}}</ref>  {{mono|/dev/random}} typically [[Blocking (computing)|blocked]] if there was less [[Entropy (computing)|entropy]] available than requested; more recently (see below for the differences between operating systems) it usually blocks at startup until sufficient entropy has been gathered, then unblocks permanently. The {{mono|/dev/urandom}} device typically was never a blocking device, even if the pseudorandom number generator seed was not fully initialized with entropy since boot. Not all operating systems implement the same methods for {{mono|/dev/random}} and {{mono|/dev/urandom}}.
}}</ref>  {{mono|/dev/random}} typically [[Blocking (computing)|blocked]] if there was less [[Entropy (computing)|entropy]] available than requested; more recently (see below for the differences between operating systems) it usually blocks at startup until sufficient entropy has been gathered, then unblocks permanently.  
* The {{mono|/dev/urandom}} device typically was never a blocking device, even if the pseudorandom number generator seed was not fully initialized with entropy since boot.  
* Not all operating systems implement the same methods for {{mono|/dev/random}} and {{mono|/dev/urandom}}.


== Linux ==
== Linux ==
Zeile 119: Zeile 122:
  |url-status    = live
  |url-status    = live
}}</ref>
}}</ref>
The implementation used [[cryptographic hash function|secure hashes]] rather than [[cipher]]s,{{clarify|date=February 2017}} to avoid [[export of cryptography|cryptography export restrictions]] that were in place when the generator was originally designed. The implementation was also designed with the assumption that any given hash or cipher might eventually be found to be weak, and so the design is durable in the face of any such weaknesses. Fast recovery from [[Entropy pool|pool compromise]] is not considered a requirement, because the requirements for pool compromise are sufficient for much easier and more direct attacks on unrelated parts of the operating system.
The implementation used [[cryptographic hash function|secure hashes]] rather than [[cipher]]s,{{clarify|date=February 2017}} to avoid [[export of cryptography|cryptography export restrictions]] that were in place when the generator was originally designed.  
* The implementation was also designed with the assumption that any given hash or cipher might eventually be found to be weak, and so the design is durable in the face of any such weaknesses.  
* Fast recovery from [[Entropy pool|pool compromise]] is not considered a requirement, because the requirements for pool compromise are sufficient for much easier and more direct attacks on unrelated parts of the operating system.


In Ts'o's implementation, the generator keeps an estimate of the number of [[bit]]s of noise in the [[entropy pool]]. From this entropy pool random numbers are created. When read, the {{mono|/dev/random}} device will only return random bytes within the estimated number of bits of noise in the entropy pool.  When the entropy pool is empty, reads from {{mono|/dev/random}} will [[Asynchronous I/O|block]] until additional environmental noise is gathered.<ref name="linux-man-page">{{man|4|random|Linux}}</ref> The intent is to serve as a [[cryptographically secure pseudorandom number generator]], delivering output with entropy as large as possible. This is suggested by the authors for use in generating cryptographic keys for high-value or long-term protection.<ref name="linux-man-page" />
In Ts'o's implementation, the generator keeps an estimate of the number of [[bit]]s of noise in the [[entropy pool]].  
* From this entropy pool random numbers are created.  
* When read, the {{mono|/dev/random}} device will only return random bytes within the estimated number of bits of noise in the entropy pool.  When the entropy pool is empty, reads from {{mono|/dev/random}} will [[Asynchronous I/O|block]] until additional environmental noise is gathered.<ref name="linux-man-page">{{man|4|random|Linux}}</ref> The intent is to serve as a [[cryptographically secure pseudorandom number generator]], delivering output with entropy as large as possible.  
* This is suggested by the authors for use in generating cryptographic keys for high-value or long-term protection.<ref name="linux-man-page" />


A counterpart to {{mono|/dev/random}} is {{mono|/dev/urandom}} ("unlimited"<ref>{{cite web | url=http://repo.or.cz/w/davej-history.git/blob/d0562c8dc:/drivers/char/random.c#l682
A counterpart to {{mono|/dev/random}} is {{mono|/dev/urandom}} ("unlimited"<ref>{{cite web | url=http://repo.or.cz/w/davej-history.git/blob/d0562c8dc:/drivers/char/random.c#l682
| title=/dev/random and /dev/urandom implementation in Linux 1.3.39, function <code>random_read_unlimited</code>
| title=/dev/random and /dev/urandom implementation in Linux 1.3.39, function <code>random_read_unlimited</code>
| date=1995-11-04
| date=1995-11-04
| access-date=2013-11-21}}</ref>/non-blocking random source<ref name="linux-man-page" />) which reuses the internal pool to produce more pseudo-random bits. This means that the call will not block, but the output may contain less entropy than the corresponding read from {{mono|/dev/random}}. While {{mono|/dev/urandom}} is still intended as a pseudorandom number generator suitable for most cryptographic purposes, the authors of the corresponding [[man page]] note that, theoretically, there may exist an as-yet-unpublished attack on the algorithm used by {{mono|/dev/urandom}}, and that users concerned about such an attack should use {{mono|/dev/random}} instead.<ref name="linux-man-page" /> However such an attack is unlikely to come into existence, because once the entropy pool is unpredictable it doesn't leak security by a reduced number of bits.<ref>{{cite AV media|url=https://media.ccc.de/v/32c3-7441-the_plain_simple_reality_of_entropy#video&t=1262|title=The plain simple reality of entropy|author=Filippo Valsorda|date=2015-12-29}}</ref>
| access-date=2013-11-21}}</ref>/non-blocking random source<ref name="linux-man-page" />) which reuses the internal pool to produce more pseudo-random bits.  
* This means that the call will not block, but the output may contain less entropy than the corresponding read from {{mono|/dev/random}}.  
* While {{mono|/dev/urandom}} is still intended as a pseudorandom number generator suitable for most cryptographic purposes, the authors of the corresponding [[man page]] note that, theoretically, there may exist an as-yet-unpublished attack on the algorithm used by {{mono|/dev/urandom}}, and that users concerned about such an attack should use {{mono|/dev/random}} instead.<ref name="linux-man-page" /> However such an attack is unlikely to come into existence, because once the entropy pool is unpredictable it doesn't leak security by a reduced number of bits.<ref>{{cite AV media|url=https://media.ccc.de/v/32c3-7441-the_plain_simple_reality_of_entropy#video&t=1262|title=The plain simple reality of entropy|author=Filippo Valsorda|date=2015-12-29}}</ref>


It is also possible to write to {{mono|/dev/random}}. This allows any user to mix random data into the pool. Non-random data is harmless, because only a privileged user can issue the [[ioctl]] needed to increase the entropy estimate.{{Dubious|date=December 2020|reason=This isn't the reason that writing non-random data is harmless. 1. The non-random data mixes with the random data in a way that keeps only the randomness, like XOR? That would make it harmless?  2. The entropy estimate is not increased when you write to it, according to https://linux.die.net/man/4/urandom, but it DOES affect the output, so that isn't what makes it harmless. 3. Only privileged users can update the entropy estimate, which doesn't make it harmless?}} The current amount of entropy and the size of the Linux kernel entropy pool, both measured in bits, are available in {{mono|/proc/sys/kernel/random/}} and can be displayed by the command {{code|cat /proc/sys/kernel/random/entropy_avail}} and {{code|cat /proc/sys/kernel/random/poolsize}} respectively.
It is also possible to write to {{mono|/dev/random}}.  
* This allows any user to mix random data into the pool.  
* Non-random data is harmless, because only a privileged user can issue the [[ioctl]] needed to increase the entropy estimate.{{Dubious|date=December 2020|reason=This isn't the reason that writing non-random data is harmless. 1.  
* The non-random data mixes with the random data in a way that keeps only the randomness, like XOR? That would make it harmless?  2.  
* The entropy estimate is not increased when you write to it, according to https://linux.die.net/man/4/urandom, but it DOES affect the output, so that isn't what makes it harmless. 3.  
* Only privileged users can update the entropy estimate, which doesn't make it harmless?}} The current amount of entropy and the size of the Linux kernel entropy pool, both measured in bits, are available in {{mono|/proc/sys/kernel/random/}} and can be displayed by the command {{code|cat /proc/sys/kernel/random/entropy_avail}} and {{code|cat /proc/sys/kernel/random/poolsize}} respectively.


Gutterman, Pinkas, & Reinman in March 2006 published a detailed cryptographic analysis of the Linux random number generator<ref>{{cite web
Gutterman, Pinkas, & Reinman in March 2006 published a detailed cryptographic analysis of the Linux random number generator<ref>{{cite web
Zeile 139: Zeile 154:
| archive-url=https://web.archive.org/web/20081003041432/http://www.pinkas.net/PAPERS/gpr06.pdf
| archive-url=https://web.archive.org/web/20081003041432/http://www.pinkas.net/PAPERS/gpr06.pdf
| archive-date=2008-10-03
| archive-date=2008-10-03
| url-status=live}}</ref> in which they describe several weaknesses. Perhaps the most severe issue they report is with [[embedded system|embedded]] or [[Live CD]] systems, such as routers and [[diskless node|diskless clients]], for which the bootup state is predictable and the available supply of entropy from the environment may be limited. For a system with non-volatile memory, they recommend saving some state from the RNG at shutdown so that it can be included in the RNG state on the next reboot. In the case of a router for which network traffic represents the primary available source of entropy, they note that saving state across reboots "would require potential attackers to either eavesdrop on all network traffic" from when the router is first put into service, or obtain direct access to the router's internal state. This issue, they note, is particularly critical in the case of a wireless router whose network traffic can be captured from a distance, and which may be using the RNG to generate keys for data encryption.
| url-status=live}}</ref> in which they describe several weaknesses.  
* Perhaps the most severe issue they report is with [[embedded system|embedded]] or [[Live CD]] systems, such as routers and [[diskless node|diskless clients]], for which the bootup state is predictable and the available supply of entropy from the environment may be limited.  
* For a system with non-volatile memory, they recommend saving some state from the RNG at shutdown so that it can be included in the RNG state on the next reboot.  
* In the case of a router for which network traffic represents the primary available source of entropy, they note that saving state across reboots "would require potential attackers to either eavesdrop on all network traffic" from when the router is first put into service, or obtain direct access to the router's internal state.  
* This issue, they note, is particularly critical in the case of a wireless router whose network traffic can be captured from a distance, and which may be using the RNG to generate keys for data encryption.


The Linux kernel provides support for several [[hardware random number generator]]s, should they be installed. The raw output of such a device may be obtained from {{mono|/dev/hwrng}}.<ref>{{cite web
The Linux kernel provides support for several [[hardware random number generator]]s, should they be installed.  
* The raw output of such a device may be obtained from {{mono|/dev/hwrng}}.<ref>{{cite web
| url=http://processors.wiki.ti.com/index.php/Cryptography_Users_Guide
| url=http://processors.wiki.ti.com/index.php/Cryptography_Users_Guide
| title=Cryptography Users Guide
| title=Cryptography Users Guide
Zeile 152: Zeile 172:
}}</ref>
}}</ref>


With Linux kernel 3.16 and newer,<ref>{{cite web|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=be4000bc4644d027c519b6361f5ae3bbfc52c347|title=kernel/git/torvalds/linux.git - Linux kernel source tree @ be4000bc4644d027c519b6361f5ae3bbfc52c347 "hwrng: create filler thread"|website=Git.kernel.org|access-date=18 October 2016}}</ref> the kernel itself mixes data from [[hardware random number generator]]s into {{mono|/dev/random}} on a sliding scale based on the definable entropy estimation quality of the HWRNG. This means that no userspace daemon, such as {{mono|rngd}} from {{mono|rng-tools}}, is needed to do that job. With Linux kernel 3.17+, the VirtIO RNG was modified to have a default quality defined above 0,<ref>{{cite web|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=34679ec7a0c45da8161507e1f2e1f72749dfd85c|title=kernel/git/torvalds/linux.git - Linux kernel source tree @ 34679ec7a0c45da8161507e1f2e1f72749dfd85c "virtio: rng: add derating factor for use by hwrng core"|website=Git.kernel.org|access-date=18 October 2016}}</ref> and as such, is currently the only HWRNG mixed into {{mono|/dev/random}} by default.
With Linux kernel 3.16 and newer,<ref>{{cite web|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=be4000bc4644d027c519b6361f5ae3bbfc52c347|title=kernel/git/torvalds/linux.git - Linux kernel source tree @ be4000bc4644d027c519b6361f5ae3bbfc52c347 "hwrng: create filler thread"|website=Git.kernel.org|access-date=18 October 2016}}</ref> the kernel itself mixes data from [[hardware random number generator]]s into {{mono|/dev/random}} on a sliding scale based on the definable entropy estimation quality of the HWRNG.  
* This means that no userspace daemon, such as {{mono|rngd}} from {{mono|rng-tools}}, is needed to do that job.  
* With Linux kernel 3.17+, the VirtIO RNG was modified to have a default quality defined above 0,<ref>{{cite web|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=34679ec7a0c45da8161507e1f2e1f72749dfd85c|title=kernel/git/torvalds/linux.git - Linux kernel source tree @ 34679ec7a0c45da8161507e1f2e1f72749dfd85c "virtio: rng: add derating factor for use by hwrng core"|website=Git.kernel.org|access-date=18 October 2016}}</ref> and as such, is currently the only HWRNG mixed into {{mono|/dev/random}} by default.


The entropy pool can be improved by programs like {{mono|timer_entropyd}}, {{mono|haveged}}, {{mono|randomsound}} etc.  With {{mono|rng-tools}}, [[hardware random number generator]]s like ''Entropy Key, etc.'' can write to {{mono|/dev/random}}. The [[diehard tests]] programs {{mono|dieharder}}, {{mono|diehard}} and {{mono|ent}} can test these random number generators.<ref>{{cite web |url=http://www.vanheusden.com/te/timer_entropyd-0.1.tgz |title=?? |website=Vanheusden.com |access-date=2016-10-23 |archive-url=https://web.archive.org/web/20130921054659/http://www.vanheusden.com/te/timer_entropyd-0.1.tgz |archive-date=2013-09-21 |url-status=dead }}</ref><ref>{{cite web|url=https://code.google.com/p/dieharder/|title=Google Code Archive for dieharder|website=Code.google.com|access-date=18 October 2016}}</ref><ref>{{cite web|url=http://stat.fsu.edu/pub/diehard/|title=The Marsaglia Random Number CDROM including the Diehard Battery of Tests of Randomness|website=Stat.fsu.edu|access-date=2016-10-23|archive-url=https://web.archive.org/web/20160125103112/http://stat.fsu.edu/pub/diehard/|archive-date=2016-01-25|url-status=dead}}</ref><ref>{{cite web|url=https://www.gnu.org/software/hurd/user/tlecarrour/rng-tools.html|title=rng-tools|website=Gnu.org|access-date=2016-10-23}}</ref>
The entropy pool can be improved by programs like {{mono|timer_entropyd}}, {{mono|haveged}}, {{mono|randomsound}} etc.  With {{mono|rng-tools}}, [[hardware random number generator]]s like ''Entropy Key, etc.'' can write to {{mono|/dev/random}}.  
* The [[diehard tests]] programs {{mono|dieharder}}, {{mono|diehard}} and {{mono|ent}} can test these random number generators.<ref>{{cite web |url=http://www.vanheusden.com/te/timer_entropyd-0.1.tgz |title=?? |website=Vanheusden.com |access-date=2016-10-23 |archive-url=https://web.archive.org/web/20130921054659/http://www.vanheusden.com/te/timer_entropyd-0.1.tgz |archive-date=2013-09-21 |url-status=dead }}</ref><ref>{{cite web|url=https://code.google.com/p/dieharder/|title=Google Code Archive for dieharder|website=Code.google.com|access-date=18 October 2016}}</ref><ref>{{cite web|url=http://stat.fsu.edu/pub/diehard/|title=The Marsaglia Random Number CDROM including the Diehard Battery of Tests of Randomness|website=Stat.fsu.edu|access-date=2016-10-23|archive-url=https://web.archive.org/web/20160125103112/http://stat.fsu.edu/pub/diehard/|archive-date=2016-01-25|url-status=dead}}</ref><ref>{{cite web|url=https://www.gnu.org/software/hurd/user/tlecarrour/rng-tools.html|title=rng-tools|website=Gnu.org|access-date=2016-10-23}}</ref>


In January 2014, [[Daniel J. Bernstein]] published a critique<ref>{{cite web|url=http://blog.cr.yp.to/20140205-entropy.html|title=cr.yp.to: 2014.02.05: Entropy Attacks!|author=Daniel J. Bernstein|author-link=Daniel J. Bernstein|date=2014-02-05}}</ref> of how Linux mixes different sources of entropy.  He outlines an attack in which one source of entropy capable of monitoring the other sources of entropy could modify its output to nullify the randomness of the other sources of entropy.  Consider the function {{tmath|H(x,y,z)}} where ''H'' is a hash function and ''x'', ''y'', and ''z'' are sources of entropy with ''z'' being the output of a CPU based malicious HRNG Z:
In January 2014, [[Daniel J.  
* Bernstein]] published a critique<ref>{{cite web|url=http://blog.cr.yp.to/20140205-entropy.html|title=cr.yp.to: 2014.02.05: Entropy Attacks!|author=Daniel J.  
* Bernstein|author-link=Daniel J.  
* Bernstein|date=2014-02-05}}</ref> of how Linux mixes different sources of entropy.  He outlines an attack in which one source of entropy capable of monitoring the other sources of entropy could modify its output to nullify the randomness of the other sources of entropy.  Consider the function {{tmath|H(x,y,z)}} where ''H'' is a hash function and ''x'', ''y'', and ''z'' are sources of entropy with ''z'' being the output of a CPU based malicious HRNG Z:
#''Z'' generates a random value of ''r''.
#''Z'' generates a random value of ''r''.
#''Z'' computes {{tmath|H(x,y,r)}}.
#''Z'' computes {{tmath|H(x,y,r)}}.
Zeile 163: Zeile 189:
Bernstein estimated that an attacker would need to repeat {{tmath|H(x,y,r)}} 16 times to compromise DSA and ECDSA.  This is possible because Linux reseeds H on an ongoing basis instead of using a single high quality seed.
Bernstein estimated that an attacker would need to repeat {{tmath|H(x,y,r)}} 16 times to compromise DSA and ECDSA.  This is possible because Linux reseeds H on an ongoing basis instead of using a single high quality seed.


In October 2016, with the release of [[Linux kernel]] version 4.8, the kernel's {{mono|/dev/urandom}} was switched over to a [[ChaCha20]]-based [[cryptographic pseudorandom number generator]] (CPRNG) implementation<ref>{{Cite web |url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=818e607b57c94ade9824dad63a96c2ea6b21baf3 |title=kernel/git/torvalds/linux.git - Linux kernel source tree |date=2016-07-27 |publisher=kernel.org |access-date=2016-11-23}}</ref> by [[Theodore Ts'o]], based on [[Daniel J. Bernstein|Bernstein]]'s well-regarded [[stream cipher]] [[ChaCha20]].
In October 2016, with the release of [[Linux kernel]] version 4.8, the kernel's {{mono|/dev/urandom}} was switched over to a [[ChaCha20]]-based [[cryptographic pseudorandom number generator]] (CPRNG) implementation<ref>{{Cite web |url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=818e607b57c94ade9824dad63a96c2ea6b21baf3 |title=kernel/git/torvalds/linux.git - Linux kernel source tree |date=2016-07-27 |publisher=kernel.org |access-date=2016-11-23}}</ref> by [[Theodore Ts'o]], based on [[Daniel J.  
* Bernstein|Bernstein]]'s well-regarded [[stream cipher]] [[ChaCha20]].


In 2020, the Linux kernel version 5.6 {{mono|/dev/random}} only blocks when the CPRNG hasn't initialized. Once initialized, {{mono|/dev/random}} and {{mono|/dev/urandom}} behave the same.<ref>{{Cite web|url=https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.6-Random-Rework|title=/dev/random Is More Like /dev/urandom With Linux 5.6 - Phoronix|website=www.phoronix.com}}</ref>
In 2020, the Linux kernel version 5.6 {{mono|/dev/random}} only blocks when the CPRNG hasn't initialized.  
* Once initialized, {{mono|/dev/random}} and {{mono|/dev/urandom}} behave the same.<ref>{{Cite web|url=https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.6-Random-Rework|title=/dev/random Is More Like /dev/urandom With Linux 5.6 - Phoronix|website=www.phoronix.com}}</ref>


== BSD systems ==
== BSD systems ==
The [[FreeBSD]] operating system provides a {{mono|/dev/urandom}} link to {{mono|/dev/random}}.  Both block only until properly seeded.  FreeBSD's PRNG ([[Fortuna (PRNG)|Fortuna]]) reseeds regularly, and does not attempt to estimate entropy.  On a system with small amount of network and disk activity, reseeding is done after a fraction of a second.
The [[FreeBSD]] operating system provides a {{mono|/dev/urandom}} link to {{mono|/dev/random}}.  Both block only until properly seeded.  FreeBSD's PRNG ([[Fortuna (PRNG)|Fortuna]]) reseeds regularly, and does not attempt to estimate entropy.  On a system with small amount of network and disk activity, reseeding is done after a fraction of a second.


Since [[OpenBSD]] 5.1 (May 1, 2012) {{mono|/dev/random}} and {{mono|/dev/arandom}} used an algorithm based on [[RC4]] but renamed to ARC4 because of intellectual property reasons. While random number generation here uses system entropy gathered in several ways, the ARC4 algorithm provides a fail-safe, ensuring that a rapid and high quality pseudo-random number stream is provided even when the pool is in a low entropy state. The system automatically uses hardware random number generators (such as those provided on some Intel PCI hubs) if they are available, through the [[OpenBSD Cryptographic Framework]]. As of OpenBSD 5.5 (May 1, 2014), the {{code|arc4random()}} call used for OpenBSD's random devices no longer uses ARC4, but [[ChaCha20]] (''arc4random'' name might be reconsidered as ''A Replacement Call for Random'').<ref>{{man|3|arc4random|OpenBSD}}</ref><ref>{{cite web  
Since [[OpenBSD]] 5.1 (May 1, 2012) {{mono|/dev/random}} and {{mono|/dev/arandom}} used an algorithm based on [[RC4]] but renamed to ARC4 because of intellectual property reasons.  
* While random number generation here uses system entropy gathered in several ways, the ARC4 algorithm provides a fail-safe, ensuring that a rapid and high quality pseudo-random number stream is provided even when the pool is in a low entropy state.  
* The system automatically uses hardware random number generators (such as those provided on some Intel PCI hubs) if they are available, through the [[OpenBSD Cryptographic Framework]].  
* As of OpenBSD 5.5 (May 1, 2014), the {{code|arc4random()}} call used for OpenBSD's random devices no longer uses ARC4, but [[ChaCha20]] (''arc4random'' name might be reconsidered as ''A Replacement Call for Random'').<ref>{{man|3|arc4random|OpenBSD}}</ref><ref>{{cite web  
|url=http://bxr.su/OpenBSD/lib/libc/crypt/arc4random.c  
|url=http://bxr.su/OpenBSD/lib/libc/crypt/arc4random.c  
|title=libc/crypt/arc4random.c  
|title=libc/crypt/arc4random.c  
Zeile 230: Zeile 261:
| url-status=live}}</ref>
| url-status=live}}</ref>


In [[Windows NT]], similar functionality is delivered by {{mono|ksecdd.sys}}, but reading the special file {{mono|\Device\KsecDD}} does not work as in UNIX. The documented methods to generate cryptographically random bytes are [[CryptGenRandom]] and [[RtlGenRandom]]. Windows [[PowerShell]] provides access to a cryptographically secure pseudorandom number generator via the {{mono|Get-Random}} cmdlet.<ref>{{Cite web |title=Get-Random |author=Microsoft |work=learn.microsoft.com |date= |access-date=11 November 2022 |url= https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/get-random?view=powershell-7.2 }}</ref>
In [[Windows NT]], similar functionality is delivered by {{mono|ksecdd.sys}}, but reading the special file {{mono|\Device\KsecDD}} does not work as in UNIX.  
* The documented methods to generate cryptographically random bytes are [[CryptGenRandom]] and [[RtlGenRandom]].  
* Windows [[PowerShell]] provides access to a cryptographically secure pseudorandom number generator via the {{mono|Get-Random}} cmdlet.<ref>{{Cite web |title=Get-Random |author=Microsoft |work=learn.microsoft.com |date= |access-date=11 November 2022 |url= https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/get-random?view=powershell-7.2 }}</ref>


[[Cygwin]] on Windows provides implementations of both {{mono|/dev/random}} and {{mono|/dev/urandom}}, which can be used in scripts and programs.<ref>{{Cite web|url=https://www.linuxquestions.org/questions/general-10/how-does-cygwin's-dev-random-and-urandom-work-903054/#post4493834|title=How does Cygwin's /dev/random and urandom work?|website=www.linuxquestions.org|language=en|access-date=2018-03-09}}</ref>
[[Cygwin]] on Windows provides implementations of both {{mono|/dev/random}} and {{mono|/dev/urandom}}, which can be used in scripts and programs.<ref>{{Cite web|url=https://www.linuxquestions.org/questions/general-10/how-does-cygwin's-dev-random-and-urandom-work-903054/#post4493834|title=How does Cygwin's /dev/random and urandom work?|website=www.linuxquestions.org|language=en|access-date=2018-03-09}}</ref>

Version vom 10. März 2023, 01:18 Uhr

topic - Kurzbeschreibung

Beschreibung

Installation

Anwendungen

Fehlerbehebung

Syntax

Optionen

Parameter

Umgebungsvariablen

Exit-Status

Konfiguration

Dateien

Sicherheit

Siehe auch

Dokumentation

RFC

Man-Pages

Info-Pages

Links

Einzelnachweise

Projekt

Weblinks

Testfragen

Testfrage 1

Antwort1

Testfrage 2

Antwort2

Testfrage 3

Antwort3

Testfrage 4

Antwort4

Testfrage 5

Antwort5

Wikipedia

/dev/random ist unter vielen unixoiden Betriebssystemen eine zeichenorientierte virtuelle Gerätedatei, über das Programme auf einen systemweiten Zufallszahlengenerator von hoher Qualität zugreifen können.

Der Zufallsgenerator sammelt Umgebungsrauschen von Gerätetreibern und anderen Quellen in einem Entropie-„Pool“.

  • Der Generator speichert auch eine Abschätzung über die Anzahl der Bits im Entropie-Pool.
  • Aus diesem „Pool“ werden die Zufallszahlen generiert.
  • Beim Lesen gibt /dev/random nur solange Zufallszahlen zurück, bis die abgeschätzte Entropiemenge erschöpft ist; dann blockieren Lesezugriffe auf /dev/random, bis zusätzliches Umgebungsrauschen erhalten wurde.[1][2] /dev/random sollte ausreichend sein für Anwendungszwecke, die auf eine sehr hohe Qualität der Zufälligkeit angewiesen sind, wie etwa Verschlüsselung (beispielsweise One-Time-Pads oder Schlüsselerzeugung).
  • Aus Geschwindigkeitsgründen wird in der Praxis oft nur der „Seed“ eines Pseudo-Zufallszahlengenerators von /dev/random gelesen (z. B. in OpenSSL, PGP und GnuPG).

Der aktuelle Füllstand des Entropie-Pools lässt sich unter Linux aus der Datei /proc/sys/kernel/random/entropy_avail ermitteln.

  • Eine Ausgabe der Datei liefert die verfügbare Entropie in Bit, wobei das Maximum von 4096 Bit einem vollständig gefüllten „Pool“ entspricht.

/dev/urandom

Aus /dev/urandom (von engl. Vorlage:Lang) können wie aus /dev/random Zufallszahlen gelesen werden. /dev/urandom blockiert jedoch nicht, wenn eine definierte Entropieschwelle unterschritten wird.

  • In diesem Fall kann nicht ganz ausgeschlossen werden, dass es einem Angreifer gelingt, die erzeugten Pseudozufallszahlen im Nachhinein zu berechnen.[3]

Standardisierung

/dev/random (wie auch /dev/urandom) ist weder im Filesystem Hierarchy Standard 2.3 noch in der Single UNIX Specification 3.0 spezifiziert.

  • Der Linux-Kernel stellte 1994 als erstes Betriebssystem ein /dev/random-Gerät bereit, woraufhin andere unixoide Betriebssysteme nachzogen,[4][5] so zum Beispiel FreeBSD 2.2 ab Juni 2000[6] oder Solaris 9 ab 2002.[7]

Implementierungen

In FreeBSD findet ein auf dem Yarrow-Algorithmus basierender Generator Verwendung[8]. AIX verwendet seit AIX 5.2 ebenfalls eine Yarrow-Implementation.[9]

In Linux verhält sich /dev/random seit 2020 wie /dev/urandom, da dessen Zufallszahlen mittlerweile als praktikabel selbst für kryptographische Zwecke angesehen werden.[10]

Verbesserung der Entropie

Über Software, wie z. B. timer_entropyd, haveged, randomsound, lässt sich die Entropie verbessern sowie der Entropie-Pool vergrößern, damit mehr Zufallszahlen zur Verfügung stehen.

Siehe auch

Literatur

Einzelnachweise

  1. ↑ Linux manpage random(4)
  2. ↑ Solaris 10 manpage Vorlage:Webarchiv
  3. ↑ http://linux.die.net/man/4/urandom
  4. ↑
  5. ↑
  6. ↑ http://svn.freebsd.org/viewvc/base/head/sys/dev/random/randomdev.c?view=log
  7. ↑ Vorlage:Webarchiv
  8. ↑
  9. ↑
  10. ↑
  11. ↑ Vorlage:Webarchiv

Wikipedia EN

256 byte hex dump of /dev/urandom

Vorlage:Short description

In Unix-like operating systems, Vorlage:Mono and Vorlage:Mono are special files that serve as cryptographically secure pseudorandom number generators.

  • They allow access to environmental noise collected from device drivers and other sources.[1] Vorlage:Mono typically blocked if there was less entropy available than requested; more recently (see below for the differences between operating systems) it usually blocks at startup until sufficient entropy has been gathered, then unblocks permanently.
  • The Vorlage:Mono device typically was never a blocking device, even if the pseudorandom number generator seed was not fully initialized with entropy since boot.
  • Not all operating systems implement the same methods for Vorlage:Mono and Vorlage:Mono.

Linux

Rngtest testing /dev/random pool

Random number generation in kernel space was implemented for the first time for Linux[2] in 1994 by Theodore Ts'o.[3] The implementation used secure hashes rather than ciphers,Vorlage:Clarify to avoid cryptography export restrictions that were in place when the generator was originally designed.

  • The implementation was also designed with the assumption that any given hash or cipher might eventually be found to be weak, and so the design is durable in the face of any such weaknesses.
  • Fast recovery from pool compromise is not considered a requirement, because the requirements for pool compromise are sufficient for much easier and more direct attacks on unrelated parts of the operating system.

In Ts'o's implementation, the generator keeps an estimate of the number of bits of noise in the entropy pool.

  • From this entropy pool random numbers are created.
  • When read, the Vorlage:Mono device will only return random bytes within the estimated number of bits of noise in the entropy pool. When the entropy pool is empty, reads from Vorlage:Mono will block until additional environmental noise is gathered.[4] The intent is to serve as a cryptographically secure pseudorandom number generator, delivering output with entropy as large as possible.
  • This is suggested by the authors for use in generating cryptographic keys for high-value or long-term protection.[4]

A counterpart to Vorlage:Mono is Vorlage:Mono ("unlimited"[5]/non-blocking random source[4]) which reuses the internal pool to produce more pseudo-random bits.

  • This means that the call will not block, but the output may contain less entropy than the corresponding read from Vorlage:Mono.
  • While Vorlage:Mono is still intended as a pseudorandom number generator suitable for most cryptographic purposes, the authors of the corresponding man page note that, theoretically, there may exist an as-yet-unpublished attack on the algorithm used by Vorlage:Mono, and that users concerned about such an attack should use Vorlage:Mono instead.[4] However such an attack is unlikely to come into existence, because once the entropy pool is unpredictable it doesn't leak security by a reduced number of bits.[6]

It is also possible to write to Vorlage:Mono.

  • This allows any user to mix random data into the pool.
  • Non-random data is harmless, because only a privileged user can issue the ioctl needed to increase the entropy estimate.Vorlage:Dubious The current amount of entropy and the size of the Linux kernel entropy pool, both measured in bits, are available in Vorlage:Mono and can be displayed by the command Vorlage:Code and Vorlage:Code respectively.

Gutterman, Pinkas, & Reinman in March 2006 published a detailed cryptographic analysis of the Linux random number generator[7] in which they describe several weaknesses.

  • Perhaps the most severe issue they report is with embedded or Live CD systems, such as routers and diskless clients, for which the bootup state is predictable and the available supply of entropy from the environment may be limited.
  • For a system with non-volatile memory, they recommend saving some state from the RNG at shutdown so that it can be included in the RNG state on the next reboot.
  • In the case of a router for which network traffic represents the primary available source of entropy, they note that saving state across reboots "would require potential attackers to either eavesdrop on all network traffic" from when the router is first put into service, or obtain direct access to the router's internal state.
  • This issue, they note, is particularly critical in the case of a wireless router whose network traffic can be captured from a distance, and which may be using the RNG to generate keys for data encryption.

The Linux kernel provides support for several hardware random number generators, should they be installed.

With Linux kernel 3.16 and newer,[9] the kernel itself mixes data from hardware random number generators into Vorlage:Mono on a sliding scale based on the definable entropy estimation quality of the HWRNG.

  • This means that no userspace daemon, such as Vorlage:Mono from Vorlage:Mono, is needed to do that job.
  • With Linux kernel 3.17+, the VirtIO RNG was modified to have a default quality defined above 0,[10] and as such, is currently the only HWRNG mixed into Vorlage:Mono by default.

The entropy pool can be improved by programs like Vorlage:Mono, Vorlage:Mono, Vorlage:Mono etc. With Vorlage:Mono, hardware random number generators like Entropy Key, etc. can write to Vorlage:Mono.

In January 2014, [[Daniel J.

  • Bernstein]] published a critique[15] of how Linux mixes different sources of entropy. He outlines an attack in which one source of entropy capable of monitoring the other sources of entropy could modify its output to nullify the randomness of the other sources of entropy. Consider the function Vorlage:Tmath where H is a hash function and x, y, and z are sources of entropy with z being the output of a CPU based malicious HRNG Z:
  1. Z generates a random value of r.
  2. Z computes Vorlage:Tmath.
  3. If the output of Vorlage:Tmath is equal to the desired value, output r as z.
  4. Else, repeat starting at 1.

Bernstein estimated that an attacker would need to repeat Vorlage:Tmath 16 times to compromise DSA and ECDSA. This is possible because Linux reseeds H on an ongoing basis instead of using a single high quality seed.

In October 2016, with the release of Linux kernel version 4.8, the kernel's Vorlage:Mono was switched over to a ChaCha20-based cryptographic pseudorandom number generator (CPRNG) implementation[16] by Theodore Ts'o, based on [[Daniel J.

In 2020, the Linux kernel version 5.6 Vorlage:Mono only blocks when the CPRNG hasn't initialized.

BSD systems

The FreeBSD operating system provides a Vorlage:Mono link to Vorlage:Mono. Both block only until properly seeded. FreeBSD's PRNG (Fortuna) reseeds regularly, and does not attempt to estimate entropy. On a system with small amount of network and disk activity, reseeding is done after a fraction of a second.

Since OpenBSD 5.1 (May 1, 2012) Vorlage:Mono and Vorlage:Mono used an algorithm based on RC4 but renamed to ARC4 because of intellectual property reasons.

  • While random number generation here uses system entropy gathered in several ways, the ARC4 algorithm provides a fail-safe, ensuring that a rapid and high quality pseudo-random number stream is provided even when the pool is in a low entropy state.
  • The system automatically uses hardware random number generators (such as those provided on some Intel PCI hubs) if they are available, through the OpenBSD Cryptographic Framework.
  • As of OpenBSD 5.5 (May 1, 2014), the Vorlage:Code call used for OpenBSD's random devices no longer uses ARC4, but ChaCha20 (arc4random name might be reconsidered as A Replacement Call for Random).[18][19] Vorlage:Mono was removed in OpenBSD 6.3 (April 15, 2018).[20]

NetBSD's implementation of the legacy Vorlage:Code API has been switched over to ChaCha20 as well.[21]

macOS, iOS and other Apple OSes

All Apple OSes have moved to Fortuna since at least December 2019, possibly earlier.[22] It is based on SHA-256. Multiple entropy sources such as the secure enclave RNG, boot phase timing jitter, hardware interrupt (timing assumed) are used. RDSEED/RDRAND is used on Intel-based Macs that support it. Seed (entropy) data is also stored for subsequent reboots.

Prior to the change, macOS and iOS used 160-bit Yarrow based on SHA-1.[23]

There is no difference between Vorlage:Mono and Vorlage:Mono; both behave identically.[24][25]

Other operating systems

Vorlage:Mono and Vorlage:Mono are also available on Solaris,[26] NetBSD,[27] Tru64 UNIX 5.1B,[28] AIX 5.2[29] and HP-UX 11i v2.[30] As with FreeBSD, AIX implements its own Yarrow-based design, however AIX uses considerably fewer entropy sources than the standard Vorlage:Mono implementation and stops refilling the pool when it thinks it contains enough entropy.[31]

In Windows NT, similar functionality is delivered by Vorlage:Mono, but reading the special file Vorlage:Mono does not work as in UNIX.

Cygwin on Windows provides implementations of both Vorlage:Mono and Vorlage:Mono, which can be used in scripts and programs.[33]

See also

References

Vorlage:Reflist

External links

Achtung: Der Sortierungsschlüssel „Dev Random“ überschreibt den vorher verwendeten Schlüssel „Random“.

  1. ↑ Vorlage:Cite web
  2. ↑ Vorlage:Cite web
  3. ↑ Vorlage:Cite web
  4. ↑ 4,0 4,1 4,2 4,3 Vorlage:Man
  5. ↑ Vorlage:Cite web
  6. ↑ Vorlage:Cite AV media
  7. ↑ Vorlage:Cite web
  8. ↑ Vorlage:Cite web
  9. ↑ Vorlage:Cite web
  10. ↑ Vorlage:Cite web
  11. ↑ Vorlage:Cite web
  12. ↑ Vorlage:Cite web
  13. ↑ Vorlage:Cite web
  14. ↑ Vorlage:Cite web
  15. ↑ Vorlage:Cite web
  16. ↑ Vorlage:Cite web
  17. ↑ Vorlage:Cite web
  18. ↑ Vorlage:Man
  19. ↑ Vorlage:Cite web
  20. ↑ Vorlage:Cite web
  21. ↑ Vorlage:Cite web
  22. ↑ Vorlage:Cite web
  23. ↑ Vorlage:Cite web
  24. ↑ Vorlage:Man
  25. ↑ Vorlage:Cite web
  26. ↑ Vorlage:Cite web
  27. ↑ Vorlage:Man
  28. ↑ Vorlage:Cite web
  29. ↑ Vorlage:Cite web
  30. ↑ Vorlage:Cite web
  31. ↑ Vorlage:Cite web
  32. ↑ Vorlage:Cite web
  33. ↑ Vorlage:Cite web


https://en.wikipedia.org/wiki//dev/random

Abgerufen von „https://wiki.foxtom.de/index.php?title=/dev/random&oldid=56900“