: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
  .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?
  %h3 Communication that is
  %h3
    %ul
      %li super easy
      %li super secure
  %p
    For example: email, chat, voice, files, VPN.

%section
  %h1 What is the strategy?
  %h3 Federated service providers<br>using open protocols
  %p (Not peer-to-peer, not centralized)


%section
  %h1 What is the strategy?
  .row
    .left-column
      %h3 Bitmask
      %p Cross platform client application
    .right-column
      %h3 LEAP Platform
      %p Service provider automation

%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<br>LEAP-powered service provider.
  %p Currently, we support VPN and Email.

%section
  %h1 Bitmask
  %h3
    %ul
      %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
  %p A few people with high skill but without unlimited time should be able to run a service provider.
  %pre
    %code.bash(data-trim)
      :preserve
        sudo gem install leap_cli
        leap new example --domain example.org
        cd example
        leap add-user --self
        leap node add blueberry services:openvpn ip_address:1.1.1.1
        leap node add rasberry services:couchdb,webapp ip_address:2.2.2.2
        leap node init
        leap deploy

%section
  %h1 LEAP Platform
  %ul
    %li Everything is just a JSON configuration.
    %li Can use git to maintain your provider.
    %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?
  %p Just create a better user interface!
  %p Yes and no.

%section
  %h1 A better UI
  %p
    %img(src="images/bitmask-android.png")

%section
  %h1 A better UI
  %p In many cases, it turns out that is not enough.
  %p No point in polishing a turd.

%section
  %h1 Hard problems
  %h3 in making security easy.
  %ol
    %li Data availability problem
    %li Secure identity validation problem
    %li Meta-data problem
    %li Asynchronous forward secrecy problem
  %p and many others...

%section
  %h1 Data availability
  %ul
    %li Securely back up data to the cloud
    %li Available on all devices
    %li Ensure it is also encrypted locally
    %li Ensure access to data even when offline

%section
  %h1 Data availability
  %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
  %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
  %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 two people.
  %p All other security properties flow from it.

%section
  %h1 Secure identity
  %ul.plain
    %li
      %b Zooko's triangle:
      identifiers 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
  %p Existing models don't work: X.509 or WoT.
  %p New ideas: TOFU, DANE, CT, Namecoin.

%section
  %h1 Secure identity
  %p What we are trying:
  %ul.plain
    %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
  %p The problems:
  %ul.plain
    %li Headers in email are not end-to-end encrypted.
    %li Network observers, and your service provider, knows who you are corresponding with.

%section
  %h1 Meta-data problem
  %p Our solutions:
  %ul.plain
    %li
      %b Short term:
      use StartTLS with enforced certificate validation via DANE.
    %li
      %b Long term:
      direct delivery of email to recipient's provider using SMTP over Tor.

%section
  %h1 Asynchronous forward secrecy
  %p Why forward secrecy? Needed to future-proof your security.
  %ul.plain
    %li
      %b Short term:
      frequently rotating OpenPGP encryption sub-keys.
    %li
      %b Long term:
      Axolotl? <a href="https://github.com/trevp/axolotl/wiki">github.com/trevp/axolotl/wiki</a>

%section
  %h1 Links
  %p
    LEAP Encryption Access Project
    %a(href="https://leap.se") https://leap.se
  %p
    Bitmask App
    %a(href="https://bitmask.net") https://bitmask.net
  %p
    Demo
    %a(href="https://demo.bitmask.net") https://demo.bitmask.net

%section
  %h1 Appendix

%section
  %h1 Why not p2p?
  %ul
    %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.