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