On Jan 14, 2012 8:55 AM, "Ian Goldberg" <iang@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev