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

Prevent Traffic Analysis #878

Closed
phime42 opened this issue Feb 28, 2014 · 4 comments
Closed

Prevent Traffic Analysis #878

phime42 opened this issue Feb 28, 2014 · 4 comments

Comments

@phime42
Copy link

phime42 commented Feb 28, 2014

Traffic and metadata analysis can be a danger to everyone who has to communicate securely.
Actually one could very easy look through the traffic and could guess the length of the actual sent text length. I suggest to send a random amount of fill bytes with every message in order to mask the length of the actual messages.
Furthermore, more complicated approaches like #328 come to mind; but especially sending dummy messages and dummy content would severly short battery life and increase network usage.

@generalmanager
Copy link

I think adding random data to the content of some messages isn't going to make the protection against traffic analysys bombproof, because you could just look up in the source code how many bytes is added at max, calculate the average. Combine that with a lot of intercepted encrypted messages and you can make a really good guess how long messages usually are and at least guess things like which languages are spoken.
It may improve protection against making educated guesses like "Alice called Bob 50 minutes ago on an insecure line and wanted to meet an hour later. Now she sent him a short message, maybe she is going to run late, or confirming that she just arrived at the destination" a little, but other metadata like timing , sender and recipient are way more important in modern surveillance.
Your suggestion would just raise the uncertainty about the content a little if the intercepted message were longer. If there were two other messages in the 1 hour timeframe (maybe 1 to Bob, 1 to Carol) possibilities explode.
Maybe she delayed the meeting with Bob, changed the place and invited Carol, maybe she just confirmed to Bob that she got her train and told Carol about the meeting with Bob. Maybe she talks to Carol about her new car...in the first two cases it just became much harder to abduct Alice and Bob at their meeting point without people noticing. Carol may not know anything about their meeting but the adversary can't be sure.

In addition I'm sure that if we keep the number of random messages low (<25/day), the influence on battery drain and transferred data would be so miniscule on both ends that it shouldn't have any noticeable impact.
I'm also positive that the number of people using this feature will be really small - even the number of people ever entering the advanced settings dialog is probably below 1% and only a few high profile or threatened people will use this. In fact, the impact on the network should barely be noticeable.

@phime42
Copy link
Author

phime42 commented Feb 28, 2014

I think adding a random value (or filling it up to certain message lengths, like 0-160 characters, 161-500 characters and 500-1000 characters with a chance of a third that a message with the length of <160 characters is filled up to 500 characters and a message with <500 characters is filled up with up to 1000 characters. most users just send below 160 characters, so most of the traffic is obscured. The random messages could be a deal, though. But it is decision of Moxie and his team whether they say it's security by obscurity and not fitting well into the context of TextSecure or if it's a valuable idea deserving to be part of TextSecure/Whisper.

@kmindi
Copy link

kmindi commented Feb 28, 2014

If there where only fixed sizes which are padded to there would be only an amount of different sized messages. There could be a minimal size, for example 32, then padded to 64, 128 256 512 and 1024, from there it could be padded in 512 steps (to have no exponential growth).
For this one has to take into account the Padding oracle attack (http://en.wikipedia.org/wiki/Padding_oracle_attack) which can be prevented by appending a HMAC.
But prestructured things can make timing attacks more likely.

@moxie0
Copy link
Contributor

moxie0 commented Mar 1, 2014

The SMS transport will always pad messages out to a multiple of the SMS transport size, but that doesn't translate well into the data environment. Additionally, we're using data structures with varints and other dynamic values in them now, so padding is much harder to calculate correctly. I think it's unlikely that we'll incorporate these types of countermeasures before the basic functionality is more stable and under control.

@moxie0 moxie0 closed this as completed Mar 1, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants