Re: [liberationtech] A modest proposal for protecting the work (and freedom) of activists.
On 25 January 2014 23:46, coderman wrote: > On Sat, Jan 25, 2014 at 3:23 PM, Ben Laurie wrote: >> [low latency vs. anonymity] >> >> Actually, it seems it is a natural law. >> >> Hope is not a strategy. > > > natural in that they interfere with each other? (like multi-path fade, > apply science for great justice! (e.g. more radios, better encoding > turns multi-path from detriment to signal positive)) > > if high bandwidth[0] is half way there, Clearly the measure of interest is bandwidth*latency, so high bandwidth is effectively high latency. > and so many techniques[1] yet > unexplored, why the pessimism? Lower latency == smaller anonymity set, no matter what you do. > > it is certainly taking too long to get here, of course. *grin* > > > best regards, > > > > 0. "Towards Efficient Traffic-analysis Resistant Anonymity Networks" > http://research.microsoft.com/apps/pubs/?id=199302 > """ > In this paper, we present the design, implementation, and evaluation > of Aqua, a high bandwidth anonymity system that resists traffic > analysis. We focus on providing strong anonymity for BitTorrent, and > evaluate the performance of Aqua using traces from hundreds of > thousands of actual Bit-Torrent users. We show that Aqua achieves > latency low enough for efficient bulk TCP flows, bandwidth sufficient > to carry BitTorrent traffic with reasonable efficiency, and resistance > to traffic analysis within anonymity sets of hundreds of clients. We > conclude that Aqua represents an interesting new point in the space of > anonymity network designs. > """ > > > 1. various datagram based Tor-like protocols with traffic analysis > protections afforded new multi-path, out-of-order, stochastic shaped > bandwidth in non-TCP, non-stream based variants. plenty of fertile > research ground across: > - IPsec telescopes > - DTLS transports for Tor > - userspace SCTP multi-path end-to-exit and end-to-hiddensvc over > datagram Tor, I2P, etc. > - userspace IPv6 with ORCHID based node identifier overlay as endpoint > and route addressing to existing applications. > - new variations and combinations of optimized dynamic link padding > - decentralized low bandwidth directory/path building low overhead techniques > - stochastic fair queuing and reordering with traffic source > classification into priority queues for even lower path latency, RTT. > and many more, not on top of mind... [obligatory link to anon bib here] > -- > 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. -- 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.
Re: [liberationtech] A modest proposal for protecting the work (and freedom) of activists.
On 21 January 2014 00:23, Patrick Schleizer wrote: > Adam Midvidy: >> >> On Jan 20, 2014, at 11:07 AM, Katy Pearce >> wrote: >> >>> - security does not slow down the internet or the computing power >>> >> >> Unfortunately, low-latency access and anonymity are two opposing >> goals. > > This isn't a natural law, though. It only requires a bunch of motivated > people care about and working on that. Actually, it seems it is a natural law. Hope is not a strategy. -- 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.
Re: [liberationtech] dark mail alliance
On 1 November 2013 22:47, Tony Arcieri wrote: > On Fri, Nov 1, 2013 at 2:00 PM, Maxim Kammerer wrote: >> >> But since you are asking, safe human-readable addresses are not possible >> as a concept, unless >> you are willing to trust a third party. > > > Aaron Swartz wrote a great blog post about "Squaring Zooko's Triangle", an > idea which has more or less been implemented in terms of Namecoin: > > http://www.aaronsw.com/weblog/squarezooko > > tl;dr: a Bitcoin-like global append-only log can enable the secure mapping > of human-meaningful names to cryptographic keys I'm sorry to bang on about it, but, if you want an append-only log, there are ways to implement it that are both far more efficient than Bitcoin _and_ are truly append-only (Bitcoin is only kinda append-only, until someone comes along with a longer, different "append-only" log). For example, the one we use for Certificate Transparency. But really, what you want for mappings of names to keys is a verifiable map, not an append-only log. An append-only log requires everyone to download the whole log. A verifiable map does not. We describe two ways to make verifiable maps here: http://www.links.org/files/RevocationTransparency.pdf (described in the context of revocation, but it is obvious how you'd extend it to any mapping). I was hoping to get CT finished before I started to figure out how to implement verifiable maps, but I guess I should perhaps get on with it. -- 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.
Re: [liberationtech] Riseup registration process a bit odd...
On 29 October 2013 17:49, andrew cooke wrote: > people are saying that the site name is visible, but that's not strictly > correct. > > a server can have many names. with https, someone can see which server you > connected to, but they don't see which name you used to do so. Yes they do: its included in the Server Name Indication extension. -- 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.
Re: [liberationtech] ChatSecure (Gibberbot!) v12 for Android is out
On 24 October 2013 08:01, Nathan of Guardian wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > "The Guardian Project’s award-winning open-source app “Gibberbot” for > Android, has been rebranded to “ChatSecure” for its version 12 release, > unifying the branding with the iPhone and iPad apps, while offering > major updates in security from the device through the network." Can you explain why it needs these permissions: use accounts on the device find accounts on the device view configured accounts add or remove accounts ? -- 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.
Re: [liberationtech] what to install on a secure communication device
On 31 August 2013 12:43, Tom O wrote: > Is irssi-otr working yet? irssi-otr has mostly worked for ages. > You could add that. Mixmaster/mixminion? > > > On Saturday, August 31, 2013, Eugen Leitl wrote: > >> >> I'm looking to build a list for reasonably secure (no snake oil) >> ways to communicate (search, store, etc.). My ad hoc list so far is: >> >> Pidgin/OTR >> cables >> Jitsi >> Tor >> YaCy >> RetroShare >> TorChat >> Tahoe LAFS >> GnuNet >> >> No doubt I'm missing a lot. Any further suggestions? >> -- >> 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 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] Fwd: [riseup] Space for dissent
So where are these "radically new services" documented? On 21 August 2013 19:18, Sean Alexandre wrote: > - Forwarded message from newslet...@lists.riseup.net - > > Space for dissent > > > It is a mistake to frame the recent US and European massive surveillance > revelations in terms of the privacy of individuals. What is at stake is not > privacy at all, but the power of the state over its citizenry. > > What surveillance really is, at its root, is a highly effective form of > social > control. The knowledge of always being watched changes our behavior and > stifles > dissent. The inability to associate secretly means there is no longer any > possibility for free association. The inability to whisper means there is > no > longer any speech that is truly free of coercion, real or implied. Most > profoundly, pervasive surveillance threatens to eliminate the most vital > element of both democracy and social movements: the mental space for > people to > form dissenting and unpopular views. > > Many commentators, and Edward Snowden himself, have noted that these > surveillance programs represent an existential threat to democracy. This > understates the problem. The universal surveillance programs in place now > are > not simply a potential threat, they are certain to destroy democracy if > left > unchecked. Democracy, even the shadow of democracy we currently practice, > rests > on the bedrock foundation of free association, free speech, and dissent. > The > consequence of the coercive power of surveillance is to subvert this > foundation > and undermine everything democracy rests on. > > Within social movements, there is a temptation to say that nothing is > really > different. After all, governments have always targeted activist groups with > surveillance and disruption, especially the successful ones. > > But this new surveillance is different. What the US government and European > allies have built is an infrastructure for perfect social control. By > automating the process of surveillance, they have created the ability to > effortlessly peer into the lives of everyone, all the time, and thus create > a system with unprecedented potential for controlling how we behave and > think. > > True, this infrastructure is not currently used in this way, but it is > a technical tool-kit that can easily be used for totalitarian ends. > > Those who imagine a government can be trusted to police itself when given > the > ominous power of precise insight into the inner workings of everyday life > are > betting the future on the ability of a secretive government to show proper > self-restraint in the use of their ever-expanding power. If history has > shown > us anything, it is that the powerful will always use their full power > unless > they are forced to stop. > > So, how exactly are we planning on stopping them? We support people working > through the legal system or applying political pressure, but we feel our > best > hope of stopping the technology of surveillance is the technology of > encryption. Why? Because the forces that have created this brave new world > are > unlikely to be uprooted before it is too late to halt the advance of > surveillance. > > Unfortunately, most existing encryption technology is counterproductive. > Many > people are pushing technology that is proprietary, relies on a central > authority, or is hopelessly difficult for the common user. The only > technology > that has a chance to resist the rise of surveillance will be open source, > federated, and incredibly easy to use. In the long run, decentralized > peer-to-peer tools might meet this criteria, but for the foreseeable future > these tools will not have the features or usability that people have grown > accustomed to. > > In the coming months, the Riseup birds plan to begin rolling out a series > of > radically new services, starting with encrypted internet, encrypted email, > and > encrypted chat. These services will be based on 100% open source and open > protocols, will be easy to use, and will protect your data from everyone, > even > Riseup. This is a massive undertaking, made in concert over the last year > with > several other organizations, and will only work with your support. We need > programmers, particularly those experienced in Python, C, Ruby, and Android > development, and sysadmins interested in starting their own secure service > providers. > > We also need money. Donations from our amazing Riseup users keep us > running on > our current infrastructure. But in order to be able to graduate to a new > generation of truly secure and easy to use communication technology, we are > going to need a lot more money than our users are able to donate. If you > have > deep pockets and an interest in building this new generation of > communication, > then we need to hear from you. If you have friends or family who care > about the > future of democracy and who have deep pockets, we need to h
Re: [liberationtech] verifying SSL certs (was Re: In defense of client-side encryption)
On 14 August 2013 10:46, Guido Witmond wrote: > On 08/14/13 15:18, Ben Laurie wrote: > > On 14 August 2013 08:54, Guido Witmond > <mailto:gu...@witmond.nl>> wrote: > > > > On 08/13/13 19:42, Andy Isaacson wrote: > > > On Mon, Aug 12, 2013 at 11:10:39AM +0200, Guido Witmond wrote: > > >> There is another problem. You rely on HTTPS. Here is the 64000 > > >> dollar question: > > >> > > >> Q._"What is the CA-certificate for your banks' website?"_ > > >>> > > [snip] > > > I too have given up on expecting security from the global CA's. > That's > > why I want to see DNSSEC succeed. > > > > > > DNSSEC merely transfers the problem to registries and registrars, who > > are no more reliable than CAs. You need to solve the problem of having > > to trust third parties before DNSSEC will work (which is the same > > problem you need to solve for CAs), > > Yes, there is trust involved, but there is a difference. > > With CA's anyone can sign a certificate for any site. It's a race to the > bottom with no winners. Not even the CA's as they can't differentiate > between themselves. The consequence is that no one trusts any of them. > And who likes to do business with a party he doesn't trust but needs > anyway? > > With DNSSEC, I have the choice of registrar. If there is a bad apple, I > choose another who I find better worth my money. > > > > And, sorry to bang on about it, but > > the answer is Certificate Transparency. BTW, my team is about to start > > looking at DNSSEC Transparency, too. > > Don't bang to hard: DNSSEC and CT solve the same problem. > This is not correct. > > The problem is that there is no registry that specifies which of the > Global Certificate authorities is the one you should trust to validate a > server-certificate. The mess we have right now is that each of the > Global CA's can sign a server certificate. Hence my 64000 dollar question. > > Both DNSSEC and CT solve the problem. Albeit in different ways with > different pros and cons. > > With DNSSEC and DANE, the site operator specifies *a priori* which CA he > uses to sign the server certificates. It can be a self signed certificate. > > With CT, you register which CA has signed a certificate for a web site > *after the fact*. > Not really. The registration occurs before the cert can be used. > > We need them both! To keep the CA's and registrars honest. I really > appreciate your work on CT. > CT does not keep registrars honest. This is why you need DNSSEC transparency. > > 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. > -- 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] Trsst: An Open and Secure Alternative to Twitter
On 19 August 2013 05:30, Michael Rogers wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 19/08/13 07:33, Ben Laurie wrote: > > Merkle trees (a la Certificate Transparency) are more efficient > > than chains. Also, if you did that, you could have a global log, > > and so prove against censorship of an entire blog. > > I wonder if Twitter would be interested in publishing something like > this. Then if they were forced to censor a tweet in one jurisdiction > but not another, a third party could reassemble the uncensored stream > of tweets and use Twitter's signed hash tree to prove its authenticity. > Nice idea. If anyone has an appropriate contact I'd be happy to help :-) > > Cheers, > Michael > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQEcBAEBAgAGBQJSEeW1AAoJEBEET9GfxSfM/TQH/juaDphcbowwxmL75Z3ApRYM > facSkfTQNE2SaRg+zSDOPxzir+YNbKKH5rK7yKDixF/nXf/QLkuwq0P/YEnwBCJl > 5xYUd3CyNXxHj8x/7/dq7Idm1b6/rWmf/PtEDULIBzIKN4C4yyIoFpW29MDoy7gI > 86NO9ksKBWn1hk4+AXfzUpCnakUYU5b6rA/S57qPlZ7DW8MzoVlNQVGKZy+JDVrN > TG/JsLl9nhunLl5r/32edGWxnni4sDYfA2JK3nsqnAmW4e0v9uNhUDkNu6KuxLFg > UhjT9XaoEiGpQFtjah8QWBKmbIPZstxwZ4r+KbQsdtjK152wzPcW9T1cSs1cWsY= > =wKv6 > -END PGP SIGNATURE- > -- 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] Trsst: An Open and Secure Alternative to Twitter
On 18 August 2013 17:49, Michael Powers wrote: > Yep, the bitcoin stuff seems to be a distraction for whatever reason. > > The only connection with bitcoin is that each blog gets a keypair and the > public key is also the guid. Now if the keypair generation happens to > adheres to bitcoin's scheme, then your blog id happens to be a payment > address too, which could be useful for micropayment content monetization. > > I've had some people ask me if this is going to make them wanted by the > feds (or the Fed for that matter) so I'm considering just taking the whole > thing out. But there it is. > > The "blog chain" is merely bitcoin-inspired. Each entry contains the > message digest of the previous entry, hence the "blog chain" ala block > chain, so you can prove against censored messages or tampering. > > All we're doing is extending RSS to support self-signed and/or > self-encrypted entries. Your public posts remain public and > search-indexable but the private posts you encrypt with the recipient's > public key (aka their blog id and -ahem- payment address) so that it shows > up in your rss feed as encoded text. Existing RSS reader can read your > feed; you can follow any existing RSS feed. > > (I've been reading the client-side/javscript encryption stuff here with > interest.) > > White paper is here: http://trsst.com > > If it's not clear by now, I'm the project founder. > > Happy to answer any other questions and generally would love feedback. > Merkle trees (a la Certificate Transparency) are more efficient than chains. Also, if you did that, you could have a global log, and so prove against censorship of an entire blog. > Thanks. > > - > > > I came across this project in kickstarter. Subscribers of this list may > > find it interesting. (Btw I am not associated with them) > > > They lost me at bitcoin. Why??? > > > -- > > > > *Welcome to Trsst: An Open and Secure Alternative to Twitter* > > > > Post your thoughts, share links, and follow other interesting people or > > web sites, using the web or your mobile or any software of your choice. > > > >- All of your private posts to individuals or friends and family are > >securely encrypted so that even your hosting provider - or government > - > >can't unlock them. > >- All of your public posts are digitally signed so you can prove that > >no one - and no government - modified or censored your writings. > >- You control your identity and your posts and can move them to > >another site or hosting provider at any time. > > > > Think of Trsst as an RSS reader (and writer) that works like Twitter but > > built for the open web. The public stuff stays public and > > search-indexable, and the private stuff is encrypted and secured. Only > you > > will hold your keys, so your hosting provider can't sell you out. > > > > > > > http://www.kickstarter.com/projects/1904431672/trsst-a-distributed-secure-blog-platform-for-the-o/description > > > > -- > 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] Trsst: An Open and Secure Alternative to Twitter
On 18 August 2013 04:47, Edwin Chu wrote: > I came across this project in kickstarter. Subscribers of this list may > find it interesting. (Btw I am not associated with them) > They lost me at bitcoin. Why??? > -- > > *Welcome to Trsst: An Open and Secure Alternative to Twitter* > > Post your thoughts, share links, and follow other interesting people or > web sites, using the web or your mobile or any software of your choice. > >- All of your private posts to individuals or friends and family are >securely encrypted so that even your hosting provider - or government - >can't unlock them. >- All of your public posts are digitally signed so you can prove that >no one - and no government - modified or censored your writings. >- You control your identity and your posts and can move them to >another site or hosting provider at any time. > > Think of Trsst as an RSS reader (and writer) that works like Twitter but > built for the open web. The public stuff stays public and > search-indexable, and the private stuff is encrypted and secured. Only you > will hold your keys, so your hosting provider can't sell you out. > > > http://www.kickstarter.com/projects/1904431672/trsst-a-distributed-secure-blog-platform-for-the-o/description > > -- > 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] Secure alternatives to Dropbox?
Why on Earth did you quote an entire digest along with your question? -- 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] verifying SSL certs (was Re: In defense of client-side encryption (Guido Witmond)
On 14 August 2013 08:54, Guido Witmond wrote: > On 08/13/13 19:42, Andy Isaacson wrote: > > On Mon, Aug 12, 2013 at 11:10:39AM +0200, Guido Witmond wrote: > >> There is another problem. You rely on HTTPS. Here is the 64000 > >> dollar question: > >> > >> Q._"What is the CA-certificate for your banks' website?"_ > >> > >> I ask that question to anyone who claims to be security conscious. > >> No one has given me positive answer so far. Not even a wrong > >> answer. Only that people don't know. > >> > >> So I take it for granted that people won't verify anything, ever. > > > > FWIW, I did run my browser in "trust on first use" (TOFU) mode -- I > > deleted all the CA certs and manually added exceptions for each > > site, as I encountered the certificate warnings -- for several years. > > I've given up on that for modern websites because > > > > To be honest, I wouldn't win my quiz either. Could use the money, though > :-) > > I deleted the certificate and relied on CMU's Perspectives to tell me > what certificate they've seen for each name. > > It worked quite well for most sites. But big ones, like Google use a > different certificate for each endpoint. And Perspectives registers the > server-certificates it detects when it connects to the servers, not the > CA that signed it. > > At one point in time, my bank made it easy to win the quiz. They wrote > the name of the CA on their home page. But they removed it as it offers > no benefit against scammers (who would write their CA in that place) and > probably confused a lot of customers. > > Perhaps some got even scared about that and found it less safe than > without it. > > I to have given up on expecting security from the global CA's. That's > why I want to see DNSSEC succeed. > DNSSEC merely transfers the problem to registries and registrars, who are no more reliable than CAs. You need to solve the problem of having to trust third parties before DNSSEC will work (which is the same problem you need to solve for CAs), And, sorry to bang on about it, but the answer is Certificate Transparency. BTW, my team is about to start looking at DNSSEC Transparency, too. > > With DNSSEC, the bank specifies their CA certificate and my browser can > validate it. To give an error when that doesn't match. > > > 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. > -- 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 12 August 2013 06:14, Ximin Luo wrote: > On 11/08/13 22:28, Nadim Kobeissi wrote: >> >> On 2013-08-11, at 10:36 PM, 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 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 >> > > How is it possible to defend against timing attacks in JS? Any language > theoretically can be complied into anything, but the JS runtime does not give > you much control in what the CPU actually executes. The webcrypto WG you > linked to looks interesting, if browsers will provide a native crypto API to > JS, preinstalled (at least the mathy bits that you need direct execution > control over) as opposed to loaded on-demand by a remote server. Did you ever > think about having the cryptocat browser extension using a lower-level > language? Firefox at least can run binary extensions; I don't know about > Chrome. It is possible to defend against timing attacks by writing inherently constant time code. For example: https://github.com/openssl/openssl/commit/a693ead6dc75455f7f5bbbd631b3a0e7ee457965 is full of such code. > > Also I'll note that "investigate many" is not sufficient to have security > confidence; you have to "investigate all" - i.e. enumerate all parts that can > be compromised, and argue convincingly that you haven't missed anything. This > involves knowing the JS spec and browser implementations very very well. > >> 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 >>> > > > -- > 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. -- 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 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] From Snowden's email provider. NSL???
On 10 August 2013 16:43, Michael Rogers wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 09/08/13 17:43, Reed Black wrote: >> CryptoCat is served up by the Chrome app store. Do you have >> control over what binary gets distributed to who? Does any assurace >> exist beyond the app store's own signing validation? >> >> I thought this was like webmasters and third-party script >> inclusions. They will be blind if Google or DoubleClick are >> compelled to selectively swap out the scripts they serve to >> millions of third-party sites. > > If we assume that app stores aren't going away any time soon, we need > to address this problem: How can a user who downloads an app from an > app store be satisfied that it was built from published source code? > > We might also think about how to solve the problem for apps downloaded > through browsers. > > Verifiable builds are necessary but not sufficient here - they allow > an expert auditor to tell whether the binary she downloaded was built > from the published source, but an attacker might target the binaries > downloaded by certain other users without alerting the auditor. So we > also need a way for a non-expert user to tell whether the binary she > downloaded matches the one that was audited. > > PGP signatures and hashes aren't currently usable by non-experts, and > signatures or hashes published through the same channel as the binary > can be tampered with in the same way as the binary. > > Something along the lines of Certificate Transparency might be useful > here: a public log of software names, versions, and hashes, which a > browser or other download tool can use to verify downloaded binaries > without any manual steps needing to be taken by the user. Software > publishers would be responsible for adding entries to the log for > their own software and monitoring the log for entries added by anyone > else. FWIW, the Certificate Transparency code already has (primitive) support for Binary Transparency: https://code.google.com/p/certificate-transparency/source/browse/src/server/blob-server.cc. Patches, as always, welcome. > > Cheers, > Michael > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQEcBAEBAgAGBQJSBl+QAAoJEBEET9GfxSfMlVAIAJ/JEwbbZBdihiuUT6PEas9v > Bs/eOnr/+/oTvjVJc/OJvcSHXWr8ne97N3kGzBrQsS6HdiDoxZdUMC/9S+WGLQuG > boMD1MJH2qpPQzA7yG0ZDKWUodg+IvHZosC50ahC+su6zZ176Ic/8v4zzDDxnzF5 > zLqtY/jhZSrvmdaWixx4yznmrWbOXo1zxb+ulSDZWZ4TIHZKC+890d4CVGDzFNjY > Yzyz0E3BRX7Ctkbt2dW/EqhBPKsG0FtMzwCsFMa6xPIUp5Ykf0YpQ0WF4n/sTJaO > 8bY3HyAtxBAma/gZccDLP1OEkjPdaf27cxJNbcSoAYeKy4cqCOMWWXL/gLbuZqo= > =QkIa > -END PGP SIGNATURE- > -- > 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 or changing your settings at > https://mailman.stanford.edu/mailman/listinfo/liberationtech -- 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 or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] PassLok updated based on feedback from LiberationTech
On 30 July 2013 23:09, Francisco Ruiz wrote: > 3. Some users are confused by having both symmetric and asymmetric > encryption available, so they end up encrypting messages with their private > keys, which no one else has. Would it be better to hide or eliminate the > symmetric encryption mode, so this doesn't happen? Can you offer a better > solution? Refuse to encrypt with private keys? How can this be a problem? -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Fwd: [jitsi-users] New XMPP Server
On 29 July 2013 16:04, Bernard Tyers wrote: > Hi Ben, > > > Ben Laurie wrote: >>On 28 July 2013 12:44, Bernard Tyers - ei8fdb >>wrote: >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> For those interested, these two forwarded mails mention two separate >>"secure" Jabber servers with "no-logging". I cannot vouch for the >>validity of them. >>> >>> IMO, any alternative to running the now closed (as in no non-GTalk >>users can talk directly) Google Talk service. >> >>There's also OTR, of course: http://www.cypherpunks.ca/otr/. Doesn't >>hide who's talking to who, but does hide >content. > > Yes definitely agree. I use it and suggest it to everyone I know. > > The point here was running a self-hosted XMPP server which allows you to > communicate with anyone running XMPP which allows users on different servers > to communicate, unlike GTalk or Facebook. Doesn't help if the other server logs, tho, right? > > Sent from my tiny electronic gadget. Please excuse my brevity and (probable) > spelling mistakes. -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Fwd: [jitsi-users] New XMPP Server
On 28 July 2013 12:44, Bernard Tyers - ei8fdb wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > For those interested, these two forwarded mails mention two separate "secure" > Jabber servers with "no-logging". I cannot vouch for the validity of them. > > IMO, any alternative to running the now closed (as in no non-GTalk users can > talk directly) Google Talk service. There's also OTR, of course: http://www.cypherpunks.ca/otr/. Doesn't hide who's talking to who, but does hide content. > > regards, > Bernard > > Begin forwarded message: > >> From: John Perry >> Date: 28 July 2013 09:21:23 GMT+01:00 >> To: Jitsi Users >> Subject: Re: [jitsi-users] New XMPP Server >> Reply-To: Jitsi Users >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 7/27/2013 5:44 PM, Anthony Papillion wrote: >>> I know that Emil has stated that the jit.si server is an >>> experimental one and, with the developed focused on making the >>> Jisti software even more kick butt, it's probably a bit hard for >>> them to constantly troubleshoot server and config problems with the >>> service. >>> >>> So I've set up a similar service at http://patts.us and invite >>> anyone interested to use it. We support voice, video, and IM and >>> run a Jingle node. We are also completely unlogged (even the web >>> server). >>> >>> Just putting it out there to anyone who's interested. Not trying >>> to poach users from the jit.si service. Hopefully, this will give >>> Emil and the team a little breathing room. >>> >>> Best Regards, Anthony Papilloon >> >> I don't want to steal any of Anthony's thunder but I also have a >> server located at xmpp://chat.jpunix.net that has no logging and >> pretty much does what Anthony's does and is open to anyone that want's >> to use it. >> >> - -- >> John Perry >> >> > > == > > Begin forwarded message: > >> From: Anthony Papillion >> Date: 27 July 2013 23:44:36 GMT+01:00 >> To: Jitsi Users >> Subject: [jitsi-users] New XMPP Server >> Reply-To: Jitsi Users >> >> I know that Emil has stated that the jit.si server is an experimental one >> and, with the developed focused on making the Jisti software even more kick >> butt, it's probably a bit hard for them to constantly troubleshoot server >> and config problems with the service. >> >> So I've set up a similar service at http://patts.us and invite anyone >> interested to use it. We support voice, video, and IM and run a Jingle node. >> We are also completely unlogged (even the web server). >> >> Just putting it out there to anyone who's interested. Not trying to poach >> users from the jit.si service. Hopefully, this will give Emil and the team a >> little breathing room. >> >> Best Regards, >> Anthony Papilloon >> >> -- > > > - -- > Bernard / bluboxthief / ei8fdb > > IO91XM / www.ei8fdb.org > > -BEGIN PGP SIGNATURE- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > > iQEcBAEBAgAGBQJR9QQmAAoJENsz1IO7MIrr6ZcIAKxL8vUD8/BuCzQckcJQDUOw > draNqwLOu+RIzm2IASVSeqw5SiXl0XRxUEi4MiBdRJuYOXumhrM2SScsAWyYLPJx > bvoogbPRaN3jaAvH8opGUoL/GUnlyO9lSxEuQKlxb8cLV+b9Ub4HwBJbyCtMWc7T > aOjzgGW3AnpXhWMftaYGkLeBH+zDgWW1VwL6fRKcYNWwcpHF6+RALVdwgtTeVSwX > aH5HH7Pnowl8wIYAefycXktx5swhpYlbwuJZ392odcJUaxMgTzgd4wF/4vovXjtn > uJR8ChFSGw05oZq8deVR/J3DTSivfzL4lCkfOxZ8y0HRX/XCrv/uOFAt7hUysAE= > =oWr4 > -END PGP SIGNATURE- > -- > Too many emails? Unsubscribe, change to digest, or change password by > emailing moderator at compa...@stanford.edu or changing your settings at > https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Feds put heat on Web firms for master encryption keys
On 25 July 2013 11:22, Nick wrote: > On Thu, Jul 25, 2013 at 11:19:22AM +0200, Eugen Leitl wrote: >> (See also https://en.wikipedia.org/wiki/Convergence_(SSL) ) > > Would Convergence help here? I can't see how. If a government > secretly aquired the SSL private keys for a site, and the site > continued using them, then no convergence notary would know any > cause not to vouch for the key. What helps here is perfect forward secrecy. BTW, better alternative to Convergence: Certificate Transparency - http://tools.ietf.org/html/rfc6962. -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] ENGAGE Open data community
PSI? CP? CSA? What are these? On 23 July 2013 18:22, Yosem Companys wrote: > From: Marijn Janssen > > You are kindly invited to join the ENGAGE community, which is a growing > community of researchers, developers, civil servants journalists, > entrepreneurs, archivists, librarians and citizens who have professional or > personal interest in Open Data and PSI. > > Feel free to search through thousands of datasets and view, download, > visualise any of them. You may also go through a simple registration process > and gain access to more value-added services, such as requesting, submitting > or extending a dataset. > > Help ENGAGE to become a social and collaborative space with significant > impact on the way Open Data and PSI is published and re-used. > > To visit the ENGAGE platform go to: http://www.engagedata.eu > > Your feedback is always welcome and highly appreciated. > > Thank you! > > Follow us on: > Twitter: @engage_eu > Facebook: engage.project > > ENGAGE is a combination of CP & CSA project funded under the European > Commission FP7 Programme. > > - > A.M.G. (Anneke) Zuiderwijk - van Eijk > Researcher > > TU Delft > Faculty of Technology, Policy and Management Building 31 Jaffalaan 5 > 2628 BX Delft > The Netherlands > > T +31 (0)15 27 86471 > E a.m.g.zuiderwijk-vane...@tudelft.nl > W > http://www.tbm.tudelft.nl/over-faculteit/afdelingen/iss/sectie-ict/medewerkers/anneke-zuiderwijk-van-eijk/ > > -- > Too many emails? Unsubscribe, change to digest, or change password by > emailing moderator at compa...@stanford.edu or changing your settings at > https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Interesting things in keyservers
On 17 July 2013 06:45, Micah Lee wrote: > I'm working on a talk for OHM2013 about PGP. Can anyone send me examples > of interesting keys in key servers that you know of? http://shoestringfoundation.org/cgi-bin/blosxom.cgi/2004/07/01 > > For example, attempts at XSSing Enigmail (I think one of these is mine > from long ago -- and BTW, Enigmail isn't vulnerable): > > http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x6E5D912BBF74A1A6 > http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0xBDE99D48C65A27EC > http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x06AB7A6AA7B3C04D > http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0xC1BBD7FB306E2139 > > I remember seeing a key once that was full of ASCII art user IDs or > maybe sigs, but I don't remember what to search for. Anything else > interesting? > > -- > Micah Lee > @micahflee > > > -- > Too many emails? Unsubscribe, change to digest, or change password by > emailing moderator at compa...@stanford.edu or changing your settings at > https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Conference proceedings: E-Voting and Identify
Why would I want to give Springer money for their old rope? On 15 July 2013 17:34, Yosem Companys wrote: > E-Voting and Identify > 4th International Conference, Vote-ID 2013, Guildford, UK, July 17-19, > 2013. Proceedings > http://link.springer.com/book/10.1007/978-3-642-39185-9/page/1 > -- > Too many emails? Unsubscribe, change to digest, or change password by > emailing moderator at compa...@stanford.edu or changing your settings at > https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] Bring some UX/UI help to open secure apps
On 13 July 2013 20:42, Travis McCrea wrote: > I have talked about this in the past, we need to make things look nice > otherwise they are not going to be used and they lose their security > advantages. I will give a case and point, I recently revoked my old GPG key > because it's been active for over a year and I know that my computer has > been out of my sight with customs agents a lot lately. I haven't generated a > new key because then I have to open up a terminal and go through the process > of making a key and then saving my key, etc. > > If I had a mail client with GPG integrated told me "hey your key is a year > old! do you want to have it recreated?" I could click yes, and have the GUI > guide me through key creation, it would update all my mail settings and key > servers and life would be good. > > Because it doesn't do that, I have been not signing my emails for a week or > so now waiting to "get around" to setting it up. > > I use Skype instead of Jitsi, and honestly when I need to have a conference > with someone I tell them "you should just download Skype", I don't want to > have to guide them through a program that was clearly developed by engineer > brained people > > > TL;DR - Shiny things make me use the product more, if someone creates a > crowd sourcing campaign for designers I would contribute. +1. > > > On 2013-07-13, at 2:43 PM, Jerzy Łogiewa wrote: > > Jitsi > > > > -- > Too many emails? Unsubscribe, change to digest, or change password by > emailing moderator at compa...@stanford.edu or changing your settings at > https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
