<div dir="ltr"><div class="gmail_default" style="font-size:small">George, <br></div><div class="gmail_default" style="font-size:small">I would definitely create an extended transition time frame.   6 months or a year where both keys will work.   just make it clear there  is a cut off date. <br>


<br></div><div class="gmail_default" style="font-size:small">And I think Adrelanos's concept is a valid one.   Since we may need to do this again, why not put a structure in place that facilitates upgrades to the system itself.   <br>

<br><br><br><br></div><div class="gmail_default" style="font-size:small"><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 17, 2013 at 3:09 PM, adrelanos <span dir="ltr"><<a href="mailto:adrelanos@riseup.net" target="_blank">adrelanos@riseup.net</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">George Kadianakis:<br>
> Thoughts?<br>
<br>
Can you make .onion domains really long and therefor really safe against<br>
brute force?<br>
<br>
Or have an option for maximum key length and a weaker default if common<br>
CPU's are still too slow? I mean, if you want to make 2048 bit keys the<br>
default because you feel most hidden services have CPU's which are too<br>
slow for 4096 bit keys, then use 2048 bit as default with an option to<br>
use the max. of 4096 bit.<br>
<br>
Bonus point: Can you make the new implementation support less painful<br>
updates (anyone or everyone) when the next update will be required?<br>
(forward compatibility)<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
tor-dev mailing list<br>
<a href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a><br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a><br>
</div></div></blockquote></div><br></div>