Use a very cautious Rng for deriving longer-lived keys
This MR does several main things:
First, it introduces a "CautiousRng" which combines inputs from several sources, including OsRng, to minimize the likelihood of falling to a vulnerability in any particular one. (This is more than a bit paranoid, but it's what C Tor does.)
Second, it uses "CautiousRng" to generate any key that's going into a KeyMgr. (This is a close approximation to "any long- or medium-term key", though relays may want to consider some other keys "medium-term".)
(That part closes #1898 (closed).)
Third, it adds an "EntropicRng" marker trait to ensure that we don't accidentally use a weaker Rng when generating a managed key.
Merge request reports
Activity
requested review from @gabi-250
assigned to @nickm
@gabi-250, I've given you review because this messes with KeyMgr, and I may have violated some aspect of the KeyMgr philosophy. @dgoulet, you might also have thoughts on this.
a "CautiousRng" which combines inputs from several sources, including OsRng, to minimize the likelihood of falling to a vulnerability in any particular one.
If we turn out to hate this idea, we should instead IMO replace CautiousRng with a wrapper for OsRng that panics on failure, and keep the rest of this branch.
-
Marked as draft: we shouldn't merge till #1902 (closed) is straightened out.
added 11 commits
-
0cdc33f7...b6fee21e - 8 commits from branch
tpo/core:main - 53793d38 - llcrypto: new CautiousRng for constructing long-lived keys
- e5cd04dc - Use CautiousRng for keys going into the KeyMgr.
- 75697f03 - Use an EntropicRng trait to enforce key generation rules.
Toggle commit list-
0cdc33f7...b6fee21e - 8 commits from branch
added 1 commit
- 4e39226c - fixup! Use an EntropicRng trait to enforce key generation rules.
added 1 commit
- 7b8b4323 - fixup! Use an EntropicRng trait to enforce key generation rules.
mentioned in issue #1898 (closed)
crates/tor-llcrypto/src/rng.rs 0 → 10064444 45 impl rand_core::RngCore for CautiousRng { 46 fn next_u32(&mut self) -> u32 { 47 let mut buf = Zeroizing::new([0_u8; 4]); 48 self.fill_bytes(buf.as_mut()); 49 u32::from_le_bytes(*buf) 50 } 51 52 fn next_u64(&mut self) -> u64 { 53 let mut buf = Zeroizing::new([0_u8; 8]); 54 self.fill_bytes(buf.as_mut()); 55 u64::from_le_bytes(*buf) 56 } 57 58 fn fill_bytes(&mut self, dest: &mut [u8]) { 59 let mut xof = Shake256::default(); 20 21 period: TimePeriod, 21 22 revision_counter: RevisionCounter, 22 23 rng: &mut Rng, -
You mean, in favor of just having the method call
rand::rng()? I don't have super strong feelings either way; I can include that in a ticket opened as followup.I would like to keep the
Rngarguments in the hsdesc-encoding functions in tor-netdoc: those functions probably want to retain some determinism for testing.
