[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Comments on minion-spec.txt

On Fri, 2003-05-16 at 14:36, George Danezis wrote:

>                                                       I do not see how the 
> 'Modules' manager would ever get hold of any information. The type III 
> system is simply used as an anonymous transport mechanism, and all the 
> relevant information to the protocols above it are contained in the higher 
> protocols (nym protocol in this case).

Ah, agreed!  What if we said that said that, when we receive a message
of routingtype >= 0x100, we deliver it by some method specified
elsewhere.  I agree that the module language is unnecessary, and that
describing stuff like a nymserver as though it needed to be built into
the Type III implementation is nuts.

I've checked in a version of minion-spec without any module or
application key verbiage.  Do you like it better?

> > Erk.  To what end?  Keep in mind that in terms of _implementation_, the
> > current approach is not significantly difficult.  The message-processing
> > code in any working server or client is dwarfed in comparison to all of
> > the support code needed to actually send and deliver messages.
> Yes but the security critical code is very much focused there (in case 
> someone wants to prove it correct), along with the part that is required 
> to get absolutely right to interwork with everyone else. In these two 
> respects I think there are advantages in making this simple, particularly 
> if we want high confidence and independent implementations. Don't get me 
> wrong: I do not think that the spec as it stands do not fulfill these. I 
> am just wondering what we get for the additional complexity.

My perspective is that the whole system, more or less, is
security-critical.  Implementors are _least_ likely to screw up the
packet format stuff, because errors there would almost certainly result
in serious compatibility bugs.

I'm not sure how much we'd save, either.  If we made routinglen a
constant 16+2+20=38 bytes except for the last hop, we'd still need an
'overflow' case in our pseudocode for the last hop, and an 'underflow'
case for all other hops.  I'm not sure we'd save very much in terms of

Perhaps we can simplify our pseudocode without losing the ability to
extend our addressing ability in the future.  I'll make an attempt...

> > I think the last time we were considering some of this stuff (at
> > PET2003) we decided that we needed a cryptographer to look at it before
> > we passed judgment.
> I am going to look for one, but I do not think any of these are critical. 
> It is just interesting for the record to know that if we ever find a good 
> reason to slim upu the packets we could.

Agreed; this kind of stuff interests me too.


Attachment: signature.asc
Description: This is a digitally signed message part