[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-dev] Discussion on the crypto migration plan of the identity keys of Hidden Services



On Mon, May 20, 2013 at 12:25:03AM -0400, Tom Ritter wrote:
> On 17 May 2013 09:23, George Kadianakis <desnacked@xxxxxxxxxx> wrote:
> 
> > There are basically two ways to do this:
> >
> 
> A third comes to mind, somewhat similar to Mike's.
> 
> If we believe that 1024 RSA is not broken *now* (or at the very least, if
> it is broken it's too valuable to waste on breaking Tor's Hidden
> Services...) but that it certainly will be broken in the future - then I
> can't think of any mechanism that would allow a future system that keeps
> 1024 bit key-based addresses to be secure...
> 
> Without introducing a trusted third party.  Imagine if a Hidden Service
> today were to generate a new identity key, 2048 (or 4096 or whatever) and
> submit this new key, and its current key to a Directory Server, signed by
> the 1024 bit key, and received back a signature of the data and a timestamp.
> 
> Now, n years down the road when 1024 bit is broken... but 2048 is not - a
> user enters the 1024 bit address, it goes through all the hoops and
> connects to the Hidden Service where the HS provides the 2048 bit key and
> the signed timestamp.  The client trusts that the mapping between the
> broken 1024 and secure 2048 keys is valid because it trusts the directory
> authorities to only timestamp such mappings accurately, and the timestamp
> is in 2012 - before the "we're saying 1024 is broken now, don't trust
> timestamps after this date" flag day.
> 
> This isn't about petnames, and from an engineering perspective it's
> probably much more work than any other system.
> 
> -tom

I suppose the followup question to this is "is there really a need for
backwards compatability n years in the future?" I completely understand
the usefulness of this feature but I'm unsure if maintaining this
ability is really necessary. The other issue arises due to the fact that
the HSDir are not fixed, so caching this mapping will be non-trivial.

Also, I may not be groking this idea, but which entity is signing the
timestamp: "and received back a signature of the data and a timestamp."?
is it the HS or the HSDir? And is this signature also created using a 1024
bit key?

- Matt
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev