From 2aa52d6b9bf3ace309cf032d168676ad09a69f4b Mon Sep 17 00:00:00 2001 From: elijah Date: Mon, 21 Apr 2014 14:58:27 -0700 Subject: added images to ta3m presentation and improved formatting. --- README.md | 11 +- ta3m/images/bitmask-android.png | Bin 0 -> 65842 bytes ta3m/images/bitmask-icon.png | Bin 0 -> 80238 bytes ta3m/images/bitmask-main-window.jpg | Bin 0 -> 71840 bytes ta3m/images/kid-jumping.svg | 757 ++++++++++++++++++++++++++++++++++++ ta3m/slides.haml | 146 +++++-- 6 files changed, 882 insertions(+), 32 deletions(-) create mode 100644 ta3m/images/bitmask-android.png create mode 100644 ta3m/images/bitmask-icon.png create mode 100644 ta3m/images/bitmask-main-window.jpg create mode 100644 ta3m/images/kid-jumping.svg diff --git a/README.md b/README.md index acd6059..1e2a62c 100644 --- a/README.md +++ b/README.md @@ -37,4 +37,13 @@ Presentations * `ta3m` draft of ta3m slides. - Uses reveal-ck \ No newline at end of file + Uses reveal-ck + +Reveal Options +------------------------- + +* transition options: zoom, fast, fade, slide +* keys: + * f: fullscreen mode + * o: overview mode + * esc: exit fullscreen or overview modes. \ No newline at end of file diff --git a/ta3m/images/bitmask-android.png b/ta3m/images/bitmask-android.png new file mode 100644 index 0000000..3ef960d Binary files /dev/null and b/ta3m/images/bitmask-android.png differ diff --git a/ta3m/images/bitmask-icon.png b/ta3m/images/bitmask-icon.png new file mode 100644 index 0000000..0875f42 Binary files /dev/null and b/ta3m/images/bitmask-icon.png differ diff --git a/ta3m/images/bitmask-main-window.jpg b/ta3m/images/bitmask-main-window.jpg new file mode 100644 index 0000000..87cf3ad Binary files /dev/null and b/ta3m/images/bitmask-main-window.jpg differ diff --git a/ta3m/images/kid-jumping.svg b/ta3m/images/kid-jumping.svg new file mode 100644 index 0000000..7a330fd --- /dev/null +++ b/ta3m/images/kid-jumping.svg @@ -0,0 +1,757 @@ + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 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
elijah@leap.se
@ecsparrow + .right-column Sean Leonard
MeanderingCode@leap.se
@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
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
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 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. + +%section + %h1 Why not p2p? + %ul + %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. -- cgit v1.2.3