Re: [liberationtech] Piratebrowser?
On 08/11/2013 12:51 AM, Tom Ritter wrote:
Some other random stats for the curious.
Tor v0.2.3.25 (git-17c24b3118224d65)
Vidalia 0.2.21 (QT 4.8.1)
# Configured for speed
ExcludeSingleHopRelays 0
EnforceDistinctSubnets 0
AllowSingleHopCircuits 1
# Exclude countries that might have blocks
ExcludeExitNodes {dk},{ie},{gb},{nl},{be},{it},{cn},{ir},{fi},{no}
#Selected user prefs
user_pref(browser.startup.homepage, http://6kkgg7nth3sbuuwd.onion;);
user_pref(general.useragent.override, PB0.6b Mozilla/5.0 (Windows
NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0);
-tom
It's pretty surprising that the Pirate Bay went this route. I have a
hard time believing that it isn't just some kind of publicity stunt.
They also released the browser as an exe when the site doesn't use
SSL/https. Which is kind of an interesting choice, considering their
stated desire to target Iran (of all places).
About a year ago, I wrote a quick Chrome plugin for torrenters to
bypass the common DNS blocks on TPB and similar sites. Users from the
UK and the Netherlands (both places where they have a large userbase)
had recently been blocked from accessing TPB. I have a hard time
believing that Iran represents more than a negligible number of possible
Pirate Bay users. It could be a scheme to get more of their users to
use privacy-protecting techniques, but a guide might have more of an
effect there. If their only goal is to bypass censorship of this one
site, there are easier methods that are just as effective. The plugin I
made was trivial to write and it wouldn't be difficult for the pirate
bay to do something similar (quite a few plugins exist already, and it
wouldn't be hard to just pick one to promote).
~Griffin
--
Cypherpunks write code not flame wars. --Jurre van Bergen
#Foucault / PGP: 0xAE792C97 / OTR: sa...@jabber.ccc.de
My posts, while frequently amusing, are not representative of the thoughts of
my employer.
--
Liberationtech is a public list whose 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.
Re: [liberationtech] From Snowden's email provider. NSL???
The app store can't substitute a different binary (no developer signing key), users can verify that the app was what the developer produced (via pulling the binary and checking the hash), and advanced users can verify that what the developer produced is what they produce via the replicable build process. I don't know how the Apple or Chrome app stores work, but on Android the user doesn't have a standard way to obtain the developer's key, so the app store could sign a modified binary with any key. In any case, verifying a signature or hash against a public key or expected hash (obtained how?) is currently a manual process that non-experts can't be expected to carry out, let alone understand. What I'm looking for is a way to automate that process to protect non-experts. As far as I can see, locked-down platforms like iOS and ChromeOS make it impossible in theory to tell whether the trust root (Apple/Google) is providing binaries built from published source code, because there's no way to get a verifier onto the device unless it's also approved (and potentially tampered with) by the trust root. But I think the situation for browser-downloaded software and Android apps might be less bleak. One aspect that concerns me is rollback attacks: if the verifier accepts binaries that aren't listed in the public log, can the adversary tamper with the identifying attributes of the tampered binary (name, URL, etc) so the verifier doesn't realise there's a log entry that the binary should match? Cheers, Michael -- Liberationtech is a public list whose 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.
Re: [liberationtech] Piratebrowser?
On 11 August 2013 03:39, Griffin Boyce griffinbo...@gmail.com wrote:
On 08/11/2013 12:51 AM, Tom Ritter wrote:
Some other random stats for the curious.
Tor v0.2.3.25 (git-17c24b3118224d65)
Vidalia 0.2.21 (QT 4.8.1)
# Configured for speed
ExcludeSingleHopRelays 0
EnforceDistinctSubnets 0
AllowSingleHopCircuits 1
# Exclude countries that might have blocks
ExcludeExitNodes {dk},{ie},{gb},{nl},{be},{it},{cn},{ir},{fi},{no}
#Selected user prefs
user_pref(browser.startup.homepage, http://6kkgg7nth3sbuuwd.onion;);
user_pref(general.useragent.override, PB0.6b Mozilla/5.0 (Windows
NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0);
-tom
It's pretty surprising that the Pirate Bay went this route. I have a
hard time believing that it isn't just some kind of publicity stunt.
They also released the browser as an exe when the site doesn't use
SSL/https. Which is kind of an interesting choice, considering their
stated desire to target Iran (of all places).
About a year ago, I wrote a quick Chrome plugin for torrenters to
bypass the common DNS blocks on TPB and similar sites.
In the UK I thought blocks were IP-based, hence this piece of
amusement: https://www.openrightsgroup.org/blog/2013/sky-torrentfreak-blocking.
Users from the
UK and the Netherlands (both places where they have a large userbase)
had recently been blocked from accessing TPB. I have a hard time
believing that Iran represents more than a negligible number of possible
Pirate Bay users. It could be a scheme to get more of their users to
use privacy-protecting techniques, but a guide might have more of an
effect there. If their only goal is to bypass censorship of this one
site, there are easier methods that are just as effective. The plugin I
made was trivial to write and it wouldn't be difficult for the pirate
bay to do something similar (quite a few plugins exist already, and it
wouldn't be hard to just pick one to promote).
~Griffin
--
Cypherpunks write code not flame wars. --Jurre van Bergen
#Foucault / PGP: 0xAE792C97 / OTR: sa...@jabber.ccc.de
My posts, while frequently amusing, are not representative of the thoughts of
my employer.
--
Liberationtech is a public list whose 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.
--
Liberationtech is a public list whose 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.
[liberationtech] In defense of client-side encryption
Twice again, privacy has taken a hit across the land. Lavabit and Silent Mail are gone, and to quote Phil Zimmermann, “the writing is on the wall” for any other encrypted email provider located in US territory. This is sure to be repeated for servers located in Europe and other countries. Is this the end of encrypted email? It might well be the end of encrypted email _servers_, at least for a while, but not of encrypted email itself. I’ve posted this a few times here, but let me repeat it: you only get real security if the encryption is handled completely client-side. Then you don’t rely on a server that can be shut down. You can use any mail system, web-based or otherwise. They’d have to shut down every mail provider and every text provider in order to shut you down. This is what PGP was when it started. We need to go back to that. And yes, client-side today might mean JavaScript. What’s so wrong with that? Sure, it is easy to intercept and modify, but it is also transparent and easy to check. If the user is willing to check a hash of the source code, JavaScript isn’t any less tamper-proof than compiled code. And who even gets to look at compiled code these days (especially if it resides in a server)? This is one of the reasons why I am developing PassLok. Thanks to feedback from members of this forum, the security provided by PassLok is stronger than ever, but you don’t have to believe me. Download it from its source at https://passlok.site44.com (once you have it once, you have it forever), look at it, run it, test it. Get its SHA256 hash from its help page and check it. If you’re as paranoid as I am, you can watch me reading that hash (with some nice background music to make tampering with it more difficult), in this youtube video: https://www.youtube.com/watch?v=VHR_w0FCkC0 There’s no legal action that can shut down PassLok because it consist of pure code, and pure code is speech, protected from government interference under the 1st amendment to the US Constitution. If you don’t think this is enough, let us all know. Let’s come up with a solution. Meanwhile, I appreciate any suggestions on how to make PassLok more secure and easier to use. -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL13lok=WsH3zTgZn8V3hnIqjdbfPus+5YF5n+LBRPuH9USMMp8izPv+hsLoZKv+jaCFMapJFfiA11Q9yJU1K1Wo0TbjXK/=PL13lok get the PassLok privacy app at: http://passlok.com -- Liberationtech is a public list whose 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.
Re: [liberationtech] In defense of client-side encryption
Side note: please don't use LibTech as a marketing tool. Occasional mentions are good, but I feel like you're flagging it a little too much and too often. Just a friendly note. :) On Sun, Aug 11, 2013 at 1:10 PM, Francisco Ruiz r...@iit.edu wrote: Twice again, privacy has taken a hit across the land. Lavabit and Silent Mail are gone, and to quote Phil Zimmermann, “the writing is on the wall” for any other encrypted email provider located in US territory. This is sure to be repeated for servers located in Europe and other countries. Is this the end of encrypted email? It might well be the end of encrypted email _servers_, at least for a while, but not of encrypted email itself. I’ve posted this a few times here, but let me repeat it: you only get real security if the encryption is handled completely client-side. Then you don’t rely on a server that can be shut down. You can use any mail system, web-based or otherwise. They’d have to shut down every mail provider and every text provider in order to shut you down. This is what PGP was when it started. We need to go back to that. And yes, client-side today might mean JavaScript. What’s so wrong with that? Sure, it is easy to intercept and modify, but it is also transparent and easy to check. If the user is willing to check a hash of the source code, JavaScript isn’t any less tamper-proof than compiled code. And who even gets to look at compiled code these days (especially if it resides in a server)? This is one of the reasons why I am developing PassLok. Thanks to feedback from members of this forum, the security provided by PassLok is stronger than ever, but you don’t have to believe me. Download it from its source at https://passlok.site44.com (once you have it once, you have it forever), look at it, run it, test it. Get its SHA256 hash from its help page and check it. If you’re as paranoid as I am, you can watch me reading that hash (with some nice background music to make tampering with it more difficult), in this youtube video: https://www.youtube.com/watch?v=VHR_w0FCkC0 There’s no legal action that can shut down PassLok because it consist of pure code, and pure code is speech, protected from government interference under the 1st amendment to the US Constitution. If you don’t think this is enough, let us all know. Let’s come up with a solution. Meanwhile, I appreciate any suggestions on how to make PassLok more secure and easier to use. -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL13lok=WsH3zTgZn8V3hnIqjdbfPus+5YF5n+LBRPuH9USMMp8izPv+hsLoZKv+jaCFMapJFfiA11Q9yJU1K1Wo0TbjXK/=PL13lok get the PassLok privacy app at: http://passlok.com -- Liberationtech is a public list whose 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. -- @kylemaxwell -- Liberationtech is a public list whose 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.
Re: [liberationtech] In defense of client-side encryption
On 08/11/13 20:10, Francisco Ruiz wrote: Download it from its source at https://passlok.site44.com (once you have it once, you have it forever), look at it, run it, test it. Get its SHA256 hash from its help page and check it. If you’re as paranoid as I am, you can watch me reading that hash (with some nice background music to make tampering with it more difficult), in this youtube video: https://www.youtube.com/watch?v=VHR_w0FCkC0 A few things: 1. I have to *run* it to get the hash of the application from the help page. That is already a leap of faith to run unverified code. 2. I have to verify the hash code with a spoken message in a youtube video. The message is spoken by someone I've never met, so how do I verify that it is you who's saying it and not an actor hired by a spooky agency? Or just dubbed with a new audio score. Hollowood can do that without a blink. 3. How can I validate that the youtube url is correct? They are all gibberish to me. Again could be a fake by some adversary. This mail was not encrypted and validated. I do *like* your spoken hash verification mechanism. But for it to work you need to achieve celebrity status. If someone would announce SecureBieberMail, there are some people in my surroundings that can vouch for the identity of the speaker. (web of trust) There’s no legal action that can shut down PassLok because it consist of pure code, and pure code is speech, protected from government interference under the 1^st amendment to the US Constitution. Theoretically you are correct. In practice, we've seen the value of your US constitution... Guido. -- Liberationtech is a public list whose 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.
Re: [liberationtech] Secure Android guide?
I read this: http://www.wired.co.uk/news/archive/2013-08/09/recycling-bins-are-watching-you The unique identifying numbers of over half a million smartphones have been recorded by a network of recycling bins in central London. Hundreds of thousands of pedestrians walking past 12 locations unknowingly had the unique MAC address of their smartphones recorded by Renew London. Maybe also it should be added to this list, some thought about MAC and DHCP randomness? Is this feature included in any of tools recommended? -- Jerzy Łogiewa -- jerz...@interia.eu -- Liberationtech is a public list whose 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.
Re: [liberationtech] In defense of client-side encryption
On 11/08/13 at 01:10pm, Francisco Ruiz wrote: Twice again, privacy has taken a hit across the land. Lavabit and Silent Mail are gone, and to quote Phil Zimmermann, “the writing is on the wall” for any other encrypted email provider located in US territory. This is sure to be repeated for servers located in Europe and other countries. Is this the end of encrypted email? [cut] IMHO you are making big statements, taking a lot of risks, and a lot of people's life on your back, as we're not playing here. Are you sure to have big enough shoulder? First, it is in Javascript. Who needs cryptography, SHOULD NOT use javascript. Google can help you ([1] for example, [2] if you are coming from a 48h non-stop no-sleep marathon). Second, someone posted about your random number generator, and you ignored it. But this is a minor problem, as all things are in Javascript. Third, you use Javascript. But, wait, I need to sleep. Please stop spamming an insecure-by-design product. Last thing: People, please, use PGP instead of these circus things. [1] http://www.matasano.com/articles/javascript-cryptography/ [2] https://www.google.it/search?q=why%20is%20bad%20crypto%20javascript -- Liberationtech is a public list whose 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.
Re: [liberationtech] In defense of client-side encryption
On 11/08/13 20:36, danimoth wrote: On 11/08/13 at 01:10pm, Francisco Ruiz wrote: Twice again, privacy has taken a hit across the land. Lavabit and Silent Mail are gone, and to quote Phil Zimmermann, “the writing is on the wall” for any other encrypted email provider located in US territory. This is sure to be repeated for servers located in Europe and other countries. Is this the end of encrypted email? [cut] IMHO you are making big statements, taking a lot of risks, and a lot of people's life on your back, as we're not playing here. Are you sure to have big enough shoulder? First, it is in Javascript. Who needs cryptography, SHOULD NOT use javascript. Google can help you ([1] for example, [2] if you are coming from a 48h non-stop no-sleep marathon). Second, someone posted about your random number generator, and you ignored it. But this is a minor problem, as all things are in Javascript. Third, you use Javascript. But, wait, I need to sleep. Please stop spamming an insecure-by-design product. I think you forgot to mention the design flaw that it implements crypto in javascript. Last thing: People, please, use PGP instead of these circus things. Hear, hear. I never bought this whole users will never install software argument. Have you seen the sort of crap the typical non-technical user has installed? [1] http://www.matasano.com/articles/javascript-cryptography/ [2] https://www.google.it/search?q=why%20is%20bad%20crypto%20javascript -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git -- Liberationtech is a public list whose 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.
Re: [liberationtech] In defense of client-side encryption
Hello everyone: I believe we need is an standard way to do client side encryption in the web. We need secure end-to-end communications in the web, so that we don't need to be trust and dependent on the html/css/javascript given by any server. We have a server in the middle security problem. This is different from a man in the middle, where there's *potentially* someone spying in the middle: in the web, by design, there's a server in the middle. We should not trust this server just because it's part of the design. This might seem like the holy grail, but it's not something unachievable (but it's surely very difficult to solve in a nice general way), here I talk about this problem: http://edulix.wordpress.com/2012/01/08/the-server-in-the-middle-problem-and-solution/ . BTW, as a funny note, I gave a lighting talk about the server in the middle in Madrid Google's offices in 2012, showing in the slides google as being that server. People assisting to the talk loved the talk, but I think the google people didn't, as they didn't call me again next year for the same event (which was remote Google I/O). Regards, On Sun, Aug 11, 2013 at 8:10 PM, Francisco Ruiz r...@iit.edu wrote: Twice again, privacy has taken a hit across the land. Lavabit and Silent Mail are gone, and to quote Phil Zimmermann, “the writing is on the wall” for any other encrypted email provider located in US territory. This is sure to be repeated for servers located in Europe and other countries. Is this the end of encrypted email? It might well be the end of encrypted email _servers_, at least for a while, but not of encrypted email itself. I’ve posted this a few times here, but let me repeat it: you only get real security if the encryption is handled completely client-side. Then you don’t rely on a server that can be shut down. You can use any mail system, web-based or otherwise. They’d have to shut down every mail provider and every text provider in order to shut you down. This is what PGP was when it started. We need to go back to that. And yes, client-side today might mean JavaScript. What’s so wrong with that? Sure, it is easy to intercept and modify, but it is also transparent and easy to check. If the user is willing to check a hash of the source code, JavaScript isn’t any less tamper-proof than compiled code. And who even gets to look at compiled code these days (especially if it resides in a server)? This is one of the reasons why I am developing PassLok. Thanks to feedback from members of this forum, the security provided by PassLok is stronger than ever, but you don’t have to believe me. Download it from its source at https://passlok.site44.com (once you have it once, you have it forever), look at it, run it, test it. Get its SHA256 hash from its help page and check it. If you’re as paranoid as I am, you can watch me reading that hash (with some nice background music to make tampering with it more difficult), in this youtube video: https://www.youtube.com/watch?v=VHR_w0FCkC0 There’s no legal action that can shut down PassLok because it consist of pure code, and pure code is speech, protected from government interference under the 1st amendment to the US Constitution. If you don’t think this is enough, let us all know. Let’s come up with a solution. Meanwhile, I appreciate any suggestions on how to make PassLok more secure and easier to use. -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL13lok=WsH3zTgZn8V3hnIqjdbfPus+5YF5n+LBRPuH9USMMp8izPv+hsLoZKv+jaCFMapJFfiA11Q9yJU1K1Wo0TbjXK/=PL13lok get the PassLok privacy app at: http://passlok.com -- Liberationtech is a public list whose 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. -- Eduardo Robles Elvira +34 668 824 393skype: edulix2 http://www.wadobo.comit's not magic, it's wadobo! -- Liberationtech is a public list whose 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.
Re: [liberationtech] In defense of client-side encryption
On 2013-08-11, at 10:36 PM, danimoth danim...@cryptolab.net wrote: On 11/08/13 at 01:10pm, Francisco Ruiz wrote: Twice again, privacy has taken a hit across the land. Lavabit and Silent Mail are gone, and to quote Phil Zimmermann, “the writing is on the wall” for any other encrypted email provider located in US territory. This is sure to be repeated for servers located in Europe and other countries. Is this the end of encrypted email? [cut] IMHO you are making big statements, taking a lot of risks, and a lot of people's life on your back, as we're not playing here. Are you sure to have big enough shoulder? First, it is in Javascript. Who needs cryptography, SHOULD NOT use javascript. Google can help you ([1] for example, [2] if you are coming from a 48h non-stop no-sleep marathon). Second, someone posted about your random number generator, and you ignored it. But this is a minor problem, as all things are in Javascript. Third, you use Javascript. But, wait, I need to sleep. Please stop spamming an insecure-by-design product. I think it's a bit short-sighted to criticize encryption because of the programming language it's implemented in. JavaScript encryption doesn't have problems because of the programming language, but because of the APIs, environment and mechanisms surrounding the language. I've investigated many of the challenges surrounding proper implementation in those contexts, and have written a blog post to this effect. I would be interested in hearing some feedback! http://log.nadim.cc/?p=33 NK Last thing: People, please, use PGP instead of these circus things. [1] http://www.matasano.com/articles/javascript-cryptography/ [2] https://www.google.it/search?q=why%20is%20bad%20crypto%20javascript -- Liberationtech is a public list whose 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. -- Liberationtech is a public list whose 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.
Re: [liberationtech] Piratebrowser?
IMHO, it seems like a needless duplication of effort.
Tor alone is pretty good at circumvention. It has a couple flaws - it's
slower than a simple VPN, and obtaining bridges can be a bit of a
challenge if you're in a regime that's actively blocking access.
But the Pirate Browser doesn't seem to attempt to solve either of these
issues.
-Greg
On 8/11/13 10:14 AM, Ben Laurie wrote:
On 11 August 2013 03:39, Griffin Boyce griffinbo...@gmail.com wrote:
On 08/11/2013 12:51 AM, Tom Ritter wrote:
Some other random stats for the curious.
Tor v0.2.3.25 (git-17c24b3118224d65)
Vidalia 0.2.21 (QT 4.8.1)
# Configured for speed
ExcludeSingleHopRelays 0
EnforceDistinctSubnets 0
AllowSingleHopCircuits 1
# Exclude countries that might have blocks
ExcludeExitNodes {dk},{ie},{gb},{nl},{be},{it},{cn},{ir},{fi},{no}
#Selected user prefs
user_pref(browser.startup.homepage, http://6kkgg7nth3sbuuwd.onion;);
user_pref(general.useragent.override, PB0.6b Mozilla/5.0 (Windows
NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0);
-tom
It's pretty surprising that the Pirate Bay went this route. I have a
hard time believing that it isn't just some kind of publicity stunt.
They also released the browser as an exe when the site doesn't use
SSL/https. Which is kind of an interesting choice, considering their
stated desire to target Iran (of all places).
About a year ago, I wrote a quick Chrome plugin for torrenters to
bypass the common DNS blocks on TPB and similar sites.
In the UK I thought blocks were IP-based, hence this piece of
amusement: https://www.openrightsgroup.org/blog/2013/sky-torrentfreak-blocking.
Users from the
UK and the Netherlands (both places where they have a large userbase)
had recently been blocked from accessing TPB. I have a hard time
believing that Iran represents more than a negligible number of possible
Pirate Bay users. It could be a scheme to get more of their users to
use privacy-protecting techniques, but a guide might have more of an
effect there. If their only goal is to bypass censorship of this one
site, there are easier methods that are just as effective. The plugin I
made was trivial to write and it wouldn't be difficult for the pirate
bay to do something similar (quite a few plugins exist already, and it
wouldn't be hard to just pick one to promote).
~Griffin
--
Cypherpunks write code not flame wars. --Jurre van Bergen
#Foucault / PGP: 0xAE792C97 / OTR: sa...@jabber.ccc.de
My posts, while frequently amusing, are not representative of the thoughts of
my employer.
--
Liberationtech is a public list whose 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.
--
Liberationtech is a public list whose 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.
Re: [liberationtech] In defense of client-side encryption (Guido Witmond)
In your message, you wrote: 1. I have to *run* it to get the hash of the application from the help page. That is already a leap of faith to run unverified code. Good point. A counterfeit copy of the page might lead to a different server, and the help page thus obtained would display a different code which, of course, would check out all right. Both the active code and the help page come via TLS, but maybe this is not enough. In any case, this would be just about the same risk that anyone incurs when loading any page via https, so almost every crypto app out there would have the same security flaw.This is why I added the video verification, anyway. It's a lot harder to fake a video. 2. I have to verify the hash code with a spoken message in a youtube video. The message is spoken by someone I've never met, so how do I verify that it is you who's saying it and not an actor hired by a spooky agency? Or just dubbed with a new audio score. Hollowood can do that without a blink. I'm not Justin Bieber (thank God) and there's nothing I can do about that. But maybe someone in this forum knows a privacy-conscious celebrity who could be persuaded to do the reading. It should be possible to find one. Actors are into all kinds of causes these days... Concerning faking a video. Sure, it can be done too, but mere dubbing won't work because you have to sync the lips. Chopping the video into little pieces and reassembling it to make a different code won't be easy to pull off, either, especially with background music to serve as a sort of tamper-evident paper. I'd like to see more discussion on this. 3. How can I validate that the youtube url is correct? They are all gibberish to me. Again could be a fake by some adversary. This mail was not encrypted and validated. Well, the URL leads to me (or a famous actor, in the future ;-) reading the hash for a particular version. If the guy in the video says something else, you know you don't have the right video. I think videos have great potential for authentication, since they are so much richer, and harder to fake, than a mere piece of text. There?s no legal action that can shut down PassLok because it consist of pure code, and pure code is speech, protected from government interference under the 1^st amendment to the US Constitution. Theoretically you are correct. In practice, we've seen the value of your US constitution... Lavabit and Silent Mail have shut down due to legal challenges rooted in US law. The same laws cannot be used to force a website (or many websites, for there should be mirrors) to stop delivering a certain document, unless it is pornographic or hate speech, because of the 1st Amendment. So far, free speech has been quite successfully protected in the USA. Thanks! -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL13lok=WsH3zTgZn8V3hnIqjdbfPus+5YF5n+LBRPuH9USMMp8izPv+hsLoZKv+jaCFMapJFfiA11Q9yJU1K1Wo0TbjXK/=PL13lok get the PassLok privacy app at: http://passlok.com -- Liberationtech is a public list whose 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.
Re: [liberationtech] In defense of client-side encryption
Thanks for the warning. I'll be more careful in the future ;-) BTW, I'm having trouble replying to postings in a way that will show in the log. I don't know what I'm doing wrong. Is there a help page detailing best practices for the mail list? -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL13lok=WsH3zTgZn8V3hnIqjdbfPus+5YF5n+LBRPuH9USMMp8izPv+hsLoZKv+jaCFMapJFfiA11Q9yJU1K1Wo0TbjXK/=PL13lok get the PassLok privacy app at: http://passlok.com -- Liberationtech is a public list whose 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.
Re: [liberationtech] In defense of client-side encryption
Thanks for the warning. I'll be more careful in the future ;-) BTW, I'm having trouble replying to postings in a way that will show in the log. I don't know what I'm doing wrong. Is there a help page detailing best practices for the mail list? -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL13lok=WsH3zTgZn8V3hnIqjdbfPus+5YF5n+LBRPuH9USMMp8izPv+hsLoZKv+jaCFMapJFfiA11Q9yJU1K1Wo0TbjXK/=PL13lok get the PassLok privacy app at: http://passlok.com -- Liberationtech is a public list whose 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.
Re: [liberationtech] In defense of client-side encryption
@danimoth, sorry if this is duplicate. I'm re-sending this a different way so it can be seen by all. Thanks for the quick feedback. In there, you say, First, it is in Javascript. Who needs cryptography, SHOULD NOT use javascript. Google can help you ([1] for example, [2] if you are coming from a 48h non-stop no-sleep marathon). I still have to read through the references you supply, but I can already see a misconception. They refer to the dangers of carrying out cryptography with javascript-containing dynamic pages. My previous posting referred to _perfectly static_ pages, which are supposed to be always the same coming from the server, not modified by the browser in any way, and which, in fact, you can save and store somewhere safe and never again have to get from the server. I believe the intrinsic security of this kind of javascript code is no different from that of compiled code, which also should be checked for tampering, so long as it uses standard functions that are not likely to be modified in browser updates. Sorry about the confusion. Second, someone posted about your random number generator, and you ignored it. But this is a minor problem, as all things are in Javascript. I did reply, and the updated PassLok includes improvements based on that great piece of feedback. But perhaps it hasn't shown in the mail list because I replied directly to the poster. I'm still trying to figure out how to reply to a post on the daily digest. The criticism is actually about how SJCL handles entropy collection. I hope the SJCL developers will read it and respond to it. -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL13lok=WsH3zTgZn8V3hnIqjdbfPus+5YF5n+LBRPuH9USMMp8izPv+hsLoZKv+jaCFMapJFfiA11Q9yJU1K1Wo0TbjXK/=PL13lok get the PassLok privacy app at: http://passlok.com -- Liberationtech is a public list whose 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.
Re: [liberationtech] In defense of client-side encryption
@Edulix (hombre, un paisano ;-) I believe we need is an standard way to do client side encryption in the web. We need secure end-to-end communications in the web, so that we don't need to be trust and dependent on the html/css/javascript given by any server. We have a server in the middle security problem. This is different from a man in the middle, where there's *potentially* someone spying in the middle: in the web, by design, there's a server in the middle. We should not trust this server just because it's part of the design. I believe the big problem that we are not addressing is precisely this. The server is a big liability, because a server can always be hacked or subpoenaed. We'd get better security from strictly client-side encryption/decryption. This might seem like the holy grail, but it's not something unachievable (but it's surely very difficult to solve in a nice general way), here I talk about this problem: http://edulix.wordpress.com/2012/01/08/the-server-in-the-middle-problem-and-solution/ . BTW, as a funny note, I gave a lighting talk about the server in the middle in Madrid Google's offices in 2012, showing in the slides google as being that server. People assisting to the talk loved the talk, but I think the google people didn't, as they didn't call me again next year for the same event (which was remote Google I/O). It's servers that are getting shut down. If we move encryption to the client, then they can't shut them down. They might try to inject malicious code in a static page as it loads (not easier than injecting it into anything else, if it comes via SSL), but if the code is transparent, it can be detected. That's all I'm saying. Kind regards, too. -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL13lok=WsH3zTgZn8V3hnIqjdbfPus+5YF5n+LBRPuH9USMMp8izPv+hsLoZKv+jaCFMapJFfiA11Q9yJU1K1Wo0TbjXK/=PL13lok get the PassLok privacy app at: http://passlok.com -- Liberationtech is a public list whose 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.
Re: [liberationtech] Tormail in trouble. Experts at Black Hat recommend Elliptic Curves: this is what PassLok 1.3 is based on.
Hi Greg,
It seems my reply didn't stick, so I'm replying again. Sorry about
that. I'm still trying to figure out hos this mail list works.
On Tue, Aug 6, 2013 at 3:20 PM, Francisco Ruiz ruiz at iit.edu
https://mailman.stanford.edu/mailman/listinfo/liberationtech wrote:
* Hi folks, Thank you very much for your great feedback on the previous
version. The** next version is now up at http://passlok.com, which redirects
to** https://passlok.site44.com** This may come in handy now that there are
problems with Tor, since PassLok** allows you to go to any computer to do
encrypted mail, because there is** nothing to install. This is what PassLok
was designed to do. The other unforeseen endorsement came from the
recent Black Hat conference.** Researchers Alex Stamos, Tom Ritter, Thomas
Ptacek, and Javed Samuel** encouraged everyone to base their public key
cryptosystems on elliptic** curves rather than RSA. Here's a link on this:**
http://arstechnica.com/security/2013/08/crytpo-experts-issue-a-call-to-arms-to-avert-the-cryptopocalypse/*
You replied:
Wait. You are using vague popular press FUD about RSA to promote a
website hosted JS encryption tool? Really?
Your code generates random values like this:
sjcl.random.addEntropy([a.x || a.clientX || a.offsetX || 0, a.y ||
a.clientY || a.offsetY || 0], 2, mouse)
sjcl.random.addEntropy((new Date).valueOf(), 2, loadtime)
try {
var s = new Uint32Array(32);
crypto.getRandomValues(s);
sjcl.random.addEntropy(s, 1024, crypto['getRandomValues'])
} catch (t) {}
Meaning that if it's used someplace where crypto.getRandomValues()
doesn't exist, it has only pure snake-oil-extract randomness.
Really
This is what the SJCL code does. I didn't write this. I believe the
getRandomValues call is in addition to all the entropy collection the
SJCL is doing elsewhere. But you've got a worthwhile point. I'm adding
instructions to my code so entropy collection gets done a lot more
often, every time the user clicks or releases a button.
If the randomness is poor, the nonce used in ECDSA will be predictable
and the private key will be recoverable.
Absolutely. It is essential that the RNG be flawless.
This isn't to say I've audited any of it, I just grepped for a couple
likely mistakes. Part of the JS code has been whitespace compressed, I
consider it unauditable.
Thanks for bringing this up. This was because the qr.js code I added
was minimized. I've corrected that. Hopefully you can read the code it
now.
* up to a whopping** 200,000 iterations for lousy keys. Since keys made in
version 1.2 are no** longer compatible, this prompts upping the version to
1.3.*
So, not implemented in slow-as-dirt JS 200,000 iterations should take
a random desktop cpu about 100ms or so. This is hardly wopping. It's
not far from the minimum I'd start with, for all keys not just weak
ones. Generally user provided keys are a security disaster and should
be avoided wherever it's possible, strengthening or no. Humans are
horrific entropy sources and really can't self assess how bad they
are.
The web app has to be able to run on a smartphone. 200k iterations require
more than a minute in an iPhone 4S. Totally unacceptable, which is why I
think this might entice users to select better passwords. The elliptic
curve multiplication needed to do anything with a private key is pretty
slow by itself, and it's always there. In that same iPhone, it is roughly
equivalent to 10k iterations, which take three seconds. Unfortunately,
using different iteration numbers depending on the platform would break key
compatibility.
Regards,
--
Francisco Ruiz
Associate Professor
MMAE department
Illinois Institute of Technology
PL13lok=WsH3zTgZn8V3hnIqjdbfPus+5YF5n+LBRPuH9USMMp8izPv+hsLoZKv+jaCFMapJFfiA11Q9yJU1K1Wo0TbjXK/=PL13lok
get the PassLok privacy app at: http://passlok.com
--
Liberationtech is a public list whose 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.
