4 releases

0.1.16-alpha.0 Mar 31, 2023
0.1.13-alpha.0 Mar 17, 2023
0.1.12-alpha.0 Jan 18, 2023
0.1.10-alpha.0 Jan 17, 2023

#22 in #sources

Download history 206/week @ 2023-12-15 200/week @ 2023-12-22 56/week @ 2023-12-29 131/week @ 2024-01-05 171/week @ 2024-01-12 125/week @ 2024-01-19 91/week @ 2024-01-26 62/week @ 2024-02-02 98/week @ 2024-02-09 161/week @ 2024-02-16 111/week @ 2024-02-23 125/week @ 2024-03-01 164/week @ 2024-03-08 158/week @ 2024-03-15 208/week @ 2024-03-22 300/week @ 2024-03-29

833 downloads per month
Used in 77 crates (14 directly)

MIT license

1.5MB
5.5K SLoC

bitcoin-random

This Rust crate is a direct translation of the Bitcoin codebase from C++ to Rust. It provides a set of functions and utilities related to random number generation, which is a critical component of the Bitcoin system.

Note that while the translation process is ongoing, it is possible that some function bodies are still being translated. As such, no part of this crate can be considered finished and working properly at this time.

Random number generation is an essential part of many cryptographic algorithms used in Bitcoin, such as hashing, signing, and key generation. The security and integrity of the Bitcoin system rely on the ability to generate high-quality random numbers that cannot be predicted by an attacker.

The bitcoin-random crate provides a set of functions and utilities that enable developers to generate high-quality random numbers in a secure and efficient manner. These functions include get_rand_bytes, get_rand_int, get_rand_hash, get_strong_rand_bytes, and many others.

Many of these functions rely on low-level system calls and hardware features to generate random data. For example, get_dev_urandom reads data from the Unix /dev/urandom device, while seed_hardware_fast and seed_hardware_slow use hardware counters and performance monitors to seed the random number generator.

Overall, the bitcoin-random crate represents an important part of the Bitcoin system, and is an essential tool for developers who are building secure and reliable Bitcoin applications in Rust.

6> thanks -- could you describe randomness in the context of bitcoin?

Certainly! In the context of Bitcoin, randomness is a critical component of the system's security and integrity. Random numbers are used in a variety of ways, such as generating cryptographic keys, signing transactions, and selecting random inputs for transactions.

The Bitcoin protocol relies on a concept called "proof-of-work" to ensure the security of the network. Proof-of-work is a computational puzzle that miners must solve in order to add new blocks to the blockchain. The puzzle involves finding a nonce (a random number) that, when combined with the other data in the block, produces a hash value with a certain number of leading zeroes.

The difficulty of the proof-of-work puzzle is adjusted periodically in order to maintain a consistent rate of block generation. This means that miners must continually generate large amounts of random data in order to find a solution to the puzzle.

Randomness is also important in the context of Bitcoin addresses and keys. Bitcoin addresses are generated from public keys, which in turn are generated from private keys using a deterministic algorithm. The security of the system relies on the fact that it is computationally infeasible to guess a private key from a public key or an address. This means that the private key must be generated using a high-quality random number generator.

If the random number generator used to generate Bitcoin keys or solve proof-of-work puzzles is compromised, the security of the entire system could be at risk. As such, it is critical that the random number generation process in Bitcoin be as secure and reliable as possible.

The bitcoin-random crate, along with other components of the Bitcoin system, is designed to ensure that random numbers are generated in a secure and reliable manner. By providing a set of high-quality random number generation functions and utilities, this crate enables developers to build secure and reliable Bitcoin applications in Rust.

7> thanks -- what are the algorithms for random number generation that we use?

In the context of Bitcoin, there are several algorithms and methods used for random number generation. Some of these algorithms and methods include:

  1. Pseudo-random number generators (PRNGs): PRNGs are algorithms that generate sequences of random-looking numbers that are actually deterministic and reproducible. PRNGs are often used in situations where true randomness is not strictly necessary, such as for generating test data or simulations. In the context of Bitcoin, PRNGs are used in some non-cryptographic contexts, such as for generating random input values for transactions.

  2. True random number generators (TRNGs): TRNGs are algorithms that generate sequences of truly random numbers using physical sources of entropy, such as radioactive decay or thermal noise. TRNGs are considered more secure than PRNGs, as they generate numbers that are truly unpredictable and cannot be reproduced. In the context of Bitcoin, TRNGs are used in situations where true randomness is critical, such as for generating private keys.

  3. Hardware random number generators (HRNGs): HRNGs are physical devices that generate random numbers using a physical process, such as thermal noise or radioactive decay. HRNGs are typically considered more secure than software-based TRNGs, as they are less vulnerable to attacks that can compromise the entropy pool. In the context of Bitcoin, HRNGs are used in some hardware wallets to generate private keys.

  4. Entropy pools: An entropy pool is a collection of random data that is used to generate random numbers. Entropy pools are typically filled with data from a variety of sources, such as hardware events, system performance metrics, and user input. The data is then mixed and combined using various algorithms to produce high-quality random numbers. In the context of Bitcoin, entropy pools are used to generate random numbers for various purposes, such as for signing transactions and generating private keys.

Overall, the choice of random number generation algorithm or method depends on the specific use case and level of security required. In general, the Bitcoin system relies on a combination of software-based and hardware-based random number generation methods to ensure the security and integrity of the network.

8> thanks -- what sources of entropy are acceptable?

In the context of random number generation for Bitcoin, there are a variety of sources of entropy that can be used to generate high-quality random numbers. Acceptable sources of entropy include:

  1. Hardware events: Hardware events, such as mouse movements, keyboard presses, and network traffic, can be used as sources of entropy. These events are typically gathered by the operating system and added to an entropy pool.

  2. System performance metrics: System performance metrics, such as CPU usage, disk I/O, and memory usage, can also be used as sources of entropy. These metrics can be measured by the operating system or by specialized software tools.

  3. Environmental variables: Environmental variables, such as temperature, humidity, and air pressure, can be used as sources of entropy. These variables can be measured using specialized hardware sensors.

  4. User input: User input, such as mouse movements or key presses, can also be used as a source of entropy. This is particularly useful in situations where high-quality randomness is needed, such as when generating private keys.

  5. Hardware random number generators: Hardware random number generators, such as those based on radioactive decay or thermal noise, can be used as a source of entropy. These devices are typically more secure than software-based sources of entropy, as they are less vulnerable to attacks that can compromise the entropy pool.

Overall, the key requirement for acceptable sources of entropy is that they must be unpredictable and statistically independent. The more diverse the sources of entropy, the better the quality of the random numbers that can be generated. In addition, the entropy must be mixed and combined using secure algorithms to ensure that the output is as random and unpredictable as possible.

9> thanks -- what sources of entropy are unacceptable?

In the context of random number generation for Bitcoin, there are some sources of entropy that are considered unacceptable or less secure. These sources of entropy include:

  1. Deterministic algorithms: Algorithms that generate predictable or repeatable outputs, such as simple arithmetic operations or time-based algorithms, are not considered acceptable sources of entropy.

  2. Low-entropy sources: Low-entropy sources, such as system clock values or network packet timestamps, are generally not considered sufficient sources of entropy on their own. These sources of entropy may be predictable and subject to manipulation by attackers.

  3. Insufficiently mixed data: Entropy that is not properly mixed and combined can result in biased or predictable outputs. It is important to ensure that entropy from different sources is combined in a way that ensures the output is as random and unpredictable as possible.

  4. Weakly seeded random number generators: Random number generators that are not properly seeded with high-quality entropy can generate predictable or insecure outputs. It is important to use secure methods for seeding random number generators, such as hardware-based sources of entropy.

  5. Insecure or compromised hardware: Hardware devices that are insecure or compromised can be a source of weak or predictable entropy. It is important to use hardware that is designed to provide high-quality and secure sources of entropy.

Overall, the key requirement for acceptable sources of entropy is that they must be unpredictable, statistically independent, and properly mixed and combined to ensure that the output is as random and unpredictable as possible. It is important to use a combination of software-based and hardware-based sources of entropy to ensure that the system is as secure and reliable as possible.

Dependencies

~87MB
~785K SLoC