<div dir="ltr">On 17 May 2013 09:23, George Kadianakis <span dir="ltr"><<a href="mailto:desnacked@riseup.net" target="_blank">desnacked@riseup.net</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There are basically two ways to do this:<br></blockquote><div><br></div><div style>A third comes to mind, somewhat similar to Mike's.</div>

<div style><br></div><div style>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...</div>

<div style><br></div><div style>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.</div>

<div style><br></div><div style>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.  </div>

<div style><br></div><div style>This isn't about petnames, and from an engineering perspective it's probably much more work than any other system.</div><div style><br></div><div style>-tom</div></div></div></div>