[Cryptography] How to De-Bollocks Cryptography?

[Phillip Hallam-Baker]

On Mon, Aug 12, 2024 at 8:25 AM Peter Gutmann <pgut001 at cs.auckland.ac.nz>
wrote:

> Phillip Hallam-Baker <phill at hallambaker.com> writes:
>
> >There is a tendency for people to design systems that fail to meet
> essential
> >requirements in the mistaken belief this will reduce complexity.
>
> There's also a tendency for protocol designers / standards committees to
> design mechanisms to try and address every imaginary issue everyone on the
> standards committee could ever dream up, including a great many that don't
> actually exist.


The SAML design team had a requirements group that spent a lot of time
voting on which use cases to make into requirements, they spent a lot of
time on it.

I did the design and made sure that it was capable of meeting every one of
the use cases regardless of whether it was included or not.

My designs are not extensive, they are actually much more sparse than most
people's. I find that having a lot of requirements actually helps get to
the heart of the matter and can lead to a leaner design. The Mesh is a lot
less extensive than PKIX but it does vastly more.


IPsec and anything PKIX did are extreme examples of this,
> leading to designs that were severely compromised because, apart from their
> unmanageable complexity, they ended up with the flexibility of rubber
> swords
> and styrofoam screwdrivers, losing a lot of utility in exchange for
> theoretical properties that didn't matter.
>

PKIX is complex because many things that are the same are different. That
is what I tried to fix in TAXI which became the core of SAML. Certificates,
CRLs and OCSP tokens are all examples of assertions and should be processed
in similar ways but PKIX forces them to be very different. OCSP and SCVP
could have been one protocol, they are two because of politics and people
insisting on 'simplicity'.

The complexity in SAML came from using XML as a base and we did that
because, well ASN.1. ASN.1 was a very good idea that got ruined because of
one half baked proposal, DER encoding which is utterly unnecessary and a
bad way to achieve the intended outcome. Canonicalization is just as bad in
XML.

My cure for complexity is to force people to learn formal methods and write
some proofs. I don't think the proofs have much value in ensuring bug free
systems, too much opportunity for error in the requirements, but the
pedagogical exercise sure does teach you to be lean and mean in design.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20240812/638038a8/attachment.htm>