Fork me on GitHub
#crypto
<
2016-09-06
>
xcthulhu16:09:01

@vikeri Welcome to the sleepy security corner of clojurians.

xcthulhu17:09:00

@vikeri The only other guy I know around here who also does security is @lvh - he maintains a NaCl wrapper - https://github.com/lvh/caesium

xcthulhu17:09:01

Server-side only though, I personally believe there will be a massive demand for JS crypto as developers spend more and more time in the JS VM

lvh17:09:49

yeah, so, JS crypto

lvh17:09:04

I need to write up some thoughts around that

vikeri17:09:36

@lvh @xcthulhu interesting! Yes there will definitely be a big demand for js crypto, not only all the node apps, but things like react native will increase demands as well. One may reach out to Java or Obj-C but it would definitely be more convenient to stay in the js realm.

lvh17:09:51

that’s a significant difference though; if you’re running in react native you can probably libffi out

lvh17:09:07

you don’t get to do that as much with browser crypto

lvh17:09:30

my main concern is threat models (or ostensible lack thereof)

lvh17:09:43

I can think of a handful of usecases where it works reasonably well

lvh17:09:55

1. KDFing in the browser, which may or may not be sane

lvh17:09:22

2. compatibility with some other thing where you do have a way to ship code

xcthulhu17:09:33

@lvh: You know that the closure-library ships with PKDF2, right?

lvh17:09:07

sure, there’s plenty of pure-js crypto that exists

lvh17:09:30

I’m not sure if you intended that to impact my point

lvh17:09:42

or if it was just a by-the-way comment

xcthulhu17:09:00

Just a by-the-way, really. You can effectively wrap FFI calls in Chrome/Safari/FireFox via the W3C WebCrypto API - https://www.w3.org/TR/WebCryptoAPI/

xcthulhu17:09:59

Probably the biggest downside is that JSC doesn't implement it, which is what all of the ReactNative app developers want.

xcthulhu17:09:58

I guess you wouldn't be super happy with it either, since it doesn't implement ED25519 or Twisted Edwards curves in general.

xcthulhu18:09:07

Also, there's no particular way to protect crypto from getting overridden, so an attacker could inject JS and hack it to produce signatures with recoverable private keys.

lvh18:09:51

so: nodejs ffi crypto, no problem

lvh18:09:59

pure JS crypto: not intrinsically bad

lvh18:09:27

just that everyone I’ve talked to so far in depth who wanted either a) wanted compatibility with another thing where they could securely ship crypto or b) it hadn’t really thought about their threat model

xcthulhu19:09:04

@lvh For my own work, I want it because I need to do user authentication by third parties out of band.

xcthulhu19:09:45

Clients I have talked to want it to avoid having so-called hot-wallets on their servers which are a massive liability.

xcthulhu19:09:03

It's worth noting in the little cottage industry of JavaScript P2P networks, folks reimplement JS crypto time and time again. Here's the one libp2p uses - https://github.com/libp2p/js-libp2p-crypto/blob/master/src/keys/rsa.js

lvh19:09:11

right; so my problem isn’t “I can’t figure out why you might want that”, but rather “in-browser, I can’t think of any use cases where the server couldn’t trivially compromise it in the manner you described above anyway"

xcthulhu19:09:31

If it's bundled in a ReactApp, I suppose you place your trust in the Google and Apple stores.

xcthulhu19:09:41

I have recommended to my clients hell-bent on having browser wallets that they use IPFS. The state of the industry is horrible right now, but there is a browser plugin for this - https://github.com/dylanPowers/ipfs-chrome-extension

xcthulhu19:09:31

The plan is to move away from calling the IPFS daemon and use JavaScript instead.

xcthulhu19:09:28

@lvh: Anyway, even if you are placing trust in the server for content delivery, wouldn't having JavaScript handle all of private-key signatures for a digital currency wallet spare you from storing them on the backend?

xcthulhu19:09:28

So you wind up with less attack surface, because a DB filled with hot-wallets is a very easy target for a thief compared to hacking some JS to send you private keys or passwords out of band.

xcthulhu20:09:00

Or in band, I guess, if you've accessed the server...

lvh20:09:58

It’s a different threat surface, I’m not sure it’s less

lvh20:09:27

It becomes a lot easier to steal a hot wallet with anything targeting that user’s browser

lvh20:09:52

So if the question is “is stealing hot wallets easier if they’re all on the server versus if you have to compromise them on clients via content delivery” then, I guess; is it better than the content delivery problem plus CSRF/XSS? maybe less sure

xcthulhu20:09:14

You can steal passwords just as easily as you can steal private keys if you compromise content delivery, right?