This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-09-06
Channels
- # admin-announcements (10)
- # alda (78)
- # arachne (33)
- # bangalore-clj (2)
- # beginners (11)
- # boot (70)
- # chestnut (8)
- # cljsjs (5)
- # cljsrn (4)
- # clojure (212)
- # clojure-art (1)
- # clojure-berlin (1)
- # clojure-brasil (27)
- # clojure-canada (6)
- # clojure-colombia (12)
- # clojure-dev (6)
- # clojure-greece (29)
- # clojure-hk (2)
- # clojure-italy (7)
- # clojure-russia (51)
- # clojure-spec (12)
- # clojure-uk (18)
- # clojurescript (115)
- # clojurex (8)
- # component (1)
- # crypto (41)
- # css (5)
- # cursive (31)
- # datomic (17)
- # defnpodcast (7)
- # emacs (9)
- # flambo (1)
- # funcool (4)
- # juxt (29)
- # off-topic (1)
- # om (122)
- # onyx (12)
- # pedestal (1)
- # planck (10)
- # portland-or (1)
- # re-frame (30)
- # reagent (4)
- # rum (3)
- # slack-help (2)
- # specter (20)
- # sql (3)
@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
@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
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.
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
@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.
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