[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: End to end Mixminion issues, with proposed solutions
Dear All,
I agree with most of the document, but allow me to read it a bit more
carefully before I can wholeheartedly embrace it. I still have a few issues
and questions that I have interleaved in the text.
George
On 20 Sep 2002, Nick Mathewson wrote:
> Hello, everyone!
>
> [...]
>
> SENDER:
> B) For FWD messages, the sender generates a 159-bit random number for
> the Tag. For a text message, the sender pads the payload with 00
> bytes. For a binary message, the sender sends 2 size bytes,
> the payload, and random padding up to 28K.
There is a problem here: I do not see how the TAG can be encrypted if the
key of the final recipient is not known. Do we assume that the last hop to
process the message sends only the TAG and the BODY, to the final
recipient? I can see how this can be done using the SMTP delivery type but
we have not specified a way of delivering such messages using the
TLS/TCP/IP transport to clients that listen to for messages.
>
> C) For EFWD messages, the sender generates a 128-bit temporary key K at
> random, and RSA-OAEP encrypts it with the recipient's public key.
> If the encrypted key EK has its MSB=1, the sender generates a new
> key and tries again. Otherwise, the sender uses the first 20
> bytes of EK as the Tag. The payload contains: The remaining bytes
> of EK, followed by the LIONESS encryption (with K) of:
> 2 size bytes,
> the message
> Random padding up to 28K.
>
> {{This is the iffy part. I know that RSA-encrypted data is
> distinguishable from random numbers, since the encrypted message
> is never greater than the public key modulus. I _think_ that
> discarding results with MSB=1 forces the encrypted data to 'look
> random', but I've really got no clue.
>
> Does this work at all? How well? If this doesn't work, what might?
>
> Efficiency shouldn't be too bad: On average, a sender only has
> to do 1 extra RSA public-key encryptions per EFWD message.}}
>
Again I think you assume that only the TAG and BODY are delivered. Am I
wrong?
> D) REPL/SREPL messages: The sender does nothing to the Tag field;
> that's part of the SURB header, and under the recipient's
> control. The recipient can't tell whether the SURB is 'stateless'
> or not.
>
> Each SURB includes an encryption key K. The sender generates a
> payload containing the string 'Mix Reply', two bytes of size
> data, the message, and random padding up to 28K. The sender then
> encrypts this payload with K and sends it.
>
> [ lots of ...]
>
> K) If the recipient has a public key of size N, she appends the
> tag to the first N-20 bytes of the payload, and tries to
> decrypt the result. (If the OAEP padding doesn't check, the
> message is junk, or was not encrypted: go to step L.) The
> result is a key; the recipient uses it to decrypt the rest of
> the message.
>
I do not really understand that step. Surely is the final recipient has
a public key address that the sender knows, it can follow exactly the same
procedure as a mix would in order to decrypt the message. Or do you assume
that the complete headers have been stripped before the message reaches the
final recipient?
> L) The message is either unencrypted data, or junk.
>
> Open questions:
> 1) We should figure out compression at some point.
> 2) Likewise for fragments.
> 3) Likewise for k-of-n and friends.
> 4) Did I really get indistinguishability for everything but FWD?
> 5) Will my scary hack really make RSA-encrypted data hard to distinguish
> from random numbers? If not, do we have any other choices?
>
I will go along with Roger's comment on (5). I will have a hard look at
(4) in the next week. I think that Issues (1-3) do not concern the basic
"transport layer" that mixminion provides and will need to be addressed
above the "interface" that mixminion provides. Does anyone think that
they are so intrinsically linked to minion transport that they need to be
addressed now?
BTW: I do take Len's comment abou the fact that fragment recomposition
would need to happen on the network rather than the edges, but I rather
think of it as a network service rather than a basic thing that everyone
should do (depending on implementing a particular exit policy). Am I
wrong?
>
> Part II: WHAT'S AN ADDRESS?
>
> Another end-to-end issue is: how can clients specify addresses?
>
> To send a forward message, or to generate a SURB, the program must know:
> 1) The final routing type.
> 2) The non-Tag portion of the routing info.
> 3) If the sender wants to send a EFWD message, the recipient's
> public key.
> 4) If the routing type depends on a particular node (as does
> MBOX), a valid sever descriptor for that node.
>
> If the sender knows (3) and (4), we're okay. But -- as George asks --
> how is a sender supposed to find them out? If the sender just gets them
> off a keyserver, an observer (or the keyserver) can tell who wants to
> talk to whom.
>
> Possible solution: just use the Mix system to query the keyserver! The
> would-be recipient uses Minion to sent the keyserver a list of users and
> a SURB to receive the reply. (Alternatively, just send a non-encrypted
> anonymous mail to the user and ask for his key.)
>
Well relying on the anonymity system for a basic operation of the
anonymity system seems slightly fragile to me. I would rather have a way
of being able to send messages to users without (3) (as described above)
to bootstrap the conversation.
> Of course, we still have some pretty severe usability problems. When I
> want to use this thing from the command line, what do I need to tell the
> client? For now, I'm going to make users specify public keys and
> 'final' nodes on the command line, but that'll probably need to change.
> Otherwise, it'll be too easy to accidentally send a reply to the wrong
> server.
>
George