I really appreciate the resumption. Whatever mechanisms wireguard introduces to handle non-RTC devices with limited flash-write cycles (which far most of the openWrt community uses) would significantly ease the configuration of every-even-ntp-traffic-secured networks.
Regarding > Initiation of a wireguard > tunnel for those devices would be: read last counter to variable X, > increment last counter, store incremented counter to flash, tell > wireguard to use X as basetime. Do you mean update counter to flash for each peer for each handshake? That may again result in a lot (10..100++ ???) of write cycles per day, no? Otherwise, if done only once per overall wireguard initialization then incrementing last counter by one would not be enough to ensure that already used SQNs are not used again after a reboot. Incrementing by e.g. 16000 (corresponding 16ms in real time) would allow 16k handshakes before the stored value had to be updated again. Wireguard could even delay first handshake by 16ms to 100% ensure that SQNs have never be used before. Then, by setting system base time to stored counter value on wireguard init, and > choose a per-peer base > time for the first handshake, and then simply increment that on each > handshake would be sufficient for our use case. Just important that the peer base time used for all peers is always given by the system base time when wireguard initialized (and NOT the current time when the handshake is made). Otherwise, an unexpected reboot of the system after >16ms may again lead to re-used handshake SQNs. On 04.02.19 15:56, Jason A. Donenfeld wrote: > An update on this old thread: > > The only requirement for the "timestamp" field is that it's > monotonically increasing. I've been mulling over some improvements to > the current situation of just sticking a nanosecond resolution > timestamp in there raw, after discussing with Jann a few months ago > and then with Ivan the last two days at FOSDEM. > > First, it's quite trivial to whiten that by only allowing a resolution > of 16 or so ms, which might mitigate various unrelated sidechannels > that think they have an oracle in WireGuard. > > Second, both Ivan and Jann have suggested that rather than always > adding a fresh timestamp, we should instead choose a per-peer base > time for the first handshake, and then simply increment that on each > handshake (making sure that the stamp never exceeds the current time). > While we're holding off on new features and nobs and whatnot until > post kernel merge, this would then enable us to potentially add a > specialized option for manually setting the base time. It would by > default remain the time, as it is now, since that's almost always a > reasonable decision. But for devices without an RTC and whose flash > chips prohibit writing out a new timestamp once a second or minute or > whatever, this would allow, instead, to just write out a counter once > per boot, which is much more reasonable. Initiation of a wireguard > tunnel for those devices would be: read last counter to variable X, > increment last counter, store incremented counter to flash, tell > wireguard to use X as basetime. I think this dance should handle a lot > of the issues discussed in this thread. > > Third, Ivan suggested that we actually add a blinding factor to the > timestamps, simply by adding HASH(label||private||public) or similar > to the stamp itself. I'll need to think carefully about the crypto > before committing to anything, but this kind of transformation does > not seem infeasible and might lessen a potential infoleak. A good > idea, in other words. > _______________________________________________ > WireGuard mailing list > [email protected] > https://lists.zx2c4.com/mailman/listinfo/wireguard > _______________________________________________ WireGuard mailing list [email protected] https://lists.zx2c4.com/mailman/listinfo/wireguard
