14 JAN 2019 (no. 2)

Real World Crypto Notes

[ These are not all the talks as there are some I missed or decided not to take notes on. I’ll get to these soon and update this page. ]

Table of Contents:

Day 1

Day 2

Day 3

Day 1

Message Franking: From Invisible Salamanders to Encryptment

Message franking is essentially a proof that a decryption of a ciphertext C is the plaintext M. A message franking scheme includes an encryption algorithm and a verification algorithm.

Facebook uses this for abuse reporting, however their scheme is very slow in comparison to authenticated encryption. Due to the efficiency problems, Facebook handles attachements differently.

To handle attachements, the user chooses a one-time file key and encrypts the attachment file with AES-GCM. They then use the Facebook franking algorithm on the key instead.

Problematically, GCM is not a secure franking scheme. Moreover, it’s not robust [ABN10], [FLQP13], [FOR17] – easy to construct a ciphertext that decrypts validly under different keys.

An attack is as follows:

  1. Construct a ciphertext C* which decrypts to innocuous attachement under K_1 and an abusive attachment under K_2.
  2. Attacker sends C* to victim twice, first with K_1 and then with K_2.

The outcome of the attack is that the user can report a message for abuse and Facebook will see an innocuous message while the user sees the abusive message.

Facebook Messenger source code refers to encrypted messages as salamanders. Thus, a disappearing message is an invisible salamander.

Catch Me If You Can: An Account Based End-to-end Encryption for Snapchat

Snaps have inherent privacy protections. They’re ephemeral – deleted after viewing, deleted in 30 days if not viewed.

Identity Churn: People lose identity between devices, applications, etc.

Snpchat had tried to use a double-ratchet like protocol, but it failed.

Requirements for a new scheme were: - Reduce identity churn - Securely support multiple users on a single device - Support multiple devices for a single user - Make retries faster

They introduced the notion of Account-based E2EE. Using a “post logout secure DB”, the user authenticates to the service and supplies a new public key (if any). This new public key is then very efficiently distributed accross the social graph for their friends.

On Snapchat, content is uploaded immediately upon creation, but it’s encrypted on the client side with a key CEK. When the user wants to share the content, only then is the key uploaded. If the user discards the content, then the key is never uploaded and snapchat never has access to the encrypted data.

Essentially, Snapchat uses their Account-based E2EE to wrap CEK to share among other devices. When the recipient logs in to a different device, and the sender is attempting to encrypt with a different device, Snapchat tells the sender to re-wrap the CEK with a different key.

Snapchat sends key updates via push notifications. To protect the public key they’re sending via push notification, they encrypt it with a key known only to the user’s device.

[This is interesting, but it doesn’t prevent any sort of nation state attacker, or rogue employee, from acting maliciously. Predominantly, the key exchange deployed over push notifications seems exceptionally problematic.]

The Hill We Must Die On: Cryptographers and Congress

Cryptography rearranges power: it configures who can do what, from what. This makes cryptography an inherently political tool. – Phillip Rogaway

Why work in policy?

Authors worked in Ron Wyden’s office.

Some questions:

The interests of the authors and the Senator somewhat overlapped, but they weren’t exactly the same.

What the authors did:

The authors note that they argued a lot and felt that it was very productive.

They also met with members of NSA:

Cryptography is everywhere and seeing more adoption in government. For example, the Census will begin using differential privacy in 2020.

Authors note:

Legislators want to hear stories. It’s hard to sell complex cryptography, instead use a story that may present why those concepts are preferable in comparison to the status quo. It’s also important to consider the politician’s mental model.

Don’t ignore “Incremental” problems. Big ticket issues are controversial and have friction. You can work incrementally to effect real change.

If you’re an academic:

If you’re in industry:

Crypto Means Cryptography (But not for Voting)

Interestingly, Matt Blaze notes that public confidence in election outcomes depends partly on public confidence in the mechanisms. These mechanisms have become very important (paper ballots, machine-counted ballots, voting computers, etc). We should think a lot on whether or not our voting tech actually accomplishes the requirements that we need for public confidence.

Some of these requirements contradict:

Elections need recovery, not just proof that irregularities were detected. Does new voting tech enable mischief or does it prevent it?

Traditionally, the threat model was to prevent a corrupt candidate from influencing the election towards one way or another. In 2016, it became included that state actors could influence an election or reduce confidence in an election. These actors likely have resources that are greater than any other candidate or person. These malicious actors also only need to reduce confidence in who the winner (or loser) is.

Voting in the US:

Matt notes that US voters vote for more issues per-election than any democracy on Earth. We may have 20-30 issues on each ballot. There can even be multiple ballots within ballots. Logistically, this becomes complex so the solution to “not use computers” just isn’t valid anymore.

With hole-punched ballots, if more people show up than expected, it becomes more difficult to vote. This is because the cardboard “hole” on the ballot fills up a reservoir and it physically becomes harder to vote. If a cardboard piece partially tears, it also becomes difficult for the optical reader to read the ballot, but easy for a human to notice.

The Help America Vote Act (HAVA) was a federal law passed after 2000 election. It mandated that states shift to accessible voting technology.

The most prominent machine that was HAVA Compliant was a DRE Voting Machine. It reads votes directly into memory from a touchscreen.

This is computerized voting. This is problematic because software is also problematic. There is a lot of room for failure and compromise. It’s also inherently complex and easy to hide malicious bugs.

It’s used at basically all stages of elections (pre, during, and post).

There are many potential vulnerabilities with computerized voting and cryptography doesn’t help with most of these problems. Especially when we consider recovery from some of these vulnerabilities.

There are four major vendors of voting equipment and all of them have had serious questions raised about the integrity of the voting system.

In theory, voting sounds simple, but in practice it’s actually very complex and encompasses many phases of an election.

Matt audited a voting system at UPenn and found that all they needed was physical access (a voter, poll worker) to alter election results.

The solution is not to build better software, but conduct more audits and procedural controls. In the long term, we need careful design for security and better architectural models that don’t make us dependent on problematic platforms. New innovative cryptography is not so important for these answers. Essentially, don’t build systems that rely on software.

But what about the blockchain:

Blockchains just don’t solve the issues inherent in voting problems.

Want to learn more?

Questions/Notes:

Levchin Prize

Noise Explorer: Fully automated modeling, analysis, and verification for arbitrary Noise protocols

Noise is a framework for Secure Channel Protocols based on Diffie-Hellman key agreement.

[See Trevor Perrin’s RWC2018 talk on Noise]

Noise Handshake Pattern Notation:

Noise is adopted by popular products like WhatsApp and WireGuard.

Security goals in Noise are based on a Grade System.

There are 50+ handshake patterns in the spec alone.

Noise allows for use-case specific protocols.

Noise Explorer allows for designing and formally verifying any noise handshake pattern. Nadim has made a compendium for the results for 50+ noise handshake patterns. Noise Explorer also generates full implementations for your noise handshake pattern in JS and Go.

What is Formal Verification with ProVerif?

In ProVerif all cryptographic primitives are perfect symbolic black-boxes with no algebraic properties. Using ProVeriff, they were able to make contributions to the Noise specification to imporove security. They also added security grades for 23 different patterns.

Noise Vs TLS:

Noise protocols have less room for error and are easier to audit in comparison. It takes less trust to build these protocols.

The Noise Explorer really is very complete and articulate. Definitely check it out.

Future of Noise:

See https://eprint.iacr.org/2018/766

Application Layer Transport Security

Distributed systems rely on secure communication protocols. Google uses Application Layer Transport Security (ALTS) to secure Remote Procedure Calls (RPCs). Google sees roughly 10 billion RPCs per second.

Why not TLS?

ALTS was designed to be a highly reliable, trusted system.

Some guiding principles:

ALTS Trust Model:

Three types of credentials expressed in ProtoBuffs: master certs, handshaker certs, and resumption keys.

[Speaker is moving exceptionally quick for a very complex protocol, and I can’t notate quickly enough. Fairly interesting infrastructure, though. Google published a whitepaper with more details. See https://cloud.google.com/security/encryption-in-transit/application-layer-transport-security/ ]

OPAQUE: Strong client-server password authentication for standardization

Passwords, can’t live with them, can’t live without them. – Cyberius Erasmus

Hugo notes that passwords will not disappear.

Unavoidable attacks of using passwords:

Avoidable attacks:

aPAKE

OPAQUE:

The OPAQUE Protocol:

OPAQUE basics from [FK’00, Boyen’09 (HPAKE), JKKX’16].

OPAQUE can be thought of as a “compiler” from any OPRF and key exchange to aPAKE.

Diffie-Hellman OPRF is the most efficient OPRF.

OPAQUE also blends smoothly with 3-flight TLS1.3 handshake. The server certs and client signature can be replaced with OPAQUE’s components. To add account confidentiality, it adds a round trip w/ account info protected by a server-authenticated 1-RTT (with server’s certs).

OPAQUE Security:

Extenstions:

Summary:

See https://bit.ly/OPAQUE-paper, https://bit.ly/OPAQUE-draft, https://bit.ly/SPHINX-paper (password manager to complement OPAQUE)

How to (not) share a password

Passwords:

Bad passwords don’t only compromise the users. Weak and popular passwords can be used for large-scale attacks. Some examples are the Mirai attack and easy to find IoT devices with Shodan-like search engines. Unique weak passwords might be okay, but popular passwords are bad. There exists also a question of whose fault is it. California made the “Security of Connected Devices” law in October 2018 to answer some of this.

It’s very difficult to decide “ideal” guidelines for password. NIST basically said to choose the longest password the user remembers.

Some possible solutions:

Passwords over time change but changes aren’t strong enough and tend to go back to simple ones like the original.

It’s noted that publishing blacklists can also help attackers. An attacker can use auxiliary data to guess password distribution. It’s noted that publishing a blacklist is similar to a code vulnerability. Leaking password info can also hurt the user.

Ideally, we want to identify and blacklist popular passwords. However, servers should not learn “more than 1 bit” on any user’s password. This halves (at most) the number of password guesses.

Authors note that there exists lots of prior research, but says that theirs is a bit different. Both users and servers may be malicious.

MPC Meets DP in the Malicious World:

[Again, speaker is moving quickly and I’m having trouble keeping up.]

See https://eprint.iacr.org/2018/003/

Cryptography at DARPA

Overview:

Braneis’ goal is to develop tools and techniques that allow applications to use private date for only their intended purpose. Essentially, the aim is to decrease trust in applications that require private information.

An example was given with how some folks didn’t use Signal because it wanted their contacts list, but it needed it for innocuous purposes.

Brandeis attempts to measure privacy which is fairly complicated, among other things.

One development is “Privacy-Enhanced (PE) Android”. PE Android seems like a system that is very similar to SELinux but for privacy controls.

Author notes that he belives MPC is completely practical for some applications. Brandeis uses MPC in some ways to preserve privacy. An example is given for something called a “Help Me” application that uses encryption to route users to a near by medical aid center.

Another example is given for “Optimized Schedule Docking”. Brandeis is accomplishing this in a practical time (7s) utilizing MPC.

Some tech supported w/ Brandeis:

Race’s goal is to use cryptogaphy and obfuscated communications to build an anonymous, attack resilient, mobile communication system that can reside completely within a contested network environment.

Author notes strong security properties and offers confidentiality, Integrity, and Availability.

Future Cryptography at DARPA:

Interesting question – someone pointed out that there is an ethical question with regards to accepting funding from military sources, like DARPA and quoted Phillip Rogaway.

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

We’re specifically examining Threshold schemes and their applications to journalism.

In a threshold scheme, each participant is given a fragment of a secret and cannot, alone, recover information from the secret.

In our scenario, a journalist wants to securely store information in a manner that has some redundency. This can be accomplished in a threshold setting to securely share this information to eliminate that single point of failure. It also prevents a single person from unilaterally deciding to share information.

The Freedom of the Press Foundation created Sunder which allows for people to use Shamir’s Secret Sharing to accomplish the threshold setting.

There are three stages of this scheme:

  1. Fragment Generations
  2. Distribution
  3. Reconstruction

Authors are focusing on the security of these systems, including the “ceremony” and the people interacting with the system. This includes how a human interacts with the protocol. We will examine the gaps in these protocols and how it affects security, and the improvements identified.

Gaps and Improvements: Base

Organizational Turnover

Integrity for Ciphertext:

Redundency for ciphertexts:

Ongoing and Future Work:

Current:

Future:

Takeaways:

Post talk notes:

Understanding Security Mistakes Developers Makes: Qualitative Analysis from Build It, Break It, Fix It

Many real vulnerabilities arise from “solved” problems

A graph notes that buffer overflows have become more prominent, especially in 2018.

There are many examples of vulnerabilities that are quite obvious today. Even Ransomware developers get crypto wrong. Sony, yet again, gets hardware and embedded cryptography wrong leading to playstation classic hacking (thank you!!)

It’s easy to laugh at these mistakes, but we need to change our minds on this. Instead of asking, “What’s wrong with devs?” we should ask, “What can we do to make secure programming easier?”

Some solutions:

We need to understand causes and prevalence of vulnerabiltities. This is hard.

We can accomplish this with:

  1. Field Studies
    • Hard to do.
    • Organizations aren’t thrilled about letting researchers in to do this.
  2. Field Measurements
    • Look at CVEs
    • Examine what vulnerabilties exist over some years
    • Reading new research
    • This can be difficult because you tend to find bugs you’re looking for
  3. Lab studies
    • Lots of control
    • Much easier to manage and examine
    • Has some drawbacks due to programming in a lab setting is different from practice.

Build it, Break it, Fix it

Builders:

Breaker:

Findings:

Problems asked to solve:

Secure Log Problem

Secure Communications Problem

Secure Data Server Problem

Analysis Approach

Measuring:

Hierarchy of vulnerability classes

Author notes that the analysis is taking longer than expected and is not complete yet.

Non-attempts >> mistakes Misunderstandings >> mistakes Implicit non-attempts occur more than obvious non-attempts.

Comparing problems:

Vulnerability classes:

Non attempt:

Misunderstanding:

Mistake:

Thinking about solutions:

More analysis coming soon:

Understanding developer errors is hard. Vulnerabilties arise from nuanced security properties. Abstractions and documentation matter (and not just in lab studies).

An invitiation to join the participant panel – https://ter.ps/SecPros/

Author notes that Education, Programming experience, and security experience don’t really help that much against creating bugs. Author also notes that code with test coverage statistics aren’t available yet, but are coming soon.

Day 2

Applying Proxy Re-encryption to Payments

A Merchant bank and a Consumer bank are connected via a payment network.

Some sample transactions on this network are:

Visa does 5000 messages/second worth roughly about 2 billion dollars.

HSMs are connected at all points througout the network.

There are two pin verification modes:

Key Custodians can share keys with the bank to re-encrypt and perform a pin transformation. These keys are held by the Payment Gateway and the Payment Network. This creates a chain of custody wherein each actor encrypts, then decrypts, then encrypts again the pin to keep it confidential on the network.

This is error prone.

Requirements:

Solutions:

Instead of encrypting, decrypting, then encrypting repeatedly, these network actors would perform a re-encrypt function.

Important properties in PRE for Visa

Key setup:

  1. Merchant bank and Payment Network is considered a trusted network.
    • The Merchant Bank can share the public key to the PoS partner and store its re-encryption key
    • The payment network also stores some re-encryption key and shares a pubkey with the consumer bank.
  2. PoS encrypts pin normally
  3. Payment Gateway performs re-encryption on Pin to merchant bank
  4. Payment network performs a re-encryption to consumer bank
    • These require no HSM and transactions are performed more efficiently.

Benchmarks:

Solution Summary:

Problem: Cart Abandonments:

People abandon their carts online because:

How can we help merchants accept unknown payment types?

Visa Blockchain shilling commences w/ PRE + SGX + Blockchain

Conclusion:

[ I am very concerned with how they use BBS98 for this… They spent very little time explaining their trust model and given the key setup for BBS98, this is concerning. ]

Managing Teams and Keys with Keybase

Too many people are uploading unencrypted data to centralized servers.

How do we build an end-to-end encrypted slack?

Basic Requirements:

Slack is currently very centrally managed. It basically trusts on email authentication.

Threat model:

There are a few insufficient solutions:

Keybase’s approach:

How apps work:

Questions:

  1. How devices sign statements to constitute a user?
  2. How users sign statements to constitute a team?

Account Creations:

  1. Pick username n
  2. Rolls a new Ed25519 Signing Keypair (s,S)
  3. Rolls a new Curve25519 DH Keypair (d,D)
  4. Rolls a new “per-user-key” Curve25519 DH Keypair (u,U)
  5. Signs D with s
  6. Encrypts u for D
    • Crucially, s and d never leave the device; encryption of u does
  7. Posts sigchain links to a global merkle tree.

New device addition:

  1. New Ed25519 Key (s',S')
  2. New Curve25519 key (d', D')
  3. Signs S with s' and S' with s
  4. Signs D with d' and d' with d
  5. couldn’t complete this list

Keybase uses a QR code to transmit keys between devices. Secrecy isn’t needed here, just authenticity.

Revoking a device:

  1. Sign a statement to revoke S and D from lost/stolen/retired device
  2. Rotate per-user-key to (u',U') and re-encrypts u' for all non-revoked devices

A link is added to the global merkle tree to show that a key was revoked.

Proving External Corroboration

To find Alice, Bob:

  1. Descends Merkle tree to Alice’s leaf
  2. Fetch tail of her “sigchain”
  3. Playback chain from beginning to compute:
    • Signing keys
    • DH keys
    • Per-user keys
    • Claimed external identities (Twitter, HN, etc)

How to define a team?

Adding a user to a team:

  1. Alice or Bob can now add Chuck to the team
    • Admins can make membership changes
    • Non-admins just get to see team secrets
  2. Adds a sighchain link
  3. Encrypts t for new user Chuck

Removing a user:

  1. Admins can remove users, but must re-roll the team keys
  2. Sigchain is appended with the removal and new keys

Revoing a device, revisisted:

What was learned using per-user-keys:

Details and other lessons learned:

Conclusion:

Practicing the art and science of side channel and fault attacks

Sometimes there is leakage on devices and we can examine it.

When doing fault attacks, we’re trying to make the device misbehave in some way. We’re simply trying to make it perform some computation fault.

Today, we can examine this leakage via:

Some methods:

The process from Riscure to certify a device can take 2 week to 2 months for a single algorithm.

Power analysis process:

  1. Get a signal
  2. Signal processing
  3. Leakage modeling (if it’s leaky enough)

On Signal Processing:

Open Research Questions:

  1. How to find good EM spots without doing T-testing on each spot?
  2. How to automate the combined problem of filtering, alignment, etc?

Fault Injection:

More open Research questions:

  1. What exactly happens to a circuit when faulted, to inform countermeasures?
  2. More software scalable FI attacks, a la CLKscrew?
    • CLKscrew was able to overclock CPU for a short amount of time to cause a fault
    • Being able to trigger a fault through software is far more scalable instead of having to use things like EM-pulses.

TVLA (T-testing):

More open research questions:

  1. How exploitable are T-spikes in practice?
    • Requires some leakage model to practically find an exploit.
    • Sometimes leakage occurs in different parts of an algorithm, but makes it unexploitable.

DPA key recovery:

More open research questions:

  1. So far, it’s hard to beat CPA in terms of efficiency (couldn’t complete the question)
  2. We rarely perform Differential Fault Analysis. If we can exploit JTAG or boot, how can we more effectively secure this?

Cerification:

Improvements:

More open research questions:

  1. How to automatically creat countermeasures based on test results?
  2. Results on FPGA/non-secure microcontroller do not translate to secure icrocontrollers or SoCs. More results on the latter are needed.

Current research - Deep learning for SCA:

On S-box Masking:

Author notes we rarely perform 2nd order attacks, because sample combing is infeasible due to noise and limited time. How do we find these efficiently?

Conclusions on Deep Learning:

Active research:

Conclusion:

Tink: a cryptographic library

Motivation:

On complex APIs:

On ambiguous yet inextensible APIs:

Outline:

Design goals:

User Perspective - Primitives:

Examples of primitives: - Message Authentication Code (MAC) - Authenticated Encryption with Associated Data (AEAD) - Streaming AEAD

Primitives in Action:

  1. Generate key material via KeysetHandle
    • Templates are possible.
      • Keys for AES-GCM, for example
  2. Get the primitive
    • Like an AEAD, or Streaming AEAD
  3. Use the primitive to encrypt a plaintext
    • Output is simply an array of bytes

Tink Core - keys:

Key Management features: - Key Rotation - via Keysets - A distinguished primary key for creation of crypto data (ciphertexts, signatures, etc) - Matching of crypto data with a suitable key in a keyset - Disabling of obsolete keys - Uniform handling of external keys (KMS, HSM, etc) - “Key” in a keyset contains only a reference to KMS - A keyset can contain both external and regular keys - Gradual deprecation of cryptographic schemes - Can forbid creation of new keys of deprecated schemes

Readability and Auditability:

Extensibility:

Current status and Future plans:

Summary:

Lightning Talks!

  1. Two remarks
    • Blockchain
      • Deprecating remarks are bacause of misunderstanding
    • Urges participation of cryptographers in Hyperledger
      • Wants contribution on “Ursa”, a crypto lib
  2. Zero Knoweldge industry is growing very fast.
    • Mainly related to Blockchain space
    • An initiative called zkproof.org
      • Open initiative between academia and industry
      • Wants to create a set of community standards from the theoretical level to practicioners
      • Planning a second workshop in April 2019
        • Open submissions for proposals
        • Also contributed talks
        • Has a very experienced steering committee
  3. AWS Crypto tools’ goal is to make devs crypto problems go away
    • “We write crypto so you don’t have to!”
    • Working on many crypto and generic tools that don’t work directly with AWS
    • Wants to know what the community needs, code review, plugins, different KMSs, and interoperability with other systems
    • Would love to chat
      • They’re hiring!
  4. Announcements on:
    • Secure messaging
      • First analysis of Signal protocol
      • Formalized properties
      • Modularizable (Post quantum signal when???)
    • Random Number Generation
      • Finally have right models for RNGs
  5. Co-author of TLS1.0 says:
    • Wants to be known as the architect for the Decentralized Identifier
    • Decentralized Identifiers are associated with Blockchains to a fault
    • W3C is going to formalize a working group on it.
      • Spec is up as an early draft form
      • Over 20 companies have implemented various versions of it
      • Great for solving anti-correlation, anonymity, “the decentralized problem” (lolwut)
    • Rebooting web of trust is March 3rd in Barcelona
    • Blockchain commons is trying to fund independent devlopment
  6. Very funny bit relating addiction support to blockchain stuff from Brent from Evernym.
    • Crypto means cryptography
  7. Digital Asset
    • A DLT company
    • Claims every stock trade in Australia will be processed by them
    • Building a language to model business workflows across parties
      • High level
    • Building a platform that’s a runtime for the language
    • Looking for cryptographers and people in formal methods
  8. On the standardization of a BLS signature scheme
    • Uses pairings
    • Nice efficiency properties
      • Specifically aggregation
    • Very useful for Blockchain
    • Algorand is working with Dan Boneh and others to standardize the scheme
    • Will soon submit a draft to CFRG
  9. Subspace labs is building a decentralized database protocol
  10. Easy Safe is distributed and encrypted filesystem
  11. Crypto Quanthique developed first quantum secure something in silicon
    • Looking for more chip developers
  12. Scott from Paragon Initiative Enterprises
    • PHP
      • It powers 83% of web servers according to W3C
      • Wordpress powers a lot too
        • Needs more attention from the crypotgraphic community
  13. Unsure of this one
  14. PhD student from Brown university
    • Cryptography always challenged the limits of possibility e.g. ZK Proofs
    • What if we want to prove ignorance of something?
      • Recent work is proofs of ignorance
      • Joint work with Yale and Microsoft Research
  15. A password generation scheme
    • word passphrases are too long
      • entropy per character is bad
    • BIP-39 reference
      • Pick five words, take first four chars of each
      • Good low bound on entropy
  16. Shameless self promotion
    • New variants for one of Bleichenbacher’s attacks
  17. Katriel
    • Take a minute to think about trees.
    • Organizing a London Crypto Day
      • Like RWC, but smaller
    • Has a mailing list
    • 7th of March
  18. DJB
    • No one enjoys United airlines
    • Very expensive whiskey
    • If you’re flying united this month (Jan 2019)
      • Free vouchers for drinks on United lol
  19. Tech lead for Key Transparency at google
    • Key transparency at Google is open source
    • Also included cert transparency, binary transparency, among other things
    • https://keytransparency.org/
  20. Recommendations for SMPC
    • Something really strong Russian accent
  21. An open source project:
    • We have lots of keys
    • Majority of people have problems backing up keys
    • It’s a work-in-progress
    • Looking for collaborators
    • It’s a Google project
    • Couldn’t understand name
  22. Nadia likes to break cryptography
    • The DSA and ECDSA schemes are randomized
      • Very important to generate random values carefully
      • A recent work on eprint
      • Examined signatures on blockchains
      • Used lattice reduction to compute vulnerabilities
      • Found an attacker w/ bad nonce generation
      • Cool paper, 10⁄10
  23. Jeff from Web3
    • They’re hiring!
    • Organizing a meeting on mix networking
      • In Brussels
  24. An invititation to hashing to curve standardization
    • Many mappings have been published
    • None have proper mapping to hash to the curve
    • Attempting to come up with algorithms to do this
  25. New results on eprint!
    • Encrypted databases
      • Useful for outsourcing data to untrusted server
      • Still want to do queries on the data
      • All schemes leak some information
      • “What are the practical impacts of this leakage?”
      • Attacks have targeted specific leakage
      • There are some open questions on this leakage
      • Access pattern leakage is leaked by all schemes currently
      • Lots of theory speak
      • Very interesting paper w/ practical attacks
      • On eprint now!
      • See https://eprint.iacr.org/2019/011
  26. Many jobs available at RWC
  27. New results!
    • Interoperability between blockchains
    • Communication in a decentralized way
    • A formal definition for a sidechain protocol to be secure
    • on eprint
    • “Proof of Stake sidechains”
  28. Organizing a Summer school on Real World Crypto on Privacy
    • In Croatia
    • In June
  29. Mozilla Security Engineering team
    • Open position for Cryptography engineer
    • Another in six months!

NIST PQC Round 2 Announcements

Direct Anonymous Attestation in the Wild

Outline:

  1. DAA in theory
    • History
    • Formal Analysis
  2. DAA in the Real World
    • Vehicular use case
    • Implementation Challenges

Direct Anonymous Attestation

DAA Schemes:

TPM 2.0 DAA Vulnerabilities

Formal Analysis of ECC-DAA:

DAA impelementation in vehicular architecture:

Immplementation of vehicular architecture

TPM implementation challenges

Future TPM - A Quantum-Resistant TPM

Conclusion:

So how hard is solving LWE/NTRU anyway?

Learning With Errors:

An attack:

Computational problem: - The SVP problem

LLL Algorithm:

Slope:

Strong Lattice Reduction - BKZ Algorithm

Solving SVP:

Enumeration estimates:

Sieving vs Enumeration:

Open Questions:

[ This was a very hard talk to notate, it had many graphs for context ]

An Account of the ISO/IEC Standardization of SIMON and SPECK

ISO/IEC Meeting, Jaipur meeting:

SIMON and SPECK

People are still making new block ciphers?

NSA proposed two block ciphers (SIMON and SPECK) for lightweight block ciphers. This effort emerged in 2013.

Why standardize at ISO?

What about NIST?

Recap:

Goal:

SIMON and SPECK were submitted at:

ISO/IEC Process:

Six steps to publication:

  1. Study period
  2. Working draft
  3. Committee Draft
  4. Draft International Standard
  5. FDIS
  6. Publication

Lots of important decisions happen at physical meetings and there are many working groups at the ISO meetings.

Observations:

Resulting difficulties:

Technical Discussion:

Cryptanalysis:

Generic attacks:

Alternatives?

Summary:

Conclusions:

FORESHADOW: Extracting the Keys to the Intel SGX Kingdom with Transient Out-of-Order Execution

Operating Systems:

Intel delivered SGX unto the world to solve these problems (joke)

SGX

SGX Security Model:

SGX Memory Organization

Security Model fine print:

Speculative Execution Attacks

Enter Foreshadow:

SGX Security:

Collateral damage and Countermeasures:

What can you do with an EPID key?

A single EPID key can be used to sign millions of unlikable signatures. This erodes trust in the entire ecosystem.

RISC-V: An Open Platform for Security R&D

What is RISC-V?

RISC-V Community Evolution

RISC-V Foundation

Why is RISC-V interesting?

RISC-V + Security:

Security-Related R&D

Why should RWC participants care?

See https://riscv.org/

Mailing list: https://riscv.org/mailing-lists/

True2F: Backdoor-resistant authentication tokens

Hardware 2FA tokens are effective against phishing

U2F protocol Steps:

  1. Registration
    • Associate token with account
  2. Authentication
    • Upon login
    • Token sends reponse to challenge

U2F defends against phishing and browser compromise – even if malware takes over your browser. It can’t authenticate without the token.

What about token compromise?

True2F is an enhancement of U2F

True2F Goals:

Design Principles of True2F:

True2F adds a third step to U2F – Initialization

Our CKG protocol (Initialization)

  1. Pick random v, r
  2. Commit to c = H(v,r)
  3. Compute v’ and g^v’
  4. Compute V’ * g^v
  5. return v,r
  6. Check c = H(v, r)
  7. Sorry for not annotating characters.

Verifiable Identity Families:

VIF properties:

  1. Unique – the token can produce the unique keypair for a site.
  2. Verifiable – The token can prove to the browser that the pubkey is really the unqieu pubkey for a site.
  3. Unlinkable
  4. Unforgable

Simplified VIF construction:

  1. Token holds secret x
  2. Browser holds g^x
  3. Browser sends a = H(site)
  4. token does sk,pk = (ax, g^ax)
  5. browser does a = H(site)
  6. Check if pk = X^a

New primitive:

True2F implementation:

True2F is only 2.5x slower than U2F when fully optimized. In the browser, True2F is only 12-16% slower than U2F.

Fast, Furious, and Insecure

Passive Keyless Entry and Start:

Tesla Model S fob:

Getting Started:

Uncovering undocumented SPI commands:

RF Reverse Engineering:

[ Presenter is moving very quickly with lots of visual slides, hard to keep up ]

Day 3

Towards an Open-Source, Formally-Verified Secure Processor

Build enclaves on an enclave platform, not just processes

On Enclaves:

Who do you trust?

15 years ago, we didn’t think sidechannels would be as big of a deal as they are.

The Enclave Lifecycle:

  1. Create enclave, Grant resources
  2. Load enclave
  3. Seal enclave
  4. Enter enclave
    • Process executes in an isolated environment
    • Platform should erase (flushes) sensitive state

Strong Isolation Goal:

The Sanctum Enclave:

[ Speaker is moving too fast to collect enough details ]

Advanced Cryptography on the way to practice

Cryptography research and adoption

Advanced cryptography is: - Needed - Fast enough to be useful - Not “generally usable” yet

Efficiency measures: - Speed - Communication might be limiting resource - Online/offline efficiency - Asymmetric resources - Trade-offs between efficiency and utility

The need for advanced cryptography:

Privacy preserving computation scenarios

Few Input Parties

Federated Learning

Zero Knowledge Proofs

zkSNARKS:

Zero Knowledge without trusted setup - Efficiency is worse than SNARKs - Some discrete log based - BCCGP - Bulletproofs - MPC based - ZKBoo++ - Ligero - IOP Based - Hyrax - ZK-STARKS - Aurora

How to use Advanced Crypto?

It’s time to put these tools to use. – Shai Halevi

Deploying MPC For Social Good

Boston University partners w/ MPC

Closing the Wage Gap in Bostom (see BWWC)

  1. Understanding the root causes of the wage gap
  2. Closing the gap
  3. Evaluating success

MPC is used to protect company data but also allow for studing the wage gap.

Roles & concerns:

MPC Solution:

Economic Inclusion: - Supporting local minority-owned businesses - More than 10 companies participating in these deployements - Smaller scale than the wage gap deployments - Upcoming deployment in March

Detecting seriel perpetrators of sexual misconduct:

[ I need to write a separate note on this talk, it was great! ]

Towards Transparent Zero Knowledge Computation

Transparency and Scalability

Trust - real or perceived?

10 years of commercial use cases:

Privacy-preserving Analytics:

[ This is truly a horrible, irrelevant talk. I’m done taking notes on it. ]

A Full Cryptocurrency Custody Solution Based on MPC and Threshold ECDSA

Custody and Protection

Solution Platform Requirements - High security - Protection against key theft and fraudulant key usage - Backup and disaster recovery - Flexibility - Fine tune security vs usability (ease of transfer) - Broad support - Different coins/systems - Different signing algorithms - Standards (e.g BIP32, BIP44)

Cryptographic Core – Threshold Signing

Protocol vs Platform

Our solution – additional components

Threshold ECDSA

New Threshold ECDSA Protocol

Solution in [GGN16]

  1. Each party chooses two random shares k_i, p_i
    • Use additive sharing: k = k_1 + ... + k_n
  2. Couldn’t complete

Instantiating the Additively Homomorphic Encryption

Decryption

Summary:

[ Too many details going too fast, will update later. ]

A Tangled Curl: How we forged signatures in IOTA

Background:

Terminology

Why examine IOTA?

What is the attack?

Currently doesn’t impact IOTA security

What is “multisig”?

Multisig payments

IOTA background: Signatures

Exploiting Colliding bundles - unauthorized payments

  1. Eve creats two bundles
    • Have same hash
  2. Even gives benign bundle to Bob
    • Bob then signs the Bundle
    • Sends back to Eve
  3. Eve copies Bob’s signature from the benign bundle to the evil bundle
  4. Eve signs and broadcasts the evil bundle

Note: No racing required here, Eve can only broadcast the bundle.

Placing collisions to pay different amounts

Note: works for more than multisig payments, CMA attack fits well here though.

Curl-P-27

Reducing collision resistance

Transformation function is simple

Discussion - what happened

Takeaways:

Troika!

A note on cryptocurrency security:

If interested in working on problems: narula@mit.edu

my name is tux. · notes · art · main

340282366920938463463374607431768211456 115792089237316195423570985008687907853269984665640564039457584007913129639936