chore(boundary): salt_sharing canister implementation
#3650
Conversation
nikolay-komarevskiy
force-pushed
the
komarevskiy/salt-canister-interface
branch
2 times, most recently
from
23696f2 to
0227c73
Compare
nikolay-komarevskiy
force-pushed
the
komarevskiy/salt-canister-interface
branch
from
0227c73 to
b788460
Compare
| pub static LAST_SALT_NS: RefCell<StableMap<(), Timestamp>> = RefCell::new(StableMap::init( | ||
| MEMORY_MANAGER.with(|m| m.borrow().get(MEMORY_ID_LAST_SALT_MS)), |
There was a problem hiding this comment.
Mismatch in naming:
LAST_SALT_NS vs. MEMORY_ID_LAST_SALT_MS
| regenerate_salt(); | ||
| } | ||
| // Start salt generation schedule based on the argument. | ||
| if let Some(strategy) = init_arg.salt_generation_strategy { |
There was a problem hiding this comment.
If we set the strategy again, will it cancel the old timer or will it then have two timers: then one from before and the new one?
There was a problem hiding this comment.
When the canister is upgraded all existing timers will be stopped. and should be restarted manually. That's why there is a call to init in the post_upgrade.
rs/boundary_node/salt_sharing/canister/salt_sharing_canister.did
Outdated
Show resolved
Hide resolved
Co-authored-by: r-birkner <[email protected]>
| static RNG: RefCell<ChaCha20Rng> = { | ||
| let mut seed = [42; 32]; | ||
| seed[..8].copy_from_slice(&time().to_le_bytes()); | ||
| RefCell::new(ChaCha20Rng::from_seed(seed)) |
There was a problem hiding this comment.
This is quite predicable; at worst an attacker just has to iterate over timestamps near where they think the canister started.
Getting randomness can be done by accessing the random beacon. This is at least more random than the time. But I'm not sure if other canisters on the same subnet see the same beacon value or not. [Made a query on internal channels on this]
What I'd suggest is modifying the interface such that BN can "contribute" randomness to the canister whenever they contact it, since they have access to "real" randomness. For example by just sending a 256-bit string they generated using their local RNG (/dev/random or whatever). Then the canister takes that input plus the current internal seed, computes SHA-256 of both, then uses that as the new seed value. As soon as 2 or more honest boundary nodes have contacted the canister, the randomness of the canisters state is unknown to everyone except the node providers running that subnet.
There was a problem hiding this comment.
Per @andreacerulli each canister will see a different value for the random beacon so that should be sufficient without having to do a BN randomness contribution scheme like I outlined above
There was a problem hiding this comment.
Interesting idea. That would require the following logic in the canister and nodes:
- collect
N>=2random secrets from nodes viaupdatecalls - generate the final seed based on canister's own secret + N collected secrets
- generate the shared salt based on the final seed and start serving salt
- nodes need additional logic to stop "contributing" and just fetch the shared salt
Provide all API boundary nodes with the same secret salt to anonymize the IP addresses and the sender principals when logging the incoming requests.