Skip to content
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

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

Open
str4d opened this issue Apr 16, 2017 · 1 comment
Open

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

str4d opened this issue Apr 16, 2017 · 1 comment

Comments

@str4d
Copy link
Member

str4d commented Apr 16, 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:

  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
Copy link
Member Author

str4d commented Apr 17, 2017

Trac update at 20161026T19:36:06:

  • zzz changed owner from "" to "str4d"
  • zzz changed status from "new" to "assigned"
  • zzz changed summary from "Making tracking by other nodes more difficult" to "Bote: Making tracking by other nodes more difficult"

@str4d str4d removed the str4d label Apr 17, 2017
@str4d 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
@str4d str4d removed this from the eventually milestone Apr 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant