Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upTiming of block downloads leaks whether or not any notes belonging to the wallet were discovered #71
Comments
Merged
This comment has been minimized.
This comment has been minimized.
|
@defuse I can't assure that timers will fire on 0 20 40 exactly. Apple requieres a minimum tolerance of delay for the timer, since if we manage to set a 0 20 40 Timer scheme (there's no direct api for it) and the recommended 10% offset tolerance that Apple recommends, the offset for each user becomes information as well, doesn't it? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This issue was originally discovered and reported by Florian Tramèr. I'm making it public since no users are currently at risk.
The issue is that the SDK will:
A passive network adversary can measure the time between (1) and (4) to determine whether any notes in the blocks belonged to the wallet. To fix this, either
a. Decouple the network code from the block processing code, such that downloaded blocks are queued up to be processed on a separate thread and the processing won't affect the timing of network requests,
b. Florian's suggestion, to request blocks at absolute time intervals, i.e. instead of sleeping for 20 seconds between requests, request new blocks at times *:00, *:20, *:40. In order for this to not leak information, the block processing MUST always complete before the next request is due to be made.
I recommend (b) since it's easier and we're about to run into even harder side-channel challenges with memo downloading and mempool access.