fix: random state reusage

[gferon]

This includes the fix whisperfish/presage#292 in particular fixing the long-standing issue #234.

Also adjust usage of presage::Store API which is now asynchronous. One possibly negative side-effect is that the UI looks up in the contact names cache in read-only fashion, and only the async part of gurk can populate the cache using the store.

Also fix clippy warnings.

[hrdl-github]

I got another session reset with these changes today. Before trying this build I was running a build based on hrdl-github/presage@8ac1da0, which replaces https://github.com/whisperfish/presage/blob/a8582e5232ce13ae15c84c4634a7226aec943c44/presage/src/manager/registered.rs#L629 and https://github.com/whisperfish/presage/blob/a8582e5232ce13ae15c84c4634a7226aec943c44/presage/src/manager/registered.rs#L1199, among others.

[boxdot]

@hrdl-github I don't see why cloning the rng is a problem. The cloned rng is neither Send nor Sync, so it can be only used on the same thread it was cloned on. Also the thread_rng function actually just clones the thread local rng variable. It seems to me that this code is equivalent.

edit: Ok, the difference is that in presage StdRng is used and in your branch a ThreadRng.

[boxdot]

This explains a lot

use rand::rngs::StdRng;
use rand::{RngCore, SeedableRng};

fn main() {
    let mut rng = StdRng::from_seed([0; 32]);
    let mut rng2 = rng.clone();

    println!("{:?}", rng.next_u64());
    println!("{:?}", rng2.next_u64());
}

Output

6050961064690644123
6050961064690644123

[hrdl-github]

The rng in https://github.com/whisperfish/presage/blob/a8582e5232ce13ae15c84c4634a7226aec943c44/presage/src/manager/registered.rs#L629 is used in https://github.com/whisperfish/presage/blob/a8582e5232ce13ae15c84c4634a7226aec943c44/presage/src/manager/registered.rs#L658, where it gets used by libsignal-service-rs in https://github.com/whisperfish/libsignal-service-rs/blob/6401dc34872a5f0c2fba32c1f136d98ccf3dd418/src/cipher.rs#L99, then in https://github.com/whisperfish/libsignal-service-rs/blob/6401dc34872a5f0c2fba32c1f136d98ccf3dd418/src/cipher.rs#L231, and finally by libsignal in https://github.com/signalapp/libsignal/blob/e46841ea2c1ad03bc5113eba267ac1543689d031/rust/protocol/src/session_cipher.rs#L271, https://github.com/signalapp/libsignal/blob/e46841ea2c1ad03bc5113eba267ac1543689d031/rust/protocol/src/session_cipher.rs#L443, https://github.com/signalapp/libsignal/blob/e46841ea2c1ad03bc5113eba267ac1543689d031/rust/protocol/src/session_cipher.rs#L585, and finally at https://github.com/signalapp/libsignal/blob/e46841ea2c1ad03bc5113eba267ac1543689d031/rust/protocol/src/session_cipher.rs#L661, where the duplicate ratchet key us created.

I don't have much experience with cryptographic RNGs, but I can imagine the thread_rng having side effects while the StdRng is deterministic and without side effects.

[boxdot]

Thread rng uses (current impl in rand) the os rng. But more important, it uses always the same thread local instance. So, on the same thread cloning this rng is fine, different clones still point to the same instance. However, the StdRng (current impl) is a chacha rng. Cloning it just clones its state. And different clones produce the same sequence of random numbers.