@@ -51,6 +51,7 @@ const MEMORY_SIZE: usize = MEMORY_BLOCKS * MEMORY_BLOCKSIZE;
51
51
/// [Jitterentropy](http://www.chronox.de/jent.html) version 2.1.0.
52
52
///
53
53
/// [`OsRng`]: ../os/struct.OsRng.html
54
+ #[ derive( Clone ) ]
54
55
pub struct JitterRng {
55
56
data : u64 , // Actual random number
56
57
// Number of rounds to run the entropy collector per 64 bits
@@ -63,6 +64,22 @@ pub struct JitterRng {
63
64
data_half_used : bool ,
64
65
}
65
66
67
+ // Note: `JitterRng` maintains a small 64-bit entropy pool. With every
68
+ // `generate` 64 new bits should be integrated in the pool. If a round of
69
+ // `generate` were to collect less than the expected 64 bit, then the returned
70
+ // value, and the new state of the entropy pool, would be in some way related to
71
+ // the initial state. It is therefore better if the initial state of the entropy
72
+ // pool is different on each call to `generate`. This has a few implications:
73
+ // - `generate` should be called once before using `JitterRng` to produce the
74
+ // first usable value (this is done by default in `new`);
75
+ // - We do not zero the entropy pool after generating a result. The reference
76
+ // implementation also does not support zeroing, but recommends generating a
77
+ // new value without using it if you want to protect a previously generated
78
+ // 'secret' value from someone inspecting the memory;
79
+ // - Implementing `Clone` seems acceptable, as it would not cause the systematic
80
+ // bias a constant might cause. Only instead of one value that could be
81
+ // potentially related to the same initial state, there are now two.
82
+
66
83
// Entropy collector state.
67
84
// These values are not necessary to preserve across runs.
68
85
struct EcState {
0 commit comments