Thanks for your comments, please see mine below.
Le 22/07/2014 03:40, coderman a écrit :
On Mon, Jul 21, 2014 at 5:52 PM, Aymeric Vitte <vitteayme...@gmail.com> wrote:
... including your focus on elementary mitm
issue, your arguments and judgement are so basic that I am wondering why I
am answering it, you should do some reading, and if you can trivially defeat
Peersm, then just show us how
problems with js crypto:
- side channels / non constant run time
- lack of access to robust entropy sources
True, or you have to trust your OS prng, but you can imagine solutions.
For example Peersm is establishing multiple circuits inside the Tor
network, those that have already tried this know there are a lot of
impredictable events that can occur during this process (due to the
instability of some nodes, not responding or with random delays, or
wrongly, or randomely breaking circuits, etc), so an idea would be to
use this for entropy.
- unless delivered over pinned HTTPS with CSP vulnerable to mitm attack
I am not sure pinned https is really the solution, what I would like to
have is to clearly identify the certificate of the person I am talking
to (using again third parties and different communication channels), in
practice that's impossible today given the number of certificates used
by major companies (using Cert Patrol to watch this, it's incredible how
day after day this mess is growing up), but possible for an app like
Peersm which is using only one certificate.
So, I have insisted quite a lot of time in WebCrypto to get a feature so
we can expose ssl/tls certificates in js and then check the certificates
(notwithstanding the fact that this feature can be hacked by some code
injections, but in the context of Peersm for example this would not
apply), without success.
And as I previously wrote CSP is more protecting the sites than the
users, anyway this does not apply again for Peersm, there are no issues
of content loading when you have the whole code locally.
- unless an extension, vulnerable to code injection or malicious servers
Yes in general, no for Peersm.
- even as extension, keeps keys in address space of browser with rich
attack surface. (this is true for SSL/TLS as well)
The extension can be mitmed when you get it or update it, as well as its
signature.
contrast this with a configuration where key material is kept isolated
from the rich browser attack surface through low level protections,
e.g. Qubes throwaway browser app vm talking to hidden service. A
separate Tor VM would contain keys for your client on the network and
accessing hidden sites, while the vulnerability rich browser speaks
over this transparent channel managed outside its purview.
for advanced threats, isolation and defense in depth are paramount.
peersm is inherently limited in this regard, not matter how many other
pitfalls it successfully avoids.
No, there is no story of stored keys for Peersm, if you look at the
final specs [1] the keys are generated for each session, it has a cost
but for plenty of reasons including fingerprinting you can not use the
same keys.
It will not be stored and/or use the isolation concepts of WebCrypto,
again since Peersm does not interact with anything else than itself it's
impossible to get the keys, unless there is a physical attack on your
device.
I have not studied right now what it would take to have hidden services
from the browsers.
unfortunately strong isolation and defense in depth are even more
difficult to make easy to use, once again highlighting the
complexities of usability and security in privacy enhancing
technologies.
Still OK and happy that people challenge Peersm concepts if issues and
ways of improvements can be found.
But not OK for people just to deny it based on the fact that it's
javascript inside browsers.
[1]
https://github.com/Ayms/node-Tor#anonymous-serverless-p2p-inside-browsers---peersm-specs
best regards,
--
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
--
Liberationtech is public & archives are searchable on Google. Violations of
list guidelines will get you moderated:
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change
to digest, or change password by emailing moderator at compa...@stanford.edu.
