Yesterday I published my thoughts on some of my favorite talks from Day One of Real World Crypto 2017. The following are some highlights from Day Two.

0-RTT Key Exchange with Full Forward Secrecy

In recent years two desirable properties for transport security have come to prominence:

The first is Zero-RTT Key Exchange, which enables clients to securely send data to a server without waiting one or more round trips for a key exchange to complete. This is especially desirable for mobile applications where round trip times might be high. In short, it allows for much faster page loads.

The second is forward secrecy, which aims to prevent an attacker from recording an encrypted session, then later decrypting it if a long-term key is compromised. For example if an attacker recorded all traffic to a website, then was later able to steal that site’s TLS private key, without forward secrecy the attacker would be able to decrypt all of the recorded traffic.

These properties have generally seemed to be at odds with each other - if the server, using nothing but its private key, can decrypt the first message of a secure session, then an attacker in posession of that private key should be able to do so as well. Proposed models have typically involved the server updating its private key on a known schedule, and securely destroying the old one to prevent compromise. But these models must balance the size of the attack window (ideally the server would rotate its key as often as possible) against the realities of clock drift and message delays in the real world, and thus aren’t widely deployed.

In one of my favorite talks of the conferfence, Felix Günther presented a new key exchange protocol which is able to combine 0-RTT key exchange with full forward-secrecy. The paper doesn’t seem to be available yet, but the approach uses a scheme called Puncturable Encryption which allows the server to replace its private key with a new one which can decrypt any message that the previous key could, except for the most recent message. Thus if an attacker is later able to recover the then-current private key, they won’t be able to decrypt recorded messages. See the paper on Puncturable Encryption for more detail on how this works.

Secure Multiparty Computation

Day two had two talks about secure multiparty computation - methods which allow two or more parties to jointly execute an algorithm over a set of inputs, without disclosing those inputs to one another.

In the first talk, Yehuda Lindell presented a relatively performant protocol for three-party computation, which is able to preserve the privacy of inputs even if one of the parties is malicious. Of particular interest to me, the protocol supports a client-server model: given a cluster of three servers, a client can split an input into three parts, and send one part to each server. The servers then jointly perform some arbitrary computation on the inputs and return the result to the client, without ever being able to see the plaintext of the input.

Yehuda and his co-authors demonstrated a Kerberos Key Distribution Center which had been modified to use their system for encrypting Ticket Granting Tickets. The resulting KDC was able to sign Ticket Granting Tickets at a rate of up to 35,000 per second on common server hardware - without any of the participating servers being able to see the user’s hashed password or the long-term key of the ticket granting server.

In the second talk, Ben Kreuter discussed his work on Secure Multiparty Computation at Google. He presented two systems that they have developed. The first of these systems allows businesses to compare the set of customers who have purchased a product with the set of people Google has shown an ad to, and to see the size of the intersection. The goal is to enable the business to understand how many customers are making purchases based on ad views, without either party disclosing the PII of their users to the other. The second system is an undeployed mechanism for aggregating predictive-keyboard models from user’s phones, while obscuring the model for any specific user.

The interesting thing about this talk was how Google’s approach differs from an academic one. The constraints of real world systems (especially ones involving mobile devices) make use of generic protocols for secure multiparty computation infeasible. Instead, the team at Google uses academic approaches to study the feasibility of a system, but develops purpose-specific approaches as needed.

Wrap Up

That’s it for day two! Check back soon for the final update and some closing thoughts on Real World Crypto 2017.