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

[Trevor Perrin]

On Fri, Oct 11, 2013 at 10:32 AM, Zooko O'Whielacronx <zookog at gmail.com> wrote:
> 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.

Hi Zooko,

Are you and John talking about the same thing?

John's talking about tunnelling a redundant inner "record layer" of
encryption inside an outer record layer (using TLS terminology).

I think you're talking about a couple different-but-related things:

 * "channel binding", where an unauthenticated-but-encrypted channel
can be authenticated by performing an inside-the-channel
authentication which commits to values uniquely identifying the outer
channel (note that the "inner" vs "outer" distinction has flipped
around here!)

 * "out-of-band verification", where a channel is authenticated by
communicating values identifying the channel (fingerprint, SAS,
sessionIDs) over some other, authenticated channel (e.g. ZRTP's use of
the signalling channel to protect the media channel).

So I think you're focusing on *modularity* between authentication
methods and the record layer, whereas I think John's getting at
*redundancy*.


> 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.

This seems like a different thing again.  I agree that TLS could have
been more modular wrt "key agreement" and "public-key authentication".
 It would be nice if the keys necessary to compute a TLS handshake
were part of TLS, instead of requiring X.509 certs.  This would avoid
"self-signed certs", and would allow the client to request various
"proofs" for the server's public key, which could be X.509, other cert
formats, or other info (CT, TACK, DNSSEC, revocation data, etc.).

But this seems like a minor layering flaw, I'm not sure it should be
blamed for any TLS security problems.  The problems with chaining CBC
IVs, plaintext compression, authenticate-then-encrypt, renegotiation,
and a non-working upgrade path aren't solved by better modularity, nor
are they solved by redundancy.  They're solved by making better
choices.


 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.

If you're talking about the "New Directions" paper, Diffie and Hellman
talk about a "public file".  Certificates were a later idea, due to
Kohnfelder... I'd argue that's where things went wrong...


> 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.

That's easy though, right?  Use a proper KDF from a shared secret, do
authenticated encryption, don't f*ck up the IVs....

The worthwhile problems are the hard ones, no? :-)


Trevor