>
> My concern to this is that we are adding extra latency rather then using
> the system to cut down on it. I'm worried about the time it takes per hop
> as it is - I would almost consider sacrificing forward security if it
> means we can save the seconds the keyexchange takes.
I agree, but if we want interoperability, we have to keep DH in the next
version. If we don't mind breaking everything we can use a PK
authentication+key exchange in one step system.
> Of course, maybe caching session keys for several connection is a better
> idea.
I don't like that. It means the key is sitting in memory or worse, on
disk for longer than a connection.
> Another detail we should consider in the final crypto system is making it
> possible to run an invisible node - ie one that comes alive only when a it
> gets a signed request from a recognized peer. Such a node should be able
> to masquerade as another service while waiting for the authentication.
That should be possible. It will complicate things but not much.
Scott
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20000816/1c7cfe30/attachment.pgp>
