[Mnet-devel] EGTP status / problems

[Whiel O'Zookocronx]

On 2004, Aug 08, , at 09:46, baka at baka.baka wrote:
> this broke compatibility with old/ancient EGTP nodes for the first 
> time,

:-)

> some of the reasons/goals/ideas/concepts for this are ...
> - egtp doesnt use bsddb anymore (removed by zooko)
> - egtp doesnt use a config-file anymore
> - egtp works standalone (major shuffling of code)
> - egtp contains the metatracker-server and -client
> - egtp contains the relayserver-server and -client
> - egtp depends on Twisted now (the bootpageloader. *sigh*)

Yay!  Good work.

How about this proposal for the session renegotiation problem.  Reading 
your analysis of the problem just now provoked this idea:

Whenever you receive a message which is encrypted under a session that 
you no longer have, you just send a "session" message to the sender, 
encrypted for his public key, containing a copy of your current session 
info (which you generate on demand if it is absent).

Some questions:

1. Q:  But wait a minute: you can't do that if the message arrived via 
relay server!  A: All you need to know is the ID of the sender and you 
can send him a message normally -- via egtp.Node.send().  If the sender 
includes his ID in the cleartext at the beginning of each message then 
you'll always be able to send to him, even if he is behind relay.

2. Q:  What if you each send a "new session" message to the other at 
the same time, so that the two "session" messages pass each other in 
transit?  A:  If you keep the last two sessions, then you can use the 
newest one to send messages, but if a message arrives with the other 
one you can still decrypt.

3. Q:  What if there are more than 2 active sessions, for example if 
you have received several "session" messages in a row from your 
counterparty?  A:  Hm...  Well, first of all that shouldn't happen, 
because when you send a "session" message, you should not generate a 
new session every time, but instead just send a copy of your current 
preferred session.  But if it *does* happen, it hardly costs anything 
to store 10 or 1000 sessions.  A session consists of two or three 
numbers, each one being 16 bytes or so long.

Crypto issues:

Would putting the sender ID on the front of the message in the clear 
make it harder to use EGTP anonymously?  Well, it does let a traffic 
analyzer know what your public key is, but this is the kind of thing 
that a traffic analyzer probably already knows.  If you want anonymity, 
then in addition to using a Chaumian mix (or something), you could also 
arrange it so that your public key is not associated with your IP 
address.  Mojo Nation used to have separate public keys for this 
purpose (implemented by having two MojoTransactionManager objects per 
broker) -- one for talking to the TokenServer and one for talking to 
everyone else.

Alternately, you could encrypt your public key ID with the public key 
of the recipient instead of sending it in the clear.  This doesn't 
require you to public-key-encrypt every time because you can re-use the 
encrypted message every time after the first time.  Nor does it require 
the receiver to public-key-decrypt every time because they don't need 
to use it unless they are missing the session key and need to generate 
a new one.  It does add 128 bytes, a bit more implementation work.  
(Note: needs salt.)

How much work is it to implement this proposal:

Pretty easy.  Here is a description of all the necessary pieces:

  * Add the sender public key ID in the clear to the beginning of 
messages is easy, especially if we can break backwards-compatibility.  
Even if we want to implement backwards compatibility it shouldn't be 
very tricky.

  * Change the current UnknownSession-handler code in 
CryptoCommsHandler.  Instead of sending a message back down the current 
TCP pipe, instead it sets a flag on that peer  -- "needs session 
resent" -- and then sends a "session" message via the normal 
egtp.Node.send() interface.  The "session" message includes the session 
info for your current preferred session.  You don't generate a new 
session unless of course you currently have none.  The "needs session 
resent" flag is actually implemented by stuffing a "full public key 
header" into counterparty_map[peerId][3] in mesgen.py.  mesgen.py will 
then include a full public key header next time you send to that 
counterparty.  Double-check that mesgen.py does this correctly.

  * Make the "session_id" elements of the "counterparty_map" keys be 
lists of session_ids instead of individual session ids.  Make each 
session_id in that list appear as a key in "session_map".  Make the 
lists of session_ids be ordered, so that the first item in the list is 
the one you use when sending outgoing messages, and the one that you 
use when sending a "session" message.  Newly generated session_ids get 
inserted into the 0'th item, and when that happens delete any items 
greater than the 10th item.  (Or some such number.)

I think that will do it!

What do you think of this proposal, baka?

Regards,

Zooko