<p dir="ltr">Quoting Tony Arcieri;<br>
> They should switch, if only because that 1-bit backdoor is particularly scary, but they can't do that easily because the Bitcoin protocol has nothing to signal that wallet keys are anything but ECDSA with secp256k1.</p>
<p dir="ltr">This is actually wrong.</p>
<p dir="ltr">There's a reason standard Bitcoin addresses starts with 1 - that's the address version flag. The addresses with a 3 in the beginning are Pay to Script Hash addresses (P2SH) which you only can pay from by using the hashed script and inputs which it can validate using that script (such as a valid signature for its signature validation operation in the script, against the public key specified). Add a new signature verification algorithm for another curve and let those who want to use it create such addresses which enforce usage of that operator. It would also be easy to create a new version flag for addresses that specifies what algorithm a new address uses, such as v 5 addresses using NTRU or whatever else you might feel like. </p>
<p dir="ltr">---</p>
<p dir="ltr">My opinions about the main topic (I'm no professional though);<br>
 <br>
Den 25 maj 2015 22:27 skrev "ianG" <<a href="mailto:iang@iang.org">iang@iang.org</a>>:<br>
><br>
> Today's thought while reading the WIP/draft from IETF on algorithmic agility [0].  Open questions in secure protocol design:<br>
><br>
> 1.  One True Cipher Suite versus Algorithm Agility?</p>
<p dir="ltr">A little of both. I agree with the plan of having one as the sole standard with one backup algorithm readily available at all times for instant switching if necessary. The protocol must be designed to ALLOW algorithm agility, if only for to reduce switching costs once the old standard cipher fails. As said before, the real problem is migration AWAY from what's broken. Make sure you can signal to all devices what's no longer secure so they can switch to any backup algorithm still considered secure. Or to shut down *if necessary* (which is likely to happen from time to time). </p>
<p dir="ltr">> 2.  Design:<br>
>    - One designer, small team or committee,<br>
>    - Big corp v. lone wolf,<br>
>    - open source v. proprietary,<br>
>    - patented algs v. open algs,<br>
>    - Amateurs v. professionals?</p>
<p dir="ltr">Don't have experience enough be to have a solid opinion. But small team with (non-distracting) input from a large group of experts would AFAICT perform better than most other options. I think... <br>
> 3.  Compromises:<br>
>    - Simplicity v. Features,<br>
>    - hardware v. software,<br>
>    - raw speed v. resource efficiency?</p>
<p dir="ltr">Depends entirely on use case. In general I believe small efficient extensible core protocols should be used. </p>
<p dir="ltr">> 4.  Packet-oriented v. connection oriented?</p>
<p dir="ltr">For which part of what? Auth should be connection oriented. For the link encryption, I don't know. </p>
<p dir="ltr">> 5.  opportunistic v. externally authenticated v. delayed auth?</p>
<p dir="ltr">My current favorite model is a protocol with opportunistic key exchange which notifies the software about the authentication status, with pluggable auth modules. If the software don't care (like say a torrent client), it just moves ahead with no auth. Browsers would not start communicating until the connection is authenticated with a PKI auth module or similar. As a few examples. Delayed auth would be an option the software would need to opt in to. </p>
<p dir="ltr">> 6.  Modes & switches v. mode-less, switch-less?</p>
<p dir="ltr">Core protocol with no switches. Optional extensions. </p>
<p dir="ltr">> 7.  E2e versus point2point.</p>
<p dir="ltr">What's the practical difference? </p>
<p dir="ltr">[...] </p>
<p dir="ltr">> It occurs to me that we now have enough history in open (internet) secure protocol to do a survey across protocols & time and discover whether there are any meaningful trends in the above open questions.</p>
<p dir="ltr">Yup, we need to keep track of all the causes of the various holes in protocols. Which ones were design flaws, implementation flaws, algorithm flaws, etc, scope, severity, etc... </p>