[Nym3-devel] SURBs, tag, and all that.

[Laurent Fousse]

Hi Nick,

* Nick Mathewson [2005-03-29]:
> > Specifically, I'm still confused about the "tag" mentioned in
> > E2E-spec.txt, and wondering how nym3's client is supposed to deal with
> > incoming messages - is the tag from a returning SURB readable prior to
> > any decryption ? If that's the case we can use that information to
> > know for which account a given message is.
> 
> By "returning SURB", you mean a reply message, right?

Yup.

> The "tag" (or "decoding handle" is indeed visible in the reply
> message as the client receives it; Mixminion should handle it for
> you.

Hum. I think we need to get this "tag" before we call the ClientAPI,
and letting Mixminion handle it for us is not enough.
nym3-client should support different accounts, so (presumably) one
SURB-keyring for each account. When we create the ClientEnv object
we need to pass the right keyring to it.

Is SURB.getDecodingHandle() usable on a reply message (I guess no) ?

If you say we can just use one shared SURB-keyring for all accounts
and it implies no anonymity problem to the user, that's certainly fine
with me.

> > Can we assume that ClientAPI will deal with SURB-level encryption,
> > packet fragmentation, giving the calling program the assembled and
> > decrypted message and an indication of which key was used, so we can
> > relate the message back to the appropriate account ?
> 
> (There shouldn't be a need to "assume" anything here -- ClientAPI
> should do what its documentation says.  If the documentation isn't
> clear on some point, please let me know so I can fix it.)

As far as ClientAPI is concerned, the documentation is the source,
right?

> As ClientAPI currently stands, the idea is that you provide an
> identity string when you call "generateSURB" or "generateSURBS", and
> later you get that identity back when you call "getSURBIdentity" on
> the decoded packets.  Is this about what you wanted?

That's what I wanted. Since the python function prototypes don't give
type information, it was not obvious to me that the `identity'
argument in generateSURBs was a plain string and not some more complex
mixminion data structure.

ReceivedPacket.getSURBIdentity() is just what we need. I should
forget about E2E-spec and read ClientAPI more often I guess :-)

Thanks a lot for your clarifications!

-- 
Laurent.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.noreply.org/pipermail/nym3-devel/attachments/20050330/2c8c5993/attachment.pgp