[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
SURB integration patches
As I think I mentioned a few months back, I've been working on teaching
Petmail how to use Mixminion as a transport layer. The interesting part about
this is that once they have been bootstrapped, two Petmail agents can
communicate with each other entirely through SURBs. Each agent can keep track
of which SURBs are outstanding, and use their remaining supply to keep the
other stocked with a reasonable quantity.
In writing the code to support this mode of operation, I've found I need a
few more things out of mixminion's SURB support. Basically I need to be able
to track the lifetime of each SURB separately, which means knowing their
handles when I generate them, remembering which ones I've sent to the other
agent, and knowing which was used for inbound messages. I also need to know
how many SURBs I will need for any particular message I want to send.
1: knowing the SURB "tag" (aka "seed", aka "decoding handle") for each SURB
generated by "mixminion generate-surb": the following patch adds a LOG.info
message to emit the tag for each new SURB generated:
Index: lib/mixminion/BuildMessage.py
===================================================================
RCS file: /home/minion/cvsroot/src/minion/lib/mixminion/BuildMessage.py,v
retrieving revision 1.73
diff -u -r1.73 BuildMessage.py
--- lib/mixminion/BuildMessage.py 23 Mar 2004 00:07:02 -0000 1.73
+++ lib/mixminion/BuildMessage.py 4 May 2004 07:09:27 -0000
@@ -9,6 +9,7 @@
import operator
import sys
import types
+import binascii
import mixminion.Crypto as Crypto
import mixminion.Fragments
@@ -296,8 +297,10 @@
prng = Crypto.AESCounterPRNG(Crypto.sha1(seed+userKey+"Generate")[:16])
- return _buildReplyBlockImpl(path, exitType, exitInfo, expiryTime, prng,
- seed)[0]
+ replyblock, secrets, tag = _buildReplyBlockImpl(path, exitType, exitInfo,
+ expiryTime, prng, seed)
+ LOG.info("Created reply block %s" % binascii.b2a_base64(tag))
+ return replyblock
def checkPathLength(path1, path2, exitType, exitInfo, explicitSwap=0,
suppressTag=0):
2: learning which SURBs were used for each inbound message: The
'Decoding-Handle' field of the ascii-armored encrypted message contains this.
It ought to be identical to the text emitted by the above patch.
3: counting how many SURBs will be needed for a given message: The following
patch adds a "mixminion count-surbs" command, which takes the same
message-source arguments as "mixminion send" (i.e. -i inputfile, otherwise it
reads stdin). It performs the same message compression/fragmentation
algorithm as "mixminion send" does, but then simply prints the number of
payloads generated, which is the same as the number of SURBs required.
Petmail needs this to a) determine if we have enough SURBs to actually send
the message (while maintaining a reserve to restock our peer), and b) keep
track of which SURBs were actually used.
% mm count-surbs -i /vmlinuz
Mixminion version 0.0.8alpha1
This software is for testing purposes only. Anonymity is not guaranteed.
Message length 937601 will require 66 SURBs
An alternative approach would be to put all the SURBs we're willing to spend
in a file and then let mixminion use whatever it needs. However, petmail
would still need to find out how many were used so it knows when to request
more, and it felt like the status reporting to accomplish this would be
uglier than a "count-surbs" command.
Index: lib/mixminion/Main.py
===================================================================
RCS file: /home/minion/cvsroot/src/minion/lib/mixminion/Main.py,v
retrieving revision 1.72
diff -u -r1.72 Main.py
--- lib/mixminion/Main.py 6 Mar 2004 00:04:38 -0000 1.72
+++ lib/mixminion/Main.py 4 May 2004 07:11:36 -0000
@@ -127,6 +127,7 @@
"generate-surbs" : ( 'mixminion.ClientMain', 'generateSURB' ),
"inspect-surb" : ( 'mixminion.ClientMain', 'inspectSURBs' ),
"inspect-surbs" : ( 'mixminion.ClientMain', 'inspectSURBs' ),
+ "count-surbs" : ( 'mixminion.ClientMain', 'countSURBs' ),
"flush" : ( 'mixminion.ClientMain', 'flushQueue' ),
"inspect-queue" : ( 'mixminion.ClientMain', 'listQueue' ),
"clean-queue" : ( 'mixminion.ClientMain', 'cleanQueue' ),
Index: lib/mixminion/ClientMain.py
===================================================================
RCS file: /home/minion/cvsroot/src/minion/lib/mixminion/ClientMain.py,v
retrieving revision 1.178
diff -u -r1.178 ClientMain.py
--- lib/mixminion/ClientMain.py 2 May 2004 18:45:15 -0000 1.178
+++ lib/mixminion/ClientMain.py 4 May 2004 07:11:37 -0000
@@ -1775,6 +1775,37 @@
finally:
surblog.close()
+_COUNT_SURBS_USAGE = """\
+Usage: %(cmd)s [options]
+
+Options:
+ -h, --help Print this usage message and exit.
+ -i <file>, --input=<file> Read the message from <file>. (Defaults to stdin.)
+
+EXAMPLES:
+ Report how many SURBs are necessary to send the message in file <data>
+ %(cmd)s -i data
+""".strip()
+
+def countSURBs(cmd, args):
+ options, args = getopt.getopt(args, "hi:",
+ ["help", "input=", ])
+ inFile = '-'
+ for opt,val in options:
+ if opt in ('-i', '--input'):
+ inFile = val
+ if inFile == '-':
+ if os.isatty(sys.stdin.fileno()):
+ print "Enter your message. Type %s when you are done."%(
+ EOF_STR)
+ message = sys.stdin.read()
+ else:
+ message = readFile(inFile)
+ payloads = mixminion.BuildMessage.encodeMessage(message, 0, "")
+ print "Message of length %d will require %d SURBs" % (len(message),
+ len(payloads))
+
+
_FLUSH_QUEUE_USAGE = """\
Usage: %(cmd)s [options] [servername] ...
-h, --help Print this usage message and exit.
I think these two enhancements (or something similar) will give me enough to
make petmail into a reasonable mixminion front-end. I still have to figure
out fragmentation but I think those pieces are already in place. (one thing
that would be helpful would be if the "mixminion decode" command would, when
handling a fragment, announce the msgid which owns the fragment.. this would
make it easier for me to avoid the multiple-nym-one-owner attack).
thanks,
-Brian