<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 29, 2015 at 10:23 AM, ianG <span dir="ltr"><<a href="mailto:iang@iang.org" target="_blank">iang@iang.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 28/05/2015 00:58 am, Ray Dillinger wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></blockquote></div></div>
Yup.  On the one hand, 1TCS forces you to have a way of upgrading.<br><br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The only difference then is that Algorithm Agility allows you to assume it away, whereas 1TCS forces you to consider it, by removing the crutch.</blockquote><div><br></div><div>I think the original question was baddly worded. The choices offered were one child and 19 and counting. There are obvious problems with both. Which is why most people look for an heir and a spare. </div><div><br></div><div>One of the problems with algorithm agility is that the mere ability to have a hundred algorithms does not provide any agility in practice because the tendency has always been to implement the current algorithm and a half dozen legacy algorithms.</div><div><br></div><div>Microsoft .NET gives you lovely algorithm choices, If SHA-2-256 doesn't meed your needs you can use MD5, SHA-1 or RIMPEMD.</div><div><br></div><div>The reason it took so long to deprecate SHA-1 is the long tail of machines from the era when regular O/S upgrades were expected. Even now there are all those companies whose IT departments show their uncompromising commitment to security by continuing to run Windows XP. </div><div><br></div></div>Which is why I think that for future protocols we have to have TWO mandatory to implement algorithms, at least for not severely constrained devices.</div></div>