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

[Tom Ritter]

On 17 May 2013 09:23, George Kadianakis <desnacked at riseup.net> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20130520/8ce95c5a/attachment.html>