diff options
Diffstat (limited to 'ta3m/slides.haml')
| -rw-r--r-- | ta3m/slides.haml | 146 |
1 files changed, 115 insertions, 31 deletions
diff --git a/ta3m/slides.haml b/ta3m/slides.haml index d53f36f..c80ddba 100644 --- a/ta3m/slides.haml +++ b/ta3m/slides.haml @@ -1,6 +1,42 @@ -%section +:css + .reveal h1 { + margin-bottom: 30px; + } + .reveal h3 li { + margin-bottom: 10px; + } + .reveal h1, .reveal h3, .reveal p, .reveal li, .reveal .p { + text-shadow: 0px 0px 10px rgba(0, 0, 0, 1) + } + .left-column { + display: block; + width: 50%; + float: left; + } + .right-column { + width: 50%; + float: left; + } + .row { + display: table; + width: 100%; + } + ul.plain { + list-style-type: none; + } + .reveal p, .reveal .p, ul.plain li { + margin-top: 15px; + margin-bottom: 15px; + } + .reveal li { + margin-top: 10px; + margin-bottom: 10px; + } +%section(data-background="images/kid-jumping.svg" data-background-size="50%") %h1 LEAP Encryption Access Project - Elijah Sparrow Sean Leonard + .p.row + .left-column Elijah Sparrow<br>elijah@leap.se<br>@ecsparrow + .right-column Sean Leonard<br>MeanderingCode@leap.se<br>@MeanderingCode %section %h1 What is the goal? @@ -14,18 +50,25 @@ %section %h1 What is the strategy? - %h3 Federated service providers using open protocols + %h3 Federated service providers<br>using open protocols %p (Not peer-to-peer, not centralized) %section %h1 What is the strategy? - %p Bitmask: client application - %p LEAP Platform: service provider automation + .row + .left-column + %h3 Bitmask + %p Cross platform client application + .right-column + %h3 LEAP Platform + %p Service provider automation -%section +%section(data-background="") + %p + %img{src: "images/bitmask-icon.png", style:"height: 200px; width 200px; float: left;"} %h1 Bitmask - %p With Bitmask App, you choose among any LEAP-powered service provider. + %p With Bitmask App, you choose among any<br>LEAP-powered service provider. %p Currently, we support VPN and Email. %section @@ -35,6 +78,8 @@ %li Auto-configuring %li Single click VPN %li Email via a local IMAP and SMTP services. + %p + %img{src: "images/bitmask-main-window.jpg" } %section %h1 LEAP Platform @@ -59,6 +104,9 @@ %li Heavily customizable: override node behavior with tags & environments. Easy to fork. %li Includes a testing and monitoring framework. %li Includes a webapp with user management, help tickets and billing. + %p + See + %a(href="https://leap.se/platform") leap.se/platform %section %h3 How to make something easy and secure? @@ -67,7 +115,8 @@ %section %h1 A better UI - %p image of android app on/off dashboard + %p + %img(src="images/bitmask-android.png") %section %h1 A better UI @@ -94,29 +143,49 @@ %section %h1 Data availability - %p issue 1: can't use normal hashed passwords. - %p solution: use Secure Remote Password, two pass authentication scheme built on a zero knowledge proof such that the server never has access to the password. + %ul.plain + %li + %b Issue 1: + can't use normal hashed passwords. + %li + %b Solution: + use Secure Remote Password, two pass authentication scheme built on a zero knowledge proof such that the server never has access to the password. %section %h1 Data availability - %p issue 2: when stored locally, we need the data in a database. - %p solution: stored local in sqlcipher (encrypted sqlite db) + %ul.plain + %li + %b Issue 2: + when stored locally, we need the data in a database. + %li + %b Solution: + stored local in sqlcipher (encrypted sqlite db) %section %h1 Data availability - %p issue 3: don't trust the provider - %p - solution: client's individually encrypt each document record before synchronizing with distributed cloud database. - %a(href="https://leap.se/soledad") leap.se/soledad + %ul.plain + %li + %b Issue 3: + don't trust the provider + %li + %b Solution: + clients individually encrypt each document record before synchronizing with distributed cloud database. + %a(href="https://leap.se/soledad") leap.se/soledad %section %h1 Secure identity - %p Bedrock precondition for secure communication between to people: all other security properties flow from it. + %p Bedrock precondition for secure communication between two people. + %p All other security properties flow from it. %section %h1 Secure identity - %p Zooko's triangle: identifers may be globally unique, easy to remember, or decentralized: pick two. - %p The binding problem: how to strongly bind a human name to a long random cryptographic key. + %ul.plain + %li + %b Zooko's triangle: + identifers may be globally unique, easy to remember, or decentralized: pick two. + %li + %b The binding problem: + how to strongly bind a human name to a long random cryptographic key. %section %h1 Secure identity @@ -126,11 +195,22 @@ %section %h1 Secure identity %p What we are trying: - %ul - %li TOFU - trust on first use. - %li Provider endorsement - providers sign & revoke user public keys. - %li Network perspective - audit providers to keep them honest. - %P Gradual, backward compatible, ramp up. + %ol + %li + %b TOFU: + Trust On First Use. + %li + %b Provider endorsement: + providers sign & revoke user public keys. + %li + %b Network perspective: + audit providers to keep them honest. + %p + %p Goals: gradual adoption, backward compatible, ramp up. + %p + See + %a(href="https://leap.se/nicknym") leap.se/nicknym + %section %h1 Meta-data problem @@ -166,10 +246,14 @@ %section %h1 Why not p2p? %ul - %li The "natural" network: many to many networks don't look like networks found in nature, which follow a power law ("scale free") distribution. - %li The Internet: internet infrastructure is actually very polycentric rather than decentralized (more akin to a tree than a spider's web). - %li Traffic Analysis: p2p message routing schemes are more vulnerable to traffic analysis. - %li Sybil Attacks: By their nature, peer-to-peer networks are highly vulnerable to Sybil attacks, where an attacker creates fake participants in order to reveal secrets or hijack network. - %li Mobile: Peer-to-peer networks are resource intensive, typically with every node in the network responsible for continually relaying traffic and keeping the network healthy. - %li Identifiers: There are no good schemes for secure p2p identity. Everyone uses fingerprints, but this makes user identifiers impossible to remember. - %li Data Availability: p2p has very poor data availability. + %li <b>The "natural" network:</b> many to many networks don't look like networks found in nature, which follow a power law ("scale free") distribution. + %li <b>The Internet:</b> internet infrastructure is actually very polycentric rather than decentralized (more akin to a tree than a spider's web). + %li <b>Traffic Analysis:</b> p2p message routing schemes are more vulnerable to traffic analysis. + %li <b>Sybil Attacks:</b> By their nature, peer-to-peer networks are highly vulnerable to Sybil attacks, where an attacker creates fake participants in order to reveal secrets or hijack network. + +%section + %h1 Why not p2p? + %ul + %li <b>Mobile:</b> Peer-to-peer networks are resource intensive, typically with every node in the network responsible for continually relaying traffic and keeping the network healthy. + %li <b>Identifiers:</b> There are no good schemes for secure p2p identity. Everyone uses fingerprints, but this makes user identifiers impossible to remember. + %li <b>Data Availability:</b> p2p has very poor data availability. |