Subject: [Lurk] Discussions on drafts etc. General approach to restricting crypto

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 7 Apr 2016 17:31:38 -0300

I had discussions with Daniel Migault on looking towards a joint approach.

We 'almost' implemented a TLS key restriction agreement till my tools
got hung up on a network issue :-(

I will fill in the TLS Schema section of my draft.

We both came up with a general approach to 'locking' a LURK service to
prevent it being used as an oracle (signing, encryption, whatever) as
follows.

Let X(n, P) be some cryptographic operation that depends on a nonce n
that would be supplied by the user of the LURK service and a set of
other parameters P.

So applied to a TLS 1.2 server in a CDN, n would be the server nonce.

The LURK user (i.e. client) provides (pre-n, P) to the LURK service.

LURK service

1) generates a random nonce add-n and calculates n = H (pre-n, add-n).

2) performs the requested operation

3) returns either (add-n, X(n, P)) or (n, X(n, P)) to the client.

I think someone with theorem proving skills should be able to show
that this general approach ensures that the service does not provide a
random oracle.

Now I am taking it as a given that the channel between the client and
the service is encrypted and all those good things.

But returning add-n rather than n provides an additional layer of
security in that an attacker has to be able to break the request and
the response. It is not sufficient to simply attack the request.

We can then further protect the protocol by instead calculating  n = H
(pre-n, add-n, secret-n) where secret-n is an additional nonce factor
that was provided over a secret channel to the user and service.

As I said, I will encrypt all communication between the client and the
service. BUT, the secret-n approach gives an additional layer of
security over and above. It is probably worth having as a general
crypto strengthener.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 7 Apr 2016 21:30:35 +0000

> The LURK user (i.e. client) provides (pre-n, P) to the LURK service.

Sorry, but I can't understand the notation; is pre-n a concatenated thing (if s, what is pre) or a new thing (is so what is it)?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 7 Apr 2016 18:59:43 -0300

> Sorry, but I can't understand the notation; is pre-n a concatenated thing (if s, what is pre) or a new thing (is so what is it)?

pre-n is a pre-nonce. It is a random contribution to the nonce from
the party calling the service.

So the general approach to creating an oracle-free key service is to
replace every nonce that the caller would normally provide with a
pre-nonce and combine the pre-nonce with a nonce from the LURK service
to create the nonce to use in the exchange.

Should have been clearer I guess