You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, the destinations is send and saved plain text. This enables two attacks, which I want to address here:
First of all, it allows other nodes to collect destinations (e.g. for spaming). This issue can be tackled by using a secure hash instead of the plain destination. Because secure hash fucntion are practically irreversible, other nodes won't be able to obtain the destination.
Secondly, other nodes are currently able to monitor how many mails a certain Bote identity gets. I have had two ideas to make this more difficult:
Instead of having just one possible hash per Bote identity, everyone has several hashes, for example by salting them. When sending a mail the client chooses a random salt in the desired range (maybe 4 or 8 bit; the requested salt length could be stored as additonal information in the Bote destination) and uses it as the destination tag of the mail envelop.
The receving client then requests all mails saved with his hashes (this should be done to different times for each hash to make timing-attacks more difficult). The nodes will not be able to know the actual number of received messages as they only see a subset of them.
It might be diserd to have hash collisions (they can be achieved by truncating the actual hash). When several identities have the same hash, a spying node won't be able to say if the message were all meant for the same persone or for several different. When a client wants to obtain his mails, it downloads all mails saved under the hash and then trys to decrypt them. All mails meant for the identity will be decrypted correctly while all others just result in gibberish (or an error).
{
"status": "assigned",
"changetime": "2016-10-26T19:36:06",
"description": "Right now, the destinations is send and saved plain text. This enables two attacks, which I want to address here:\n First of all, it allows other nodes to collect destinations (e.g. for spaming). This issue can be tackled by using a secure hash instead of the plain destination. Because secure hash fucntion are practically irreversible, other nodes won't be able to obtain the destination.\n\n Secondly, other nodes are currently able to monitor how many mails a certain Bote identity gets. I have had two ideas to make this more difficult:\n 1. Instead of having just one possible hash per Bote identity, everyone has several hashes, for example by salting them. When sending a mail the client chooses a random salt in the desired range (maybe 4 or 8 bit; the requested salt length could be stored as additonal information in the Bote destination) and uses it as the destination tag of the mail envelop.\n The receving client then requests all mails saved with his hashes (this should be done to different times for each hash to make timing-attacks more difficult). The nodes will not be able to know the actual number of received messages as they only see a subset of them.\n 2. It might be diserd to have hash collisions (they can be achieved by truncating the actual hash). When several identities have the same hash, a spying node won't be able to say if the message were all meant for the same persone or for several different. When a client wants to obtain his mails, it downloads all mails saved under the hash and then trys to decrypt them. All mails meant for the identity will be decrypted correctly while all others just result in gibberish (or an error).",
"reporter": "sarji",
"cc": "",
"resolution": "",
"_ts": "1477510566215434",
"component": "apps/plugins",
"summary": "Bote: Making tracking by other nodes more difficult",
"priority": "minor",
"keywords": "I2P-Bote",
"version": "0.9.27",
"parents": "",
"time": "2016-10-24T20:55:55",
"milestone": "eventually",
"owner": "str4d",
"type": "enhancement"
}
The text was updated successfully, but these errors were encountered:
str4d
changed the title
Bote: Making tracking by other nodes more difficult (Trac #1867)
Making tracking by other nodes more difficult (Trac #1867)
Apr 18, 2017
Right now, the destinations is send and saved plain text. This enables two attacks, which I want to address here:
First of all, it allows other nodes to collect destinations (e.g. for spaming). This issue can be tackled by using a secure hash instead of the plain destination. Because secure hash fucntion are practically irreversible, other nodes won't be able to obtain the destination.
Secondly, other nodes are currently able to monitor how many mails a certain Bote identity gets. I have had two ideas to make this more difficult:
The receving client then requests all mails saved with his hashes (this should be done to different times for each hash to make timing-attacks more difficult). The nodes will not be able to know the actual number of received messages as they only see a subset of them.
Migrated from https://trac.i2p2.de/ticket/1867
The text was updated successfully, but these errors were encountered: