[tor-dev] [Stegotorus] chop server to client handshake and the url dictionary

[Zack Weinberg]

On Tue, Jul 31, 2012 at 9:35 AM, vmon <vmonmoonshine at gmail.com> wrote:
> I'm working on changing how client sends info to the server for
> ApachePayloadServer, according to our discussion. This is how
> it's going to be for now. The server sends a list of file in some
> order to the client at the begining of the conversation. The client
> will send its coded request by chosing a url a from the list and a
> parameter that it sends to that file such as:
>
> /groups/watch.cgi?param=QTwFt25

Sounds good.

> For this I need to send the list of files somewhere to the client. I
> looked at the paper and paper says that on a new link the server will
> send a reply to the handshake of the client with ECDH data. I thought
> there would be a good place to send these data as well. Unfortunately
> I couldn't spot that in the code. Could you please tell me where that
> is happening?

That ... still hasn't been implemented.  *embarrassed*  But that's not
where this should go, anyway.

> Another option is to assign an opcode to this operation, and when the
> client receive that opcode then, it will process the packet differntly
> rather than just write its content in upstream event buffer.

This is what you should do.  Remember how opcodes 128 through 255 are
"reserved for steg modules"?  This is exactly what I had in mind.  The
way it ideally ought to work is going to involve changes to the
chopper as well as your code; I'm not going to have time to do the
chopper end for at least three weeks; if you want to tackle that,
please be my guest, but if you'd rather kludge something in your code
instead, that's fine too.

Here's how it ought to work:

On the receive side, you just need to add a steg method to process a
reserved-for-steg-modules block, taking F and the data payload (in an
evbuffer).  Call it from process_queue when appropriate.

On the transmit side, we would like to send your special block in the
same *cover protocol* message as the server's handshake reply, so we
need a little more complexity than just a "please send this evbuffer
now with this opcode" steg-to-chop callback.  I'm not sure this is the
right API, but what comes to mind is to extend transmit_room so that
it returns a second number, which means "if you send on this
connection next, I want to send Y bytes of additional data". Then
there's a new steg method called something like augment_message, which
gets called in a loop right after we prepare and encrypt the actual
block to transmit.  Each time it fills up an evbuffer with data and
returns a steg-specific opcode; the chopper packs the evbuffer and
opcode into another block and appends it to the block that's about to
be transmitted.  Finally steg_transmit gets the entire message to be
steganographed, which may now consist of several blocks.

> For now I suppose that the client has the list and write the code from
> that point till you give me more info.

It would also be fine if you want to get things working on this
assumption first.

zw