I2P Address: [http://git.idk.i2p]

Skip to content
Snippets Groups Projects

Patches all INMP.add() calls to use replay "Contexts" specific to where they were called from.

Merged idk requested to merge i2p.i2p.2.2.1-xor-messageIDs-as-interface-change into master

This patch applies a random long "msgIDXor" value to the messageID by XOR'ing it with the original messageID in every place where the add() function is called. This includes places like the SendMessageDirectJob, which is created as a job in a parent class and which runs sort of "ephemerally" so the job has to get the msgIDXor value must be set by the parent when the job is instantiated, or else it would break the replay protection entirely. Even more complicated is the HandleFloodfillDatabaseStoreMessageJob and HandleFloodfillDatabaseLookupMethodJob, which are handled by the respective FloodfillDatabase*MessageHandler, which are instantiated by the router itself. So in those cases, the Handler holds the msgIDXor values long-term, and then they are instantiated when a job is created by the handler with the same values as the handler. As in the previous patch, this creates separate replay "Contexts" for each add call, effectively, each context has it's own replay queue, eliminating messageID-replay information leaks.

This is a very extensive patch and should include all existing INMP.add(,,,) calls.

Edited by idk

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
Please register or sign in to reply
Loading