-
-
Notifications
You must be signed in to change notification settings - Fork 6.2k
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
Comments
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. 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 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. |
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). |
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. |
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.
The text was updated successfully, but these errors were encountered: