[Cryptography] open questions in secure protocol design?

ianG iang at iang.org
Fri May 29 10:39:43 EDT 2015


On 28/05/2015 10:26 am, Peter Gutmann wrote:
> ianG <iang at iang.org> writes:
>
>> 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.
>
> One generalisation I think is that Schneier and Ferguson's "security protocols
> should not be designed by a committee" still holds


Do you have a better cite for that?  I also wrote that somewhere, and I 
guess I'm just old, traditional, out of date, but I do like to cite people.

On generalisms:  we are talking generalisms.  If people can't cope with 
the limitations of these models, and cannot dance between the 
generalisms and the particularities of real problems, then they probably 
shouldn't be doing crypto.


> (following on from the
> implied "security protocols should not be designed by people who don't know
> much about cryptography").


:)

> The every-algorithm-ever designs (TLS now has
> what, 400 cipher suites?) seem to come as a byproduct of design-by-committee
> specs, while having one or two people who know what they're doing do the work
> leads to much cleaner designs.
>
> (A possible rule for this would be that you're allowed two each of a PKC,
> hash/MAC, and block cipher/mode.  Every time you want to introduce something
> new, you have to throw an existing one out.


The odds & evens protocol pattern, in that a protocol could be precisely 
odd or even.

(And, an implementation would therefore handle two protocol versions, 
being one odd and one even, with distance one between them. 1,2 -> 2,3 
-> 3,4...)


> That'd make people think...).



Yes.  This is all about that.  Making the designer think.  Because 
typically, they are not, they are following on from "best practices" 
that are out of date, without having realised that knowledge has moved on.

There is fairly clearly a spectrum of choices for the perceptive 
designer to choose from.

    TLS 400 flowers <--> MTIs + backups <--> odds&evens <--> 1TCS.


This of course is another stylised generalisation.  The presentation is 
of a model.  When we get to reality, the designer has to make a decision 
on the particularities; take it from model to implementation.




iang


More information about the cryptography mailing list