[cryptography] preventing protocol failings

Peter Gutmann pgut001 at cs.auckland.ac.nz
Sat Jul 9 10:01:37 EDT 2011


"Zooko O'Whielacronx" <zooko at zooko.com> writes:

>Hm, digging around in my keepsakes cabinet, I unfortunately do not find the
>original state transition diagram that I mentioned above, but I do find an
>artifact that I wrote a few months later=E2=80=94a sketch of a protocol that
>I called "ZRTP lite" which was ZRTP as it existed at that time minus insecure
>mode, algorithm negotiation, the "confirm" packet, and the max-retries
>timeout.

Back in the 1970s and 80s, anyone who was seriously into role-playing games
inevitably ended up designing their own system at some point, with the goal of
fixing all the flaws in whatever existing systems they used.  It always ended
up being, oh, about a thousand times more complex than any other system
around, and never got used much (or, usually, even finished).

I think there's a dual of this for people who've worked with security
protocols.  For example I've got a draft for a cut-down SSH that's probably
about one tenth the complexity of the existing protocol while satisfying the
majority of users (secure telnet/secure file transfer) that, like your ZRTP
lite, I've never got around to posting.  And a profile for CMP (a remarkably
unworkable mess that pretty much faded into oblivion after only a couple of
years) that drops most of the original protocol and actually works quite well,
and so on.

Has anyone else come up with an XYZ Lite that offers 90% of the functionality
of the original at 10% of the complexity, and 5% of the attack surface?

Peter.



More information about the cryptography mailing list