[Cryptography] Terminology & Multiple-Doors/Multiple-Locks

[Karl]

Hi,

I've noticed in our present popular cryptography ecosystem we have a
situation of "many doors with different kinds of locks each" (big attack
surface) instead of "many different kinds of locks needed to open each
door" (small attack surface) in a lot of different ways.

I was wondering what the terms from academia for that difference are.  If
people could talk about it with more credibility, value for changing the
situation could spread faster.

For example, most recommendations on how to validate signed binaries
involve downloading the key from a centralized source and not checking its
trust with a human in any way at all: many people trusting the large sets
of certificate authorities, SSL & even plaintext HTTP protocols, networking
infrastructure, governments, servers, and server and network operators over
and over again.  Instead if maybe we had easy software to transfer keys to
friends in a signed bundle with gnupg, we could use the same signing-system
to verify the sources of the keys as the key verification itself used,
hopefully providing for fewer kinds of locks that would break the whole
chain if broken.

To get enough support to make things like that happen, casual confused
people like me need terminology that clearly express the situation to both
professionals and end-users so as to support the value.

Similarly, it seems like many of the issues with SSL stemmed from
multiple-doors situations.  Wouldn't logjam have been impossible if the
server signed a hash of its protocol messages in general, preventing mitm
alteration?  Or if it were set as a norm that protocol-negotiable algorithm
selections had to layer on to each other, rather than providing
alternatives to select only one from.  Clearly the protocol as a whole is
only as strong as its weakest selectable algorithm, such that more
algorithms make it weaker instead of stronger (where stronger is the
intuition when you see more of something), but this is not very prominently
expressed to users.  We can fix things like that but we need people to
understand what to say when recommending or supporting changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20200708/21e48086/attachment.htm>