[Cryptography] open questions in secure protocol design?

[Natanael]

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.

---

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

Den 25 maj 2015 22:27 skrev "ianG" <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).

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

> 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?

[...]

> 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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150530/c620ee74/attachment.html>