Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] Snakeoil and suspicious encryption services

Aymeric Vitte vitteaymeric at gmail.com
Tue Jul 22 04:06:36 PDT 2014


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 <vitteaymeric at 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




More information about the liberationtech mailing list