[Cryptography] open questions in secure protocol design?

[ianG]

On 30/05/2015 10:03 am, Natanael wrote:
> Quoting Tony Arcieri;
>  > 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.
>
> This is actually wrong.
>
> 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.


OK, but the problem we are talking about here is not what curve to pick 
now, but how do you change the curve in 7 years, when the original is 
considered or proves weak.

And the corollary to that discussion is that allowing the addition of 
new key types *without a strategy for deprecation and rollover* is a 
pathway to hell.


> ---
>
> My opinions about the main topic (I'm no professional though);


Not an issue.  Part of our hope here is challenge 'professional' opinion 
that is out of date.


> Den 25 maj 2015 22:27 skrev "ianG" <iang at iang.org <mailto:iang at iang.org>>:
>  >
>  > Today's thought while reading the WIP/draft from IETF on algorithmic
> agility [0].  Open questions in secure protocol design:
>  >
>  > 1.  One True Cipher Suite versus Algorithm Agility?
>
> 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).


Right.  It's easy to talk about it key duality on paper.  I'm not sure 
anyone's got any track record in it.


>  > 2.  Design:
>  >    - One designer, small team or committee,
>  >    - Big corp v. lone wolf,
>  >    - open source v. proprietary,
>  >    - patented algs v. open algs,
>  >    - Amateurs v. professionals?
>
> 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...
>  > 3.  Compromises:
>  >    - Simplicity v. Features,
>  >    - hardware v. software,
>  >    - raw speed v. resource efficiency?
>
> Depends entirely on use case. In general I believe small efficient
> extensible core protocols should be used.
>
>  > 4.  Packet-oriented v. connection oriented?
>
> For which part of what? Auth should be connection oriented. For the link
> encryption, I don't know.


Why should auth be connection oriented?

(I agree that auth will probably be session oriented, but recent work 
with say QUIC and mosh is towards making the session agile across IPs. 
The motive for this comes from mobile.  What I don't know is how well it 
works.)


>  > 5.  opportunistic v. externally authenticated v. delayed auth?
>
> 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.
>
>  > 6.  Modes & switches v. mode-less, switch-less?
>
> Core protocol with no switches. Optional extensions.
>
>  > 7.  E2e versus point2point.
>
> What's the practical difference?


Point2point unsecures (decrypts) at each node so each node can be a 
vulnerability.  End2end requires each node to have an independent and 
reliable auth method over every other node ... a challenging ask.


> [...]
>
>  > 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.
>
> 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...



Good answers.  I should have reversed the order of the points, everyone 
got choked on #1.


iang