Opened 8 years ago

Closed 6 years ago

#5384 closed project (not a bug)

Image Steganography for BridgeFinder

Reported by: seaman Owned by: asn
Priority: Very Low Milestone:
Component: Circumvention/BridgeDB Version:
Severity: Keywords: bridge-finder, needs-proposal
Cc: isis Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Regarding the design of BridgeFinder, I suggest that it contains a plugin system in order to allow different inputs. In https://trac.torproject.org/projects/tor/ticket/5096 it is proposed to use QR codes but I think that this should not be the only option.

One problem with QR codes is that they are clearly describing something that is hidden. So instead I propose an additional plugin that does steganography. In more detail I'm thinking of image steganography (although at a later stage one could add audio/video or others (random bytes)).

The basic idea:
A list of bridge addresses get sent to a trusted person. This person encodes the bridge addresse(s) into an image and sends them to a friend. This friend then decodes the bridge address contained in the image and uses it to connect to Tor (via BridgeFinder).

A bit more specific:
# The encoding will not alter the image signficantly so that it appears to be a valid unsuspicious data exchange (e.g. a holiday snapshot, avatar, signature).

# To encode the image a password needs to be entered that is known by both ends. Password suggestions:
# # a complex password known by both parties
# # name of a significant object in the image (this would allow external people easier access, on the other hand it would also allow the use of image sharing websites and blogs, automatic algorithms (object detection) to treat large amounts of images would be difficult).
# # I can also think of images that contain no password at all. But of course that would make it easier for censors to find them and block the bridges.

# The decoding process must be computationally expensive in order to avoid dictonary attacks.

# The algorithm for decoding contains automatic error correction as well as data verification.

Let me know what you think about this idea. If it is worth pursuing I can do the coding.

Child Tickets

Change History (4)

comment:1 Changed 6 years ago by asn

Component: Pluggable transportBridgeDB

Moving this to the BridgeDB component, since it's more related to bridge distribution than PTs.

comment:2 in reply to:  description Changed 6 years ago by isis

Cc: isis added
Keywords: bridge-finder needs-proposal added
Milestone: Tor: unspecified
Status: newneeds_information

Replying to seaman:

Regarding the design of BridgeFinder, I suggest that it contains a plugin system in order to allow different inputs. In https://trac.torproject.org/projects/tor/ticket/5096 it is proposed to use QR codes but I think that this should not be the only option.


BridgeFinder's design is outdated, and, as far as I know, no one ever started implementing it. :(

The current plan is to move towards automation, such that TorLauncher is able to request bridges from BridgeDB at some regular interval (or when the ratio of non-working torrc bridge lines to total torrc bridge lines is too high), and then receive bridge lines in response. The user shouldn't have to see anything, or do anything, other than click "I need to use bridges" and "Please use obfs3 bridges", etc.

One problem with QR codes is that they are clearly describing something that is hidden. So instead I propose an additional plugin that does steganography. In more detail I'm thinking of image steganography (although at a later stage one could add audio/video or others (random bytes)).


As I understood it, the QR codes were meant to help make it easier for people to input bridge lines (which contain bridge fingerprints now) into their phones, without squinting at text or trying to use a tiny phone keyboard.

That aside, there is no steganography which is undetectable. People have already inquired about this on IRC. I've given the same answer several times. Sorry to let you down, but I don't think there will ever exist steganographic algorithms which have non-extractable grammars:

2014-03-28, irc.oftc.net#tor-dev:

06:06     isis ) i will tell you right off the bat that there is no such thing as
                 perfect steganography, due to the reduction of mimic functions
                 based upon Huffman coding or dual Tunstall coding, to (at best)
                 an optimal Huffman coding where the parser's grammar is still
                 extractable from the message space
06:07     isis ) even constructions based on Context Free Grammars are still
                 extractable, and must be, this being essentially the difference
                 between steganography and cryptography
06:08     isis ) which is to say, "yeah, sure, use F5, it doesn't matter because
                 there is no such thing as a perfect steganographic system"
06:09     isis ) not to discourage you from implementing J3 or anything. :)


The basic idea:
A list of bridge addresses get sent to a trusted person. This person encodes the bridge addresse(s) into an image and sends them to a friend. This friend then decodes the bridge address contained in the image and uses it to connect to Tor (via BridgeFinder).

A bit more specific:
# The encoding will not alter the image signficantly so that it appears to be a valid unsuspicious data exchange (e.g. a holiday snapshot, avatar, signature).

# To encode the image a password needs to be entered that is known by both ends. Password suggestions:
# # a complex password known by both parties
# # name of a significant object in the image (this would allow external people easier access, on the other hand it would also allow the use of image sharing websites and blogs, automatic algorithms (object detection) to treat large amounts of images would be difficult).


There is a famous case of Google's SafeSearch blocking an image of two pigs standing side-by-side, taken from above, because it sort of looked like someone's naked butt. While the automated use of these types of image processing may make funny mistakes, Google and Baidu already have (and use!) large-scale object/facial recognition for any images which have been made available to their crawlers.

# # I can also think of images that contain no password at all. But of course that would make it easier for censors to find them and block the bridges.

# The decoding process must be computationally expensive in order to avoid dictonary attacks.

# The algorithm for decoding contains automatic error correction as well as data verification.

Let me know what you think about this idea. If it is worth pursuing I can do the coding.


This all sounds cool, and despite my concerns listed above, it's a neat idea (esp. if someone else maintains it). My major, blocking concern is w.r.t. overall user interaction design: Getting bridge lines is already confusing for users; we should be automating it, not adding extra manual steps into the process.

comment:3 Changed 6 years ago by isis

Priority: normaltrivial

comment:4 Changed 6 years ago by isis

Resolution: not a bug
Status: needs_informationclosed

Closing as 'bot a nug'; feel free to reopen.

Note: See TracTickets for help on using tickets.