Subject: [Perc] Alternative way to do key management...

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 22 Jul 2015 10:12:03 +0200

Apologies in advance for the drive-by. I haven't read the drafts. But since
we are in Prague and I will be presenting something very similar in a few
hours at CFRG. I thought this would be relevant and useful. At any rate,
people may want to consider this approach while there is an opportunity to
talk to crypto type people.

As you are probably aware, crypto is moving to ECC. While this is being
done for performance, it also has consequences for features. RSA does not
work in elliptic curves. So all the systems are DH based.

One particular feature of DH systems is that we can combine two DH keys to
create a new key:

If we have a Right private key R and a Left private key L, we can derive a
Joint key J as follows:

J = R+L
e^J = e^R . e^L

Further, if we perform the computations in a finite group it can be shown
that knowledge of e^R and e^L does not provide any information about J
unless knowledge of e^R discloses R (in which case DH is broken in that
group anyway).

OK so what does this mean for PERC?

Well on the OpenPGP list we were discussing a mailing list server in which
this scheme is used to avoid the need to expose the private key of a
mailing list to an online mailing list remailer.

The public key of the mailing list is e^J. The secret key of the mailing
list (J) is kept offline.

The remailer only knows R and the set e^LMi

When a new member joins, they contact the (offline) key manager which
constructs the value e^LMi in the normal way and communicates this to the
mailing list manager.

So what does this mean for PERC?

Well in an enterprise setting, we can eliminate the need for the key
manager to be online at all. As an ExampleCo employee, Alice gets her
enterprise PERC key as part of her corporate credentialing process.

For ad hoc communications in which the participant is not registered in
advance, the key manager has to be online of course. But we can still use
the same approach to require collusion between the distribution point and
the key manager to effect a default.

The division of responsibility here is:

Distribution point - responsible for authentication and access control (who
joins a conference)
Key Manager- responsible for authentication (implicit) and confidentiality

The approach may be further extended to meet an additional layer of
transparency requirements and further bound the operation of the services.

In the traditional protocol design approach we have only asked 'how do we
use crypto to enforce condition X'. In the new approach typified by
Certification Transparency we accept that we can't enforce every condition
cryptographically, in fact we can't even specify every condition in
advance. So we use accountability and make trusted components either
auditable (privileged participants can verify operation) or (preferably)
transparent (anyone can audit operation).

The basic approach here is to create ephemeral keys to 'salt' the server
key and then intern them in a blockchain structure.