Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use chacha in get_secure_random_bytes() #1974

Merged

Conversation

danielgranhao
Copy link
Contributor

@danielgranhao danielgranhao commented Jan 20, 2023

Addresses #1958

lightning/src/chain/keysinterface.rs Outdated Show resolved Hide resolved
lightning/src/chain/keysinterface.rs Outdated Show resolved Hide resolved
Copy link
Contributor

@tnull tnull left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Github won't let me get there, but note that rand_bytes_unique_start is still initialized but now unused:

https://github.com/danielgranhao/rust-lightning/blob/a512d3dda038aec465122aeae2de4844c4cacfca/lightning/src/chain/keysinterface.rs#L1020-L1023

@danielgranhao
Copy link
Contributor Author

@tnull Thank you for your comments. Somehow I didn't notice the unused value warnings. In d3f14e7 I also removed rand_bytes_unique_start.

I'm still missing fixing the failing test ln::functional_tests::test_duplicate_payment_hash_one_failure_one_success(). I will try to look a bit more into it, but if anybody has any intuition about the problem, suggestions on what to look for would be highly appreciated!

@TheBlueMatt
Copy link
Collaborator

#1984 should fix it :)

Comment on lines 1021 to 1036
let mut nonce = Vec::new();
nonce.append(&mut starting_time_secs.to_be_bytes().to_vec());
nonce.append(&mut starting_time_nanos.to_be_bytes().to_vec());
let chacha = Mutex::new(ChaCha20::new(seed, &nonce));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can avoid three vec allocations by having a fixed array and copying the bytes into it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! I've changed to that approach in fac7b4e.

@danielgranhao danielgranhao force-pushed the speed-up-secure-random-byte-gen branch 3 times, most recently from d943b28 to 17860ac Compare January 25, 2023 23:03
rand_bytes_unique_start.input(&starting_time_nanos.to_be_bytes());
rand_bytes_unique_start.input(seed);
let mut rand_bytes_unique_start = [0u8; 32];
rand_bytes_unique_start[..8].copy_from_slice(&starting_time_secs.to_be_bytes());
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to hash seed in here somehow. IMO we should keep it as a hash, basically the way it was and just complete the hash rather than leaving it as an unfinished engine.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, was thinking we may just want to restore and use the original rand_bytes_unique_start as the ChaCha seed?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea, restore the old code but complete the hash.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, if I understood you correctly, this is what you propose -> 6472af6


for _ in 1..5 {
let keys_manager_clone = Arc::clone(&keys_manager);
thread::spawn(move || {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You have to join these threads at the end, no?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep, ty! Applied in 34fa5af

rand_bytes_child_index: AtomicUsize,
rand_bytes_unique_start: Sha256State,
rand_bytes_unique_start: [u8; 32],
rand_bytes_index: AtomicUsize,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be a util::atomic_counter::AtomicCounter.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Applied in 6472af6

@danielgranhao
Copy link
Contributor Author

I've rebased to take in the changes from #1984. I've added d08d4f8 just to check that fixing test_bump_penalty_txn_on_revoked_htlcs will fix the remaining CI checks. I suppose it needs an improvement similar to the one on test_duplicate_payment_hash_one_failure_one_success.

@TheBlueMatt
Copy link
Collaborator

LGTM, will let tnull take a look.

Copy link
Contributor

@tnull tnull left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, repeated the benchmarks locally, which drew a pretty clear picture:

| Threads | Method         | Time (ns) |
|---------+----------------+-----------|
| 1       | Hashing        | 1,805,139 |
| 1       | ChaCha/Mutex   | 6,308     |
| 1       | ChaCha/Counter | 10,725    |
| 3       | Hashing        | 1,875,495 |
| 3       | ChaCha/Mutex   | 144,687   |
| 3       | ChaCha/Counter | 18,778    |
| 5       | Hashing        | 1,898,584 |
| 5       | ChaCha/Mutex   | 92,116    |
| 5       | ChaCha/Counter | 40,465    |
|---------+----------------+-----------|

I'd say if we're confident in the counter method, it is probably the way to go.

That said, I'd also be happy to with the Mutex variant, as it's more straight forward, the performance difference is really not that big and realistically the kind of lock contention simulated in the benchmark is really unlikely to happen in production. Note however that in this case we may want to throw in a Sha256 for good measure, instead of using the seed directly.

nonce[..8].copy_from_slice(&starting_time_secs.to_be_bytes());
nonce[8..12].copy_from_slice(&starting_time_nanos.to_be_bytes());
let chacha = Mutex::new(ChaCha20::new(seed, &nonce));
let mut rand_bytes_unique_start = Sha256::engine();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Rather than shadowing the variable, can we maybe rename this rand_engine_unique_start?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, applied in 1456770.

@TheBlueMatt
Copy link
Collaborator

I'm more comfortable using the counter method - the ChaCha in-crate rolls doesn't handle chacha counter rollover, meaning it breaks at u32::MAX * 64 bytes, which, okay, we're not gonna hit, but still, the version with the counter doesn't.

@TheBlueMatt
Copy link
Collaborator

Please also rebase/squash the fixup commit at the end into the appropriate commit.

@danielgranhao danielgranhao marked this pull request as ready for review January 26, 2023 19:06
Copy link
Contributor

@tnull tnull left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, I think I'm ACK after the tests pass.

TheBlueMatt
TheBlueMatt previously approved these changes Jan 26, 2023
lightning/src/chain/keysinterface.rs Show resolved Hide resolved
@TheBlueMatt TheBlueMatt merged commit d4de913 into lightningdevkit:main Jan 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants