Real-World Crypto Workshop: Day 1

Today was the first day of the Real-World Crypto Workshop in Stanford, California. This workshop follows on from a similar event held in Cambridge early last year (previously featured in this blog). Like last year the program is filled with lots of interesting speakers so it looks set to be another three days filled with great talks. The workshop aims to provide a meeting ground for both academia and industry. In this blog I will concentrate on two talks from today, one from an academic and the other speaker from industry.

Mihir Bellare's talk "Instantiating Random Oracles", described work aimed to address some of the criticisms of the use of random oracles in security proofs. Random oracles are widely used in proofs of security but there has been much debate in how useful these proofs actually are. Several papers have show separations where schemes can be proved secure when hash functions are modeled as a random oracle but which when implemented in practice with a real hash function would be completely insecure. Such examples however, are not that natural and so the debate has remained on the usefulness of random oracle based proofs. The work in the talk introduces a new security definition for hash functions which would capture the security properties required from a hash function used in practice, when the scheme using such a hash function has a proof which is given in the random oracle model.

The second talk I will describe here was given by Terence Spies from Voltage Security on "Data Privacy Models in the Payments Industry". Focus here was on how credit and debit card transactions are kept secure. Specifically looking at PANs (or Primary Account Numbers), this is the 16-19 digit number shown on the front of each card. In my cases this number is kept in plaintext by the merchant and so is targeted by malicious parties how can then use these details to make fraudulent transactions. The solution to then secure such numbers is to use Format-Preserving Encryption. Such a scheme maintains the format of the message after encryption, i.e. although encrypted it continues to be a 16-19 digit number.