[tor-reports] Isis' June Report

Sat Jul 14 01:40:07 UTC 2012

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hey all,

[CC'd to tor-dev and tor-internal, because I'm not sure who is subscribed to
the new list yet.]

STATUS REPORT 2012 06
- ---------------------

[tl;dr: * Rio de Janiero
        * Reverse Engineering
        * Some OONI development
        * A janky IRC AI for querying the Onionoo API
        * Bananaphone pluggable transport development
        * A possible .onion petname system via RFC1751
        * Firenze & Roma
        * There's a Python bytebeat song at the end of this message ]

I spent the first week this month in Rio, and then in jetlag recovery. Rio, as
I mentioned in my last status report, was awesome, and I was fortunate to meet
several new amazing people working to both in policy and tech fields to
improve human rights.

I spent another two-ish weeks reverse engineering and analysing other
censorship/surviellance detection software (firmware in Project Bismark's
case), which surprisingly included little of the banal repetition or
frustration that RE work sometimes has. [1, 2, 3, 4] Also, researching tests
to write for OONI, which included a lot of time figuring out answers to obscure
networking questions.

I spent some time in OONI development, but didn't get much time for that
because our deliverable this month was research and planning oriented. I read
several papers, talked to quite a few grad students and professors in the
field, and then read a whole lot more papers. With some exceptions, most
previous work in censorship detection is either more net-neutrality and
network anomaly focused, or is technically superficial, i.e. tools which
merely check if a webpage is available without in-depth analysis of the
blocking mechanisms. Without making things overly-complicated, I would
obviously like to favour more in depth blocking/censorship mechanism
discovery, as I believe this will provide better data for the design of
circumvention tools. Though, ellaboration of censored content is also useful
for generating additional media attention towards trespasses on freedom of
information.

For funsies, I started making an IRCbot (don't worry, it's more "practical"
than hellais' gunnerbot, though far less entertaining and with little
potential for channel facilitation), written in Twisted Python (which helped
me become more familiar with the framework), which listens to nicks for
questions about specific Tor nodes and queries the Onionoo API to return
statistics and information to the channel. I've discovered that I detest JSON,
even though the format looks quite pretty. I'm working on making the bot a bit
smarter before I put it anywhere public; I'd like it to:

    * Store node information in a saner way, so as not to permit hammering
      onionoo.
    * Contain a Tor instance for retrieval of titles of .onion addresses.
    * Be capable of, when a user PMs it, taking the user's email address
      (phone numbers could also be used, in the 18003824968 at eviltele.com
      format for SMS) and storing it in a way that the server cannot read, but
      allowing the bot to use it to basically send a crontab report for
      node(s). Sort of the IRC equivalent of signing up for tor-weather.
    * Implement some sort of machine learning to better interact with nicks,
      for example, one should be able to ask "I wonder which Tor nodes still
      allow SMTP on port 25?", and the bot should be able to figure out the
      correct query to discover that information. Currently, one has to type
      "node details noise", for example, to get a detailed report on all the
      noisebridge/noisetor nodes. This implementation could start as a simple
      ############hidden markov model, just to make queries less commandliney.

Also, RFC1751 [5], is about deriving human memorable information from apparently
random sources, and there's an implementation of it in Python, if you do:

    In [1]: from Crypto.Util import RFC1751

    In [2]: RFC1751.key_to_english??

    def key_to_english (key):
        """key_to_english(key:string(2.x)/bytes(3.x)) : string
        Transform an arbitrary key into a string containing English words.
        The key length must be a multiple of 8.
        """
        english=''
        for index in range(0, len(key), 8): # Loop over 8-byte subkeys
            subkey=key[index:index+8]
            # Compute the parity of the key
            skbin=_key2bin(subkey) ; p=0
            for i in range(0, 64, 2): p=p+_extract(skbin, i, 2)
            # Append parity bits to the subkey
            skbin=_key2bin(subkey+bchr((p<<6) & 255))
            for i in range(0, 64, 11):
                english=english+wordlist[_extract(skbin, i, 11)]+' '

        return english[:-1]                 # Remove the trailing space

Which I believe their implementation is flawed, specifically in the calculation
of the parity bits [6], so I've played with rewriting that, both for a potential
.onion address petname system, and for variants of the bananaphone pluggable
transport.

Ah, and then, of course, I went to the dev meeting in Florence, and I saw most
of you there. It was good to meet several people for the first time in person,
most especially athena (hell yeah other female-bodied gothy Tor devs who nerd
out on HEP theory!), phw, lunar, and shondoit.

Then I went with some folks to a friend's beautiful house in the Tuscan
countryside, which I've visited before (that friend's family is amazing, and
their house is this ginormous 15th century farmhouse manor surrounded by
organic orchards, gardens, and vineyards). While there, myself and the two
other OONI devs had a bunch of meetings and conversations, basically for two
days straight, concerning OONI things and working on the FOCI '12 paper.

Now I'm severely jetlagged again, and this status report is too long.

<(A)3
isis agora lovecruft
python -c'import sys;[sys.stdout.write(chr(((~t>>2)*(2+(42&t*((7&t>>10)*2) \
)<(24&t*((3&t>>14)+2))))%256))for t in xrange(2**19)]'|aplay

[1] https://trac.torproject.org/projects/tor/ticket/6181
[2] https://trac.torproject.org/projects/tor/ticket/6184
[3] https://trac.torproject.org/projects/tor/ticket/6185
[4] https://trac.torproject.org/projects/tor/ticket/6187
[5] https://tools.ietf.org/html/rfc1751
[6] _extract essentially is:
    def _extract(key, start, length):
        k = key[start:start+length]
        return reduce(lambda x,y: x*2+ord(y)-48, k, 0)

which obviously because skbin='00'||'01'||'10'||'11' the output of _extract is
1||2||3||4 accordingly, which is not strictly a computation of parity.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJQAM33AAoJEKOttnos24s1ShwP/3XYrnof4gtSmkN2RC2AGdDh
Hhqzz6uHo1PbAu1LC0wU2udM9ylO52HdLtFucYvxlMOa/A6Q2awwPca2SA5i42Ma
dMxmbQ6C/fmaAdwz2Lmi7YDs0i7dmdUxj5BBXlSpyZtApuUnZ3ILhy312tTssaSK
GbN/eAX0P77UPUoYr7n2jLqXmwFixBQt0W66WzHTYt/aefLfDdQ/js7UCdp19idC
LP02Xo2g1oe4zKVTJxO+YrRfPrwrTijHMy+muJD8dhxzXfWGUZrAejGxHZnO1sGl
qpOMWoLtsSz1JDRReHkJxnBcBiBlNFMXBhe1wPXe1PE+E4W6lpSIt2Wm/HZ9zspP
LCjvENC7WxhTowqPg+umWRF7TNugRufDpwoBncGJtqsyGZyGMrnG1hFOfTUmIk7L
wS2PoP1oC2Esgemm9r+nCNzlPTcpRBzNtZg4lp8kCrR4RalOIGEV7nxFIR/10lGc
c6pEdi12XurDt+MfAw8sDMd8mka7HNIb9xnI2MwXSJHrQdFf2qcWdjpakttUAdT/
0weY5NxfQ7yUwsxaO/veLWRi0Roq3U0kiqBLvbFegEA2cMsEcOxA2Y6eHX7jhoQi
0eP/VjBqNVS3pSVfC8dD2g5SRM4FTZo8Qrp/e7U27X32e+EA93Z7DpuDfzceApCY
TiLUDcGpuFX5Sp1XGDNY
=MIzu
-----END PGP SIGNATURE-----