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

Skip to content

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

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