SLIDE 1
Javascript Crypto &
The Case Against Crypto Reductionism Ben Adida
Mozilla Workshop on Real-World Crypto January 2013
SLIDE 2 promote openness, innovation & opportunity on the Web.
SLIDE 4
- easy to deploy
- easy to use
- privacy protecting
SLIDE 5
SLIDE 6
SLIDE 7
SLIDE 8 How to implement it
navigator.id.request();
- Obtain proof of email address ownership:
- Verify it and go.
SLIDE 9
How it works
SLIDE 10
We Make it Work Today
SLIDE 11
We Make it Work Today
SLIDE 12 We Make it Work Today
- include a JS library
- that implements
navigator.id.*
postMessage communication to shim new browser functionality.
SLIDE 13 Why this approach?
- works today, in 20 LoC, on all browsers
with a shim Javascript library
- as browsers implement native support,
the user experience improves dramatically while web sites don't need to change a thing
- deploying new distributed technology is hard
scaffold + strategy for removing scaffolding
SLIDE 14
- in-browser crypto for e2e
- encryption. Clipperz, SJCL,
Mozilla, Helios, ...
- "web sites that do crypto in
browser Javascript are doomed."
what crypto is running, or even if crypto is running.
- if attacker breaks into server,
can change client crypto.
Do it on the server.
SLIDE 15 Highly Pragmatic Reasons
- progressive enhancement to web
- packaged web apps are coming
- increasingly stronger guarantees
- f code integrity (CSP, HSTS, ...)
SLIDE 16
But even without that...
SLIDE 17
Trust is all-or-nothing if I trust server to deliver crypto code, I might as well trust it with my data. Mistake #1
SLIDE 18
Compromises are all-or-nothing if attacker can extract DB data can also modify served JS code. Mistake #2
SLIDE 19 All targets are equally attractive a server with millions of user accounts
- vs. a single user's computer
Mistake #3
SLIDE 20
Implementations are perfect e.g. discarding information is the same as never receiving it in the first place. Mistake #4
SLIDE 21 security in practice is about defense in depth Crypto in browser is
SLIDE 22
threat models are not all-or-nothing