i2p / i2p.i2p-bote

I2P-Bote is a serverless, encrypted e-mail application.
https://i2pbote.xyz
Other
146 stars 44 forks source link

Making tracking by other nodes more difficult (Trac #1867) #84

Open str4d opened 7 years ago

str4d commented 7 years ago

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:

  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. 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.
  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).

Migrated from https://trac.i2p2.de/ticket/1867

{
    "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"
}
str4d commented 7 years ago

Trac update at 20161026T19:36:06: