RWC 19 Write up

This year Real World Crypto was held in San Jose, CA, a little closer to me than the previous year in Zurich.

Arriving into San Jose it was raining, which was surprising to me since I've always heard that it never rains in the bay area. It seems that I came at the time of year where the rain is at its worst and I'll miss most of the sunny beauty that comes from the bay area.

Regardless, the crypto was all the brightness I needed for those couple of days. Here are a couple notes on some of the talks I attended.

Interesting Trends

Tuesday January 8th, 2019

I arrive into town and meet up with some other crypto folks I'm staying with. It turns out that there's an event that evening organized on the cryptocatz Slack, which many cryptographers are on. Got to see some familiar faces, meet new people, and make jokes only cryptographers would understand.

Wednesday January 9th, 2019

First day weather was cool and a little cloudy. It's been awhile since I've been north in the winter so I forgot how late it takes for the sun to come out. I woke up bright and early (thanks to time zone differences) but I'm excited to learn so much, see old friends, and meet cool people!

Welcome Remarks

Nigel Smart started the party.

Messaging Security

Messaging Layer Security: the beginning

Richard Barnes

Project URL: https://messaginglayersecurity.rocks/

The purpose of this talk is to invite more folks to work on messaging security and share the current state of the art.

MLS Goal: Decoherence of secure messaging apps.

Top-level requirements for an async group messaging security protocol

Want code that is reusable in multiple contexts and interoperable between different implementations.

Following the pattern of TLS 1.3 where a spec is written and let others build implementations. Can have verification of the spec.

Clients connect to a delivery service. Also split out authentication service. Could run delivery service with Vuvuzela.

MLS: Messaging layer security TLS vs MLS:

FS/PCS with sublinear scaling with parties.

Work on this has been going on since 2015. A recent relevant paper: https://ia.cr/2017/666 .

Protocol

Tree encapsulates state (to get log complexity). Derive from this tree an epoch secret. Application secret derived from epoch secret. Epoch secret used to generate protocol messages when then update the tree.

Tree invariant: the private key for an intermediate node is known to a member iff the node is an ancestor of the member's leaf.

Trees of keys. Left-balanced binary tree of DH key pairs.

1st try: Asynchronous Ratchet Tree. Failed for dynamic trees 2nd try: TreeKEM - Children have the hash of all parent nodes.

Built the tree and now authentication. Security proof is work in progress. Want Tamarin proofs.

Tradeoffs:

MLS: Help wanted - reach out!

Fast Message Franking: From Invisible Salamanders to Encryptment

Joanne Woodage

Message franking: reporting messages to service providers and security that they actually said the message.

Message franking comes from the term "speaking frankly" and combines an encryption scheme with a verification algorithm. Needs a binding to a tag

FB: add an HMAC to their messages which can be used to report. Takes 3 passes, so slow.

FB used different technique for attachments though: AES-GCM for message encryption which turns out to not be robust See: ABN10, FLQP13, FOR17

How to do it correctly:

Q: Could you do fine-grained reporting of messages? This way only the offending part is revealed.

Catch Me if You Can: An Account Based End-to-end Encryption for 1/1 Snaps

Subhash Sankuratripati

186 Million users of Snapchat Snapchat offers:

Usage requirements

10% of all logins are from new devices axolotl-like protocol has a 2% retry rate, which is unacceptable.

Account Based E2EE

Forward security is not in mind because they want users to load up all their content on a new device.

Snapchat can see the # of devices people are logged into (also users with debug logs) Hiding adding a new device means it's easy for Snapchat to be compelled to include malicious keys GCHQ approach.

Google blog post in July 2018 about E2EE push notifications

Snapchat sends Billions of 1/1 Snaps per day.

Cryptography and Politics

The Hill We Must Die On: Cryptographers and Congress

Shaanan Conhey and Gabriel Kaptchuk (joint)

The speakers spent a summer interning with Senator Ron Wyden representing the academic crypto community.

Lessons.

  1. crypto is everyone

  2. talk is cheap, but powerful (politics is all performance)

  3. Learn to talk like the other kind of Nerd

    • Tell stories
    • politicians valorize and demonize
    • master the art of the "concrete ask" (e.g. Can you get this department to do this specific thing? vs Can you make sure there are no backdoors in crypto?)
    • When calling, ask for the staffer that works on the issue area. Can meet with politicians but be sure to have story.
    • Learn how to write congressional letters

  4. Don't ignore incremental problems

Cryptography and Elections: Threat or Menace?

Matt Blaze

Tech and elections. Voting mechanisms matter. A challenge with voting is that the requirements contradict each other:

Election integrity: more spent on campaigns vs conducting elections 5000 political entities that control elections

2000 US presidential election

What to do:

To learn more, look at the National Academies voting study to fully understand problem space. Where to start in this space: identify the problems; sign up to be a poll worker.

Levchin Prize Ceremony

Secure Communications

Noise Explorer: Fully Automated Modeling and Verification for Arbitrary Noise Protocols

Nadim Kobeissi

Noise is a framework for protocols that follow certain rules. Security Goals in Noise specification

Noise explorer: spec validity model for formal verification

Automated verification w/ ProVerif

https://noiseexplorer.com

Check out the David Wong noise protocol blog post to understand more.

Passwords

OPAQUE: Strong client-server password authentication for standardization

Hugo Krawczyk

Passwords Unavoidable attacks

Avoidable

aPAKE

Where can passwords provide TLS Building OPAQUE (aPAKE): OPRF + KE

https://bit.ly/SPHINX-paper https://bit.ly/OPAQUE-paper

My idea: build an aPAKE client in SGX or with VC

How to (not) Share a Password: Privacy preserving protocols for finding heavy hitters with adversarial behavior

Eyal Ronen

MIT CTSS 1961

Password game: use differential privacy (DP) to protect password lists

[BNSTS17] QR based technique for MPC DP through MPC for password distribution analysis Want to remove more popular passwords. Useful for statistics in heavy-hitters problem. https://ia.cr/2018/003 https://eyalro.net

Crypto Usability

DARPA's Investments in Real World Cryptography

Joshua Baron (DARPA)

Talked about Brandeis and RACE

Brandeis

PE Android SCALE-MAMBA HelpMe app Optimized Schedule Docking

RACE

Hidden communications. Packet checks

Future

State-Level Secrets: When Theory Meets Practice for Journalists Working with Encrypted Documents

Bailey Kacsmar and Chelsea H. Komlo (joint)

Threshold schemes and journalism Freedom of press: Sunder C.Ellison: Ceremony design and analysis

Secret sharing systems are not yet ready for real world usage because they don't address all usability issues.

Understanding security mistakes developers make: Qualitative analysis from Build It, Break It, Fix It

Michelle Mazurek (University of Maryland)

Build it/break it/fix it How to make secure programming easier 3 problems

  1. log append
  2. bank transaction
  3. secure server

Survey to understand developer issues: https://ter.ps/SecPros

Thursday January 10th, 2019

Enterprise Cryptography

Applying Proxy-Re-Encryption to Payments

Sivanarayana Gaddam

This turned out to be the most grilled talk.

Visa: 61.4BN credit transactions, 99Bn debit transactions in 2018

All elements use HSMs

Consumer Bank to Merchant Bank (use some relay) Map Auth Root in HSMs w/ PIN verif

Uses BBS98

BBS-secp256k1

They don't worry about CCA security (CPA is enough)

Other use case: Cart Abandonments: people on sketchy shops do not trust the company to provide their CC info.

Developed a tool called AuthChain which uses (PRE + SGX + Blockchain)

Managing Keys and Teams with Keybase.io

Max Krohn (Keybase)

Federated management; decentralization Slack case Forward secrecy and is not necessary but want post-compromise security

Every team has a random shared symmetric key and renews when users removed, or team member revokes device

Uses a global Merkle tree for all users and their devices.

Track Keybase state.

Per user keys. If one device is hacked and revokes all others, then you're screwed lol

This is an ADS in production!

Cryptographic Implementation

Practicing the art and science of side channel and fault attacks

Jasper van Woudenberg (Riscure)

Automating side channel attacks.

Most attacks are trying to get access to JTAG or trying to break the secure boot.

VC Glitcher

More software scalable fault injection (FI) attacks, like CLKscrew Open research questions:

Deep Learning for SCA:

Rarely perform 2nd order attacks, because sample coming is infeasible due to noise and limited time. How to find those samples efficiently?

Correlation power analysis: cheap to calculate and applicable to many devices.

TVLA: T-testing

Tink: a cryptographic library

Bartosz Przydatek (Google)

OpenSSL APIs are complex C++ Keyczar

Tink Design Goals

My question: what is considered a good library that we should try to model? There's all these talks about crypto APIs, but what is maybe some non-crypto library that's doing it right? What are some good mis-use resistant libraries? I understand there are some under-the-hood issues that make it more sensitive to get crypto right than maybe some other things, but the API is critical.

Uniform handling of external keys

Can forbid creation of new keys of deprecated schemes

With this API for simplicity, could we implement APIs for other ZK schemes? Take their ideas of simplicity and push it onto other schemes.

Cryptography Standardization

Announcing the 2nd Round Candidates for the NIST PQC “Competition”

Dustin Moody (NIST)

Government was shutdown - no speaker :(

So how hard is solving LWE anyway?

Martin Albrecht (Royal Holloway, University of London)

Sage math for trying to break LWE.

Slope of length of Gram-Schmidt vectors by vector length is goal of breaking LWE.

LLL attack.

Strong lattice reduction: BKZ algorithm

Two types of attacks: Sieving & Enumeration

SVP oracle

Block size -> dimension of lattices.

G6K: a python and C++ framework for experiment with sieving algorithms

Open questions:

Quantum Estimates Sieving: Grover's algorithm Enumeration: Apply Montanaro's quantum backtracking algorithm for quadratic speed-up

A word on lower bounds:

Open Questions

An Account on the ISO/IEC Standardization of Simon and Speck

Atul Luykx

Why standardize at ISO? For international trade reasons - WTO follows these standards.

How does the ISO standardization work. ISO/IEC JTC 1 SC 27 WG 2

ISO/IEC Process

  1. Registration through national bodies
  2. Two layered consensus: expert + national bodies
  3. Consensus = non sustained opposition (not the same as unanimity)
  4. Decisions made at physical meetings.

Observations

Difficulty

Tech discussions

Sweet32: birthday bound attack

"permutation-based crypto"

Summary

Someone in the audience who works at the NSA (Robert Campbell (sp?)) said that Simon and Speck were attempts to rebuild trust and some of their clients wanted the ISO standardization which is why they were pushing through it. They believe in the ARX cipher and will keep working with it, even if others are skeptical.

Cryptographic Hardware

Fast, Furious and Insecure: Passive Keyless Entry and Start Systems in Modern Supercars

Lennert Wouters (imec-COSIC, KU Leuven)

One of the coolest talks which involved hacking Teslas!

Friday January 11th, 2019

Unfortunately I arrived late this day and there was a battle for the outlets, so not very many notes were taken.

Formal Verification

Verified Vectorized Cryptography (with less manual effort)

Karthikeyan Bhargavan

Usual process for verification:

Spec -> Pseudocode -> formal spec (Coq, F\*, Cryptol) ---> Verification
                                                      /
                       Implementation (C, Rust) -----/

HACL* is a useful tool for this.

Platform-Specific Implementations -> Hard to verify Vectorized implementations are a challenge, so let's verify a SIMD library

HACSpec: towards verifiable crypto standards

Relevant related work:

Conclusion

Awesome talks with awesome people! Looking forward to next year!