[Cryptography] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?

[Zooko O'Whielacronx]

I like the ideas, John.

The idea, and the protocol you sketched out, are a little reminiscent
of ZRTP ¹ and of tcpcrypt ². I think you can go one step further,
however, and make it *really* strong, which is to offer the "higher"
or "outer" layer a way to hook into the crypto from your inner layer.

This could be by the inner layer exporting a crypto value which the
outer layer enforces an authorization or authenticity requirement on,
as is done in ZRTP if the "a=zrtp-hash" is delivered through an
integrity-protected outer layer, or in tcpcrypt if the "Session ID" is
verified by the outer layer.

I think this is a case where a separation of concerns between layers
with a simple interface between them can have great payoff. The
"lower"/"inner" layer enforces confidentiality (encryption),
integrity, hopefully forward-secrecy, etc., and the outer layer
decides on policy: authorization, naming (which is often but not
necessarily used for authorization), etc. The interface between them
can be a simple cryptographic interface, for example the way it is
done in the two examples above.

I think the way that SSL combined transport layer security,
authorization, and identification was a terrible idea. I (and others)
have been saying all along that it was a bad idea, and I hope that the
related security disasters during the last two years have started
persuading more people to rethink it, too. I guess the designers of
SSL were simply following the lead of the original inventors of public
key cryptography, who delegated certain critical unsolved problems to
an underspecified "Trusted Third Party". What a colossal, historic
mistake.

The "foolscap" project ³ by Brian Warner demonstrates that it is
possible to retrofit a nice abstraction layer onto SSL. The way that
it does this is that each server automatically creates a self-signed
certificate, the secure hash of that certificate is embedded into the
identifier pointing at that server, and the client requires the
server's public key match the certificate matching that hash. The fact
that this is a useful thing to do, and inconvenient and rare thing to
do with SSL, should give security architects food for thought.

So I have a few suggestions for you:

1. Go, go, go! The path your thoughts are taking seems fruitful. Just
design a really good "inner layer" of crypto, without worrying (for
now) about the vexing and subtle problems of authorization,
authentication, naming, Man-In-The-Middle-Attack and so on. For now.

2. Okay, but leave yourself an out, by defining a nice simple
cryptographic hook by which someone else who *has* solved those vexing
problems could extend the protection that they've gained to users of
your protocol.

3. Maybe study ZRTP and tcpcrypt for comparison. Don't try to study
foolscap, even though it is a very interesting practical approach,
because there doesn't exist documentation of the protocol at the right
level for you to learn from.

Regards,

Zooko

https://LeastAuthority.com ← verifiably end-to-end-encrypted storage

P.S. Another example that you and I should probably study is cjdns ⁴.
Despite its name, it is *not* a DNS-like thing. It is a
transport-layer thing. I know less about cjdns so I didn't cite it as
a good example above.

¹ https://en.wikipedia.org/wiki/ZRTP
² http://tcpcrypt.org/
³ http://foolscap.lothar.com/docs/using-foolscap.html
⁴ http://cjdns.info/