[tor-dev] Transitioning to new crypto (again, but with substance)

[Watson Ladd]

On Jan 14, 2012 8:55 AM, "Ian Goldberg" <iang at cs.uwaterloo.ca> wrote:
>
> On Fri, Jan 13, 2012 at 08:18:06PM -0600, Watson Ladd wrote:
> > Dear all,
> > After thinking hard about the issues involved with new cryptography in
> > Tor I came to the following idea for a somewhat reasonable upgrade
> > path for OP's and OR's that preserves everyone's privacy and security
> > at all points (to the extent that this is possible: new connections
> > are by new clients). The only issue is what actually goes out on the
> > wire needs to be though through.
> >
> > First note that the connection between the identity used to ensure
> > EXTEND cells go over canonical connections and the keys actually
> > presented by two OR's that have formed a connection can be pretty much
> > arbitrary: it isn't necessary for the client to know what it is. So we
> > could have each OR have an identity key that stays 1024 bit RSA for
> > old ORs while newer ORs trust some snazzy new elliptic curve key,
> > while using the same 1024 bits to form the identity. Note that if we
> > use elliptic curves to secure the endpoints,(and don't mind
> > incompatibility with old clients) the RSA key doesn't even need to be
> > an RSA key.
>
> I'm not sure what you're saying in this last line.  Are you saying that
> the crypto uses the snazzy EC key, and the 1024-bit identity key is now
> just an arbitrary 1024-bit string?  That doesn't seem secure to me:
> another OR can just publish that same string, along with its own snazzy
> keys?
Good catch: the identities in this scheme must remained tied to the RSA
key, which I think has to be the case to support all clients. Changing that
will be a flag day.
>
>   - Ian
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20120114/1fb92e34/attachment.html>