[Cryptography] On the meaning of perfect forward secrecy...

[Phillip Hallam-Baker]

I have been rethinking the notion of perfect forward secrecy and not just
because it is never actually perfect. In fact I think we ended up confusing
ourselves because of how we came on the problem.

The first time I saw PFS being discussed was in the design of IPSEC and we
ended up with the idea that to make the connection PFS, we periodically
generate a new DH key, authenticate it under the primary shared secret and
perform a new key exchange which is then used to key the channel.

So what is the problem? Well first off as the Signal folk pointed out,
throwing away the shared context from the primary key exchange when we
rekey is a doofus move. And especially so when our cipher suites are
RSA2048 and DH512. Instead of strengthening the key exchange, the ephemeral
weakened it massively (thanks BULLRUN)

So whenever we rekey, we are always going to make sure that we at least
preserve the security of the primary context, if appropriate, we may also
chain from one ephemeral output to the next.

Thus if we have a primary shared secret P and ephemerals E1, E2, we are
either going to use

s1 = KDF(P+E1), s2 = KDF(P+E2) ... sn = KDF(P+En)

or

s1 = KDF(P+E1), s2 = KDF(P + s1+E2) ... sn = KDF(P+ sn-1 + En)

The other subtler problem is that we are looking at perfect forward secrecy
as a property of the channel rather than being relative to a credential.
And the reason I think this matters is that the IETF MLS working group
might well be solving the wrong problem.

So lets take the case where Alice and Bob decide they want to have a
mutually authenticated, bilateral conversation. If we want mutual
authentication, each is going to have to issue a challenge to the other.
Simplest way to do that is in the form of an ephemeral keypair.

Let Alice, Bob credentials be {A, a}, {B, b}, ephemerals be {EA, ea} , {EB,
eb}

P= KDF (  a.EB + ea.B } = KDF (  eb.A + b.EA }

And this will give us forward secrecy if and only if Alice throws away ea
AND Bob throws away eb.

It is the throwing away of the credential that gives us the forward
secrecy. If Alice or Bob keeps track of either their ephemerals or P,, the
session can be decrypted.

So what ea is actually doing for Alice is to protect against the risk that
Bob's secret b is disclosed. And eb is protecting against disclosure of a.

Forward secrecy is a property relative to a credential and not to a channel.


Reason I got into this was that I was looking at the problem of a client
establishing a connection to a host with the possibility of a DoS attack. I
want to minimize the number of round trips. But I also want to turn on
crypto as fast as possible.

So that got me thinking, what if the host were to use the same ephemeral
for multiple inbound connections? My initial idea was to then do an
immediate rekey. But as I come to implement, that seems unnecessary.

So lets imagine that the host generates a new ephemeral keypair every hour.
This is used for an hour and thrown away at the end. This does open up a
window of possible compromise of the host ephemeral but this is irrelevant
if the host is maintaining the session.


Getting back to the problem of encrypted chat groups. The big problem I
have with MLS and their trees is that there are two problems in a group
chat, confidentiality and authentication. I don't see MLS helping with
either.

Yes, decentralized, peer to peer, yadda yadda. Problem is that every
decentralized system I have ever seen deployed successfully in the real
world has ended up relying on central brokers (MIT key server, Mt Gox,
Quadriga, ICANN, Tether...) And what ends up happening is that instead of
accepting the fact that there is a coordination point and mitigating the
risks with controls, the issue is swept under the carpet and we get
security by ARGUMENT IN ALL CAPS.

Confidentiality is a break once run anywhere problem no matter how you dice
it. If any participant in the channel keeps a record or discloses, the
channel is breached.

I can't see any value in Alice or Bob knowing that the shared secret they
are using was constructed using data they helped provide because the only
thing they ultimately care about is that P might be disclosed to a third
party. There is no point in controlling against Alice constructing a
malicious input into the derivation of P if she can publish P on her
Twitter feed.

The only possible way MLS could help is if it reduced the probability of an
implementation error leading to disclosure. I can't really comment on that
because MLS is a bit too complicated for me to tell if that is the case or
not.


Authentication is the problem of telling if the @alice in the channel run
by @carol is the real @alice. And that has two parts:

1) How does @carol know it is the real @alice speaking?
2) How does @bob and everyone else know this?

The first is fairly easy because @alice has to be let into the group at
some point and they will be authenticated by whoever let them into the
group.

The second requires a bit of mechanism. One very simple mechanism would
be @alice periodically signs what she is presenting to the channel.
Possibly signing a challenge value is enough.

Problem here is that we have exactly two authentication primitives, MAC and
signature. MAC is fast but relies on a shared secret and so anyone who can
verify the data can forge it. Signature is slow so we can't be signing
every packet but we could sign every n frames of video, maybe every frame.
And the bigger problem with signature is that it lacks deniability.


What I want to build eventually is a video chat environment in which Alice
is buying a house from Bob and they are doing the closing with Carol, Doug,
Edward etc. Who are realtors and the banks involved.

I want the person who is working for Fidelity Investments to have the TTP
certified Fidelity Investments logo in their window, same for all the other
trusted parties. And the reason I want that is so I don't have to worry
about sending a wire for half a million bucks over the telephone.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210218/e7db74fb/attachment.htm>