Clojurians Log v2

@vikeri Welcome to the sleepy security corner of clojurians.

@xcthulhu: haha thanks!

@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

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

hello

yeah, so, JS crypto

I need to write up some thoughts around that

@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.

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

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

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

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

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

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

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

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

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

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

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/

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

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

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.

right

so: nodejs ffi crypto, no problem

pure JS crypto: not intrinsically bad

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

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

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

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

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"

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

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

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

@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?

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.

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

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

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

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

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

Yes