Re: [tor-bugs] #5384 [BridgeDB]: Image Steganography for BridgeFinder

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#5384: Image Steganography for BridgeFinder
--------------------------+-------------------------------------------
     Reporter:  seaman    |      Owner:  asn
         Type:  project   |     Status:  needs_information
     Priority:  normal    |  Milestone:
    Component:  BridgeDB  |    Version:
   Resolution:            |   Keywords:  bridge-finder, needs-proposal
Actual Points:            |  Parent ID:
       Points:            |
--------------------------+-------------------------------------------
Changes (by isis):

 * cc: isis (added)
 * status:  new => needs_information
 * keywords:   => bridge-finder, needs-proposal
 * milestone:  Tor: unspecified =>


Comment:

 Replying to [ticket:5384 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.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5384#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs