Skip to content
GitHub no longer supports this web browser. Learn more about the browsers we support.
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

Timing of block downloads leaks whether or not any notes belonging to the wallet were discovered #71

Open
defuse opened this issue Jan 16, 2020 · 1 comment
Assignees

Comments

@defuse
Copy link
Contributor

@defuse defuse commented Jan 16, 2020

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:

  1. Download new blocks,
  2. process those blocks, taking an amount of time that depends on how many notes belong to this wallet,
  3. wait a fixed length of time,
  4. make a request to lightwalletd for more new blocks.

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.

@pacu pacu self-assigned this Jan 17, 2020
@pacu

This comment has been minimized.

Copy link
Contributor

@pacu pacu commented Jan 17, 2020

@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 Timer is not a real-time timer after all and depends on a run loop. I think that unless we can find more info on this, we will have to settle with random jitter for now.

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?

This was referenced Jan 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.