Re: [liberationtech] Snakeoil and suspicious encryption services
On 07/19/14 11:13, carlo von lynX wrote: On Fri, Jul 18, 2014 at 7:59 AM, Lorenzo Franceschi-Bicchierai lorenzo...@gmail.com wrote: I was wondering if it's time to make a list of not-so-good snakeoil encryption services that have popped up after the Snowden revelations. Let's look at the long-term solutions. We keep a map of them on http://youbroketheinternet.org - anything that uses public-key routing instead of trying to put a band-aid over the existing Internet is in it. Everything that has a chance of protecting metadata is there. Carlo's categorization in three categories: snake-oil, band-aid, and solution is a good one. Stretching that analogy: right now, internet security is mortally wounded: 1) Almost all protocols leak both content and the social graph; 2) Our operating systems protect themselves against hostile users, they don't protect users against a hostile internet - hence the rampant malware problem; 3) Browsers have a long way to go. While I really applaud the efforts of http://youbroketheinternet.org (I was part in that), *we need the band-aid now and we need a lot of it!* After the patient has been stabilized we can concentrate on the cure. Due to the inertia, it will take 15 to 25 years for an innovation to become mainstream. If it succeeds at all. Internet innovation go at that same glacial speed. Just look at speed of uptake on ipv6. Everything that tries to insist on using insecure technologies such as X.509, DNS, DANE can at best be a band-aid. Everything that tries to put encryption on top of SMTP, XMPP, HTTP instead of underneath, is vulnerable. If it's not vulnerable technically, it is by usability. DNSSEC and DANE have been in the making for 10 to 15 years. With these technologies, I've shown[1] that it can be used to combat phishing, increase confidentiality of private messages and eliminate most problems with passwords over the internet. And it makes it easier to use. No usability problems like PGP. Therefore I propose to focus the effort of investigation how to tell band-aids apart from snake-oil. Many of the criteria have been provided by Carlo. In fact, many people are still in the 'I don't have anything to hide'-fallacy mode. It will be a long journey from the current brokenness to the goals that Carlo envisions. Any step that each of makes along that journey is an improvement. And I applaud anyone who makes the first step. I pray that it is a band aid and not snake-oil. With regards, Guido Witmond. 1: http://eccentric-authentication.org/blog/2014/06/25/talk-for-icann.html -- 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] DNSSEC to the rescue. Was: Snakeoil and suspicious encryption services
On 07/22/14 13:47, Aymeric Vitte wrote: I am thinking about these issues since quite some time, unfortunately I reached the conclusion that you can not secure the code loading. A humble suggestion: With https, a self signed server certificate, a DANE record of that certificate in DNSSEC and a browser plugin (extended DNSSEC/DANE validator of cz.nic) that validates the DANE record would make code loading from the original site secure against a MitM. That way you could host all your javascript at the site. (but not at the CDN). Now the question becomes: Do the users find a reason to trust peersm with their business. Users are still vulnerable to a NSL delivered at peersm. with regards, Guido Witmond. -- 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] DuckDuckGo and PRISM
On 04/29/14 11:22, carlo von lynX wrote: Talking about tools that we should not recommend, I really don't get it why DuckDuckGo is being listed everywhere as the number one reasonable alternative to Google considering that they are based in the US and subject to US legislation which enables the PRISM program. It is just 100% naive to expect that for some magic reason DuckDuckGo is exempted from that program. I am sure the folks are great, just like the ones working at Google.. and the t-shirts that were distributed at the NYC #TA3M event are really nifty. But still, why use a service that by law has to comply to surveillance requirements if you can use services that are outside US jurisdiction? Somebody please explain. Are we suffering from the centuries old problem that if it is our people doing it, then it's okay? That's the definition of corruption, pretty much. It's two things: 1. Search is inherently a trust-thing. One has to trust that the search engine give you the results you are looking for. Whether it's a centralised service or a decentralised one. 2. Using DDG or ixquick et al is easier than blocking cookies, that requires eternal vigilance. Something that normal users love to outsource to others. (ie, forget about). DDG promises them that. The message to spread is that if one wants secure search, use Tor, inside Tails. Guido. -- 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] Trsst Encryption
On 03/20/14 14:17, Michael Rogers wrote:
You should use a constant-time comparison here to avoid timing
attacks. Something like:
boolean matches = true;
for (i = 0; i 32; i++) {
matches = (digest[i] == decoded[i + 32]);
}
if (!matches) {
// incorrectly decoded: we're not the intended recipient
return null;
}
Wouldn't this be vulnerable to a compiler-optimisation that
short-circuits the = operator?
If so, will this be better?
// count the number of matches; must be equal to length.
int len = 32
int matchcount = 0
for (i = 0; i len; i++) {
matches += !(digest[i] == decoded[i + len]);
}
if (matches != len) {
// incorrectly decoded: we're not the intended recipient
return null;
}
regards, Guido Witmond.
--
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] self signing certs by default
On 03/14/14 19:56, Julian Oliver wrote: ..on Fri, Mar 14, 2014 at 10:46:30AM -0700, Lucas Gonze wrote: Let's say web servers auto generated self-signed certificates for any domain that didn't supply its own certificate, likely one from an authority. What that would accomplish is to make the stream unreadable over the wire, unless the attacker was willing and able to do an MITM with their own auto generated self-signed certificate. It would not be hard to do that MITM, but it would be orders of magnitude more expensive than copying unencrypted bytes off the router. It would not be practical to do the MITM against a large portion of traffic. The attacker would have to pick their targets. Thoughts? It would be good if Debian and other popular GNU/Linux LAMP distributions made OpenSSL/TLS key generation (and set up of a VirtualHost template for :443) an encouraged option during an Apache installation (OpenSSL is a dependency anyway). It could be a simple walkthrough with Qs for CN and admin email, abstracting over the classic and ungainly: openssl req -new -x509 -days 365 -nodes -out /etc/ssl/localcerts/apache.pem -keyout /etc/ssl/localcerts/apache.key One could also automatically derive the DNSSEC-DANE TLSA record from that server certificate and mail it to the sysadmin. Include a paragraph that explains that by publishing that record, the site has stronger protections against MitM-attacks than possible with CA-bought certificates. (the downside is that user need to install the Extended-DNSSEC-Validator plug in). Regards, Guido. -- 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] self signing certs by default
On 03/14/14 22:45, John Adams wrote: You misunderstand the signing practice if you think this is a good idea. I don't get it yet, in which part would I be getting wrong, the signing of server certificates by CAs, or the DNSSEC/DANE part? Please elaborate. Granted, it provides a low level of encryption for clients but it does not provide Non-repudiability to those users, opening them up to MitM attacks. I don't think non-repudiability is offered to users who connect to a site with a server certificate. I believe one needs client certificates and message signing for that. Regards, Guido. -- 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] Amazing New Privacy Product for Webcams
On 03/02/14 20:26, Sal Privacy wrote: More and more people are being spied on. In February, it was announced that *1.8 million *Yahoo! users had their webcams hacked and images intercepted. Allegedly there are backdoors into all *web-connected camera device*, and people can watch you without your knowledge or permission. Sorry Sally, The 1.8 million Yahoos haven't been hacked. Their communication streams have been copied at the network routers, while they were using the camera for what it was designed. Transmit their video to the other party. Blocking a camera (and muting it's microphone) are wise things to do, but here Yahoo had 'forgotten' to implement end-to-end encryption. Guido. -- 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] Amazing New Privacy Product for Webcams
On 03/02/14 21:13, Andrés Leopoldo Pacheco Sanfuentes wrote: Isn't it reasonable to assume that EVERYBODY IS BEING OR IS BOUND TO BE SPIED ON in the Internet? Shouldn't we just assume that, and move on to other, more interesting, things? You can safely assume that... ... and give in and use the internet for exchanging grandma's cookie recipes. IMNSHO, iT is very silly to think that a ragtag global crypto-activists would have EVEN THE SLIGHTEST CHANCE to beat the NSA, ETC. Or discuss ways to create better end-to-end encryption so the NSA can't spy on everybody economically and has to decide who to watch and who to leave out. Even Keith Alexander is suggesting something like that: http://www.techdirt.com/articles/20140228/07355126387/keith-alexanders-big-idea-what-if-nsa-just-collected-phone-data-suspected-terrorists.shtml Let's build the tools to make that reality. That's why I'm on lists like this. Regards, Guido. -- 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] Concerns with new Stanford University security mandate
On 01/29/14 23:38, Jonathan Wilkes wrote: On 01/29/2014 04:50 PM, Guido Witmond wrote: On 01/29/14 19:57, Jonathan Wilkes wrote: On 01/26/2014 08:12 AM, Guido Witmond wrote: BigFix: the missing package manager for Windows. What every self respecting unix/linux/bsd/etc system already has. Good. How is a centralized service that requires the user to download and install a binary from the web anything like apt? Don't get me wrong, nearly anything is better than just bare Windows. But an honest, courageous approach would actually encourage the oddball student who runs Debian Wheezy or whatever else that is lightyears ahead of Windows in terms of security. Does this security mandate do that, or does it merely hope that the ideal of academic freedom will just get fed up and go find some other domain to bother? I fully agree, being Microsoft free since 1999, myself. However, the apt-package manager doesn't upgrade anything compiled into usr/local, hence, the need for a scanner. Hi Guido, Before I write anything else: Is the BigFix client free software? Couldn't figure it out from a quick look at the website. I wouldn't know. Being an IBM acquisition, my first guess would be that it is proprietary. If you want something to scan you linux/bsd-box, there are good tools available. Even good-old tripwire could help you. Or Samhain, that also checks for setuid executables. regards, Guido. -- 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] Concerns with new Stanford University security mandate
On 01/29/14 19:57, Jonathan Wilkes wrote: On 01/26/2014 08:12 AM, Guido Witmond wrote: BigFix: the missing package manager for Windows. What every self respecting unix/linux/bsd/etc system already has. Good. How is a centralized service that requires the user to download and install a binary from the web anything like apt? Don't get me wrong, nearly anything is better than just bare Windows. But an honest, courageous approach would actually encourage the oddball student who runs Debian Wheezy or whatever else that is lightyears ahead of Windows in terms of security. Does this security mandate do that, or does it merely hope that the ideal of academic freedom will just get fed up and go find some other domain to bother? I fully agree, being Microsoft free since 1999, myself. However, the apt-package manager doesn't upgrade anything compiled into usr/local, hence, the need for a scanner. The important thing is that BigFix can report to the user of the PC, or to university sysadmins. What matters is how they deal with any findings. That's a classic case of Who watches the watchers. Quoting the Stanford policy: Other personally-owned devices used at home or on the wireless Stanford Guest Network are encouraged to follow these mandates, but not required to at this time. Other devices stands for those not used at campus or at home for use with PII-information. Translated: Other (for non-work related) devices, used at home ... are not required ... at this time That suggests that private devices are next. I stand corrected. It has feeling of control for the sake of control. My suggestions to mr Altman (from a private message): Buy some time and use Linux/FreeBSD or Qubes-OS for your private computer use, their scanning programs are not available on these platforms yet. Use these only for personal use. Leave these computers at home. Use a dumb phone to keep contact for family business, like picking up children after school, etc. It teaches the kids that when you are at work they can't expect an immediate reply if it is not an emergency. Keep a strict separation between work and private life. Laptops are cheap. Use a separate, university controlled laptop at home for work-stuff, such as collaboration with researchers and so. Tell everyone that you maintain that separation and spread the word amongst colleagues. It's hard, but I believe it's the only way to sanity. Regards, Guido Witmond. -- 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] Concerns with new Stanford University security mandate
On 01/26/14 10:20, Tomer Altman wrote: To Liberation Tech: Stanford is implementing a new security policy detailed here: http://ucomm.stanford.edu/computersecurity/ I am personally very concerned about steps #2 and #3. BigFix is basically a back door managed by IBM that gives them and Stanford control over your device. The IDF tool effectively means that the Stanford administration can continuously search your personal laptop for any objectionable material. While there are some technical cases where one may be exempt from these new requirements, the way that it is being pushed out at Stanford is making people believe that they cannot use their cell phones or laptops on campus (i.e., connecting to the Internet, checking Stanford email, calendars, etc.) without agreeing to all of these requirements. I fully support Stanford improving security on their own computers and networks, but installing a backdoor and surveillance systems on personal laptops seems to cross a line for me. Especially in an institution devoted to open inquiry. Especially in light of the mass surveillance revelations this past year. I tried reaching out to the EFF, but did not receive any reply. I expressed by concern to the Stanford administration. They replied to a few of my emails, but it left me with more questions than answers. I am asking for advice from the community on whether this kind of encroachment has any precedents. I'm also curious to hear people's thoughts on this matter. Thank you in advance, ~Tomer Altman Dear mr Altman, From the link: No more Windows XP: Good riddance. BigFix: the missing package manager for Windows. What every self respecting unix/linux/bsd/etc system already has. Good. Identity Finder: It gives a baseline scan for all files that contain personal identifiable information, like credit card numbers (that should never be on anyones computer at all, not even your own credit card number) and SSN (likewise). Good. Encryption: Good. Central file backup: Good. Anything in that document shows the intention of solving many IT-problems that PC-users face all the time, whether they realise it or not. And the university does not make it mandatory for private devices. By taking these measures the university take responsibility for any breaches that happen from now. There is one question remaining: do you trust the university to handle this responsibility? The answers to that will become clear with how they react when they find unneccesary PII on a computer. To whom go the reports of Identity-finder? How are they going to deal with it. The intentions may be good, it's all about the actions. Good luck with it. Guido. -- 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 01/20/14 20:07, Katy Pearce wrote: Not to be a downer here, but until this is addressed: - security is incredibly easy to use - security does not slow down the internet or the computing power - security does not attract the attention of security services then all the training in the world isn't going to make people take these precautions. Kate: The first rule of First Aid is to protect yourself before helping the victim. Otherwise the next person has to take care of two victims. We need exactly that in regards of security and privacy tools. We need to weave the crypto-tools into the fabric of the Net, used by anyone at every site and every connection, even if normal users use it to spill their lives on facebook, only then can we start to train those who have a life-or-death need for security and privacy, the activists, journalists... Katy's remark above sums it up nicely. Disclosure: I'm working on a protocol and implementation to make weave ubiquitous crypto into the net[0]. My biggest hurdle: how to get people to use it Regards, Guido Witmond. 0: http://eccentric-authentication.org/ -- 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] Secure Email Survey
On 11/25/13 16:01, Dan Meredith wrote: Hello LibTech, The Open Technology Fund is surveying projects working on next generation secure email or email-like communication. The purpose of this survey is to identify potential areas of collaboration, better understand the trade-offs made by the different projects, and to help the internet freedom community better understand these projects. This survey's findings will be published publicly to serve the above purpose. So far, we have invited these projects to participate: ansamb.com bitmail.sf.net bitmessage.org darkmail.info flowingmail.com leap.se mailiverse.com mailpile.is mailvelope.com mega.co.nz opencom.io parley.co perzo.com pond.imperialviolet.org retroshare.sf.net scramble.io startmail.com All these projects are working on email or email-like communication that departs from traditional encrypted OpenPGP or S/MIME email in one way or another. Although this survey only applies to asynchronous messages (i.e. not synchronous chat), there is a great deal of diversity among the approaches. Some projects are open source, some are not. Some projects provide services, some provide only software. There are centralized, federated, and peer-to-peer approaches. There are HTML5 apps, desktop apps, mobile apps, and extensions. You get the idea. Please let us know if we are missing any projects. I believe you might be interested in mine. It's a project that tries to use existing technologies in a slightly different way to achieve a very high level of privacy and security by default. It could be used to get Granny use encryption. Although I aim at encrypting the Web, it can be easily used for an email-like service. One does not preclude the other. I've completed the survey and attached it here. With Regards, Guido Witmond. General project information -- What is the name of the project? - Eccentric Authentication Do you represent the project? - Yes Do you want to share your email address? - Yes, gu...@witmond.nl What programming languages is the project primarily written in? - Go What is the distribution license of the projectâs software? - AGPL v3+ Is there a URL to the projectâs source code, and if so, what is it? - https://github.com/gwitmond/eccentric-authentication https://github.com/gwitmond/ecca-proxy Where is the design of the software and protocols used documented? - http://eccentric-authentication.org Is the project email or email-like (or both)? In other words, does it use SMTP? - No SMTP at all. - It uses a web site to: - introduce strangers to each other; - exchange public keys; - transmit encrypted private messages. - It could be backported to IMAP. Which of the following applications does your project include: * A user agent (currently a web proxy to run on the end users computer) * A web site that sends out some specific HTTP-headers What platforms does the project currently support? - Debian Gnu/Linux 64 bit. - Any other sytstem that compiles Go(lang), libsqlite3 and libunbound. What platforms does the project plan to support? - Planning on getting a Firefox plug in Do you also provide service using your software? (For example, do you provide email accounts for users? * We do have a few demo sites running. These are for free. * Some parts of the protocol could be outsourced to a third party. - There could be a (paid) service for the part that does client certificate signing. It could help site operators that don't feel so confident with cryptography. - Also, the web hosting can be outsourced. * Best not to outsource the sites' Root CA key management. It might lead to a gagged disclosure leading to a duplicate site undetectable to the user agent. It will be detected soon, but some harm may have been done. If you have not already, when do you plan to launch a âpublic betaâ of your software or service? - Still alpha. In addition to email/email-like communication, what other types of communication does your software or service support, if any? - Primarily, it's a protocol to exchance keys between total strangers; - We use public signed messages and private encrypted messages; - Email-like messaging is one use case of the protocol. General security questions Which crypto libraries does the project primarily rely on? * the user agent at the client requires: - TLS 1.2 with renegotiation. Implemented with the Go-crypto libraries. Could be ported to any language with a decent crypto-library. Go does not implement renogiation :-( - Uses DNSSEC and DANE with all their crypto. The user agent does the DNSSEC-resolving. - No javascript is used for encryption. All crypto and authentication happens at a layer below javascript, out of control of javascript. - No WebRTC either. The server uses bog-standard http-servers with TLS. It must be configered with a server certificate and a Root
Re: [liberationtech] Secure Email Survey
I've completed the survey and attached it here. With Regards, Guido Witmond. Oops, send out to the list, instead of privately. Please be careful with any information in there. It's toxic, powerful and highly flammable. Feel free to discuss part you find interesting, appealing or appalling. Regards, Guido. -- 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] Eccentric Authentication again
Hello all, I've written two new blog entries on eccentric authentication. The protocol that uses client certificates and a local CA to distribute public keys between strangers in a secure way. I hunbly believe it is the most user friendly way to do cryptography correctly. End users don't see the crypto at all. Please read in this order: http://eccentric-authentication.org/blog/2013/08/31/the-holy-grail-of-cryptography.html http://eccentric-authentication.org/blog/2013/09/05/a-subversive-idea.html I'd love to hear comments, remarks, improvements. Feel free to play with the demo. Regards, Guido. PS, it needs Tor or others to protect against traffic analysis. -- 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] Sociological studies of covert mass-surveillance organisations
On 09/01/13 22:49, Michael Rogers wrote: On 01/09/13 10:00, Caspar Bowden (lists) wrote: AFAIK Deleuze, Foucault et al. did not say anything specifically about covert (mass-)surveillance, or analyse how the inherently secret nature of such organizations might be a causal element in theories of social control. Secret surveillance organizations are NOT Panoptic in a technical sense - they normally don't want you to know or fear they are watching (with tactical exceptions). Is there anyone who's aware of overt surveillance and who doesn't at least suspect that some form of covert surveillance also exists? And isn't that suspicion enough to create a panoptic effect? The prisoners don't know whether they're being watched at any moment, or whether the watchtower is even occupied; the secret surveillance organisation, the existence of which cannot be confirmed, corresponds to the warden who may or may not be in the watchtower. Wasn't the NSA closer to the panoptic ideal when it was No Such Agency than now, when we know we're being watched? The one 'good' thing about the original Panopticon design is that you *know it* when you are inside one. Inside a panopticon, you don't have the luxury of denial. The fact that this opportunity of denial has been taken away makes so many *watched* people upset. Before the revelations and the subsequent confirmations, many people would rather believe the old truth (having nothing to hide) than to live with the new truth that they've been misled. Truth hurts. That's the reason why so many people claim they have nothing to hide. It's emotional. 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] Standalone JS apps vs. browser extensions, which is better?
On 08/26/13 20:44, Francisco Ruiz wrote: 2. Even worse, if they save any data (public keys, in this case), the database remains tied to each particular computer. Forget about going to the library and using it there. Forget about going to the library. The public access computers are a cost for the library. Not a tool for internal use. The amount of care that the libray sysops have for malware protection is lower than that of their computers for themselves. It's not malice, just lower priorities. These public access computer are good to read a digital newspaper, search the catalog of the library and other public news sources. However. *Never ever, type in your credentials on these machines!* Friends don't let friends use public terminals. I once read a comment stating that public access computers contain as much viruses as that good looking prostitute in that oriental bar. It is time to reincarnate that meme. 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] Demos of eccentric-authentication
Hi Francisco, On 08/13/13 22:37, Francisco Ruiz wrote: Hi Guido, This looks very interesting, but I have trouble understanding it. Can you give me a sample URL where this is being shown in action? Thank you for your interest. The protocol is still in the proof-of-concept phase. I've a few demo sites: 1. The first shows that with a simple web proxy (at the clients' computer) users can create client certificates more easy than creating passwords accounts. It's the 'Favorite Number Site' at https://www.ecca.wtmnd.nl/ (I use numbers instead of text to avoid blog-spam, otherwise, it would be prototype blog site). If you go to that site, you'll get scary certificate warnings as the certificates are signed by my own CA. The CA is specified in DNSSEC, to validate it. The proxy takes care of al the crypto, including validating the server certificate against DNSSEC. To use the proxy, download the ecca-proxy binary (and run it in a Debian 64 bit VM). Run it. And configure your browser to proxy http (not https) to localhost:8000. Then browse to the site with http://www.ecca.wtmnd.nl (not https). It's the proxy that does all the crypto-stuff. When you're done, close the proxy and run: $ sqlite3 eccadb.db SELECT * FROM accounts; # there are your X509 certificate and private key. 2. The second demo uses the same proxy. Start it up again and point your browser to http://dating.wtmnd.nl:10443/ It's an showcase of both anonymous login and secure messaging between two total strangers. If you click 'The Aliens' and then choose 'guido@@dating.wtmnd.nl' you can write a message to me. Your instance of the proxy fetches my certificate and public key and encrypts the message. Not even the site operator can read the message. Check out the Walkthrough of the Datingsite [0] blog entry on my site to get an idea. To run the proxy: click the run it yourself [1] blog. Or use the source on Github. I don't have any demos on the Cryptographic Same Origin Policy yet, as that requires some changes to browsers. With some funding (or volunteers) I could create a Firefox Fork to demonstrate that. Guido. [0]: http://eccentric-authentication.org/blog/2013/06/12/walkthrough-datingsite.html [1]: http://eccentric-authentication.org/blog/2013/06/07/run-it-yourself.html On Mon, Aug 12, 2013 at 4:34 PM, Guido Witmond gu...@witmond.nl mailto:gu...@witmond.nl wrote: Dear professor Ruiz. The real issue is to create an *easy* way to do hash validation correctly. Reading a hash on youtube is not going to make it. You use HTTPS without DNSSEC and DANE. Please use those first. It solves a lot of your server validation issues. At least it allows your users' browsers to validate code44.com http://code44.com. I repeat: Hashes are for computers, not for people. Plugging my own warez: I believe I've come up with a way to do DNSSEC and DANE in combination with a certificate repository. It allows the browser to validate the authenticity of a server certificate. When validated it can be sure that the javascript found at a page is indeed that what the page-author wanted. Please see: http://eccentric-authentication.org/blog/2013/03/23/Cryptographic-same-origin-policy.html And please ask if anything is unclear. I love to receive comments on where I'm right or wrong. Regards, Guido. -- Francisco Ruiz Associate Professor -- 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)
On 08/14/13 15:18, Ben Laurie wrote: On 14 August 2013 08:54, Guido Witmond gu...@witmond.nl 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. 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*. We need them both! To keep the CA's and registrars honest. I really appreciate your work on CT. 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] In defense of client-side encryption (Guido Witmond)
Thank you for your quick response. I'm not convinced by your arguements yet. I comment in between. On 08/12/13 04:13, Francisco Ruiz wrote: 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. What you run into is the classical secure distribution problem. With native applications (not js-apps) that's a once-per-install hurdle. With a server serving pages, it's a once-per-run hurdle. Unless, somehow my browser remembers the code. Then it degenerates into *installed* code. Now we have the secure update problem in another form. 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. 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... I think I change my mind on voice hash verification. It's a neat idea but a big hassle. Not even GPG users check the certificates and identities. They just assume that if it is encrypted, it is secure. This xkcd is spot on: http://xkcd.com/1181/ I am using GPG to encrypt mail to a certain person. He uses one key to send mail to me, and I use a different key to send back. I haven't seen a complaint from him... 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. Ok, here it comes: What is the music on the background? How do I know it is your music and not a score that the attacker downloaded from mp3.xyz? Hashes are for a computer-verified protocol. Not for humans. My view on Javascript as a platform: Browsers and javascript are a platform on their own. They are becoming operating systems. Firefox even calls their browser OS. Operating systems are not neutral technology. *He who controls the operating system, controls the user.* The most important aspect of operating systems is not to schedule resources efficiently. It is to *protect the user* against all threats, both external as well as their own ignorance/stupidity. The current crop of operating systems has gone a long way from DOS to where we are now. Unix/linux went through that phase, Windows followed. We still haven't got a way to protect against malware, drive by downloads and other threats. Threats due to the Ambient Authority model of Posix. See Polaris, KeyKos, Eros-os, genode.org, Qubes-os, MinorFS for capability-secure solutions to the malware problem. Why are virtual machines so popular? It's an easy way out of the ambient authority. But instead we have Javascript trains that are just leaving the DOS-station. Relearning all security errors from the past. The hard way. Again. No thanks. Let's fix our current OS'es first Regards, 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] Does anyone know a celebrity who feels strongly about privacy issues?
On 08/12/2013 04:32 PM, Francisco Ruiz wrote: Quick request. In comments to a recent post, people seemed to agree that publishing a video of someone reading a hash might be a fairly hard-to-hack way to deliver that hash to the public, and thus assure the authenticity of a piece of code, a public key, or whatnot. The problem is that the sample youtube video I linked had yours truly reading the hash, and people naturally objected that I wasn't Justin Bieber and, consequently, weren't too convinced that the video was authentic. So, here's my question. Does any one know of a celebrity who cares enough about computer security to be persuaded to take one minute of his/her time to read a hash before a camera? Thanks a million! On 08/12/13 22:41, Richard Brooks wrote: Some idle thoughts: Edward Snowden Bradley Manning Julian Assange Gen. Hayden Jacob or Nadim Dear prof Ruiz, I made the comment about celebrities in jest. I just don't believe that people will validate hashes anyway. But if you manage to convince any of those names to read your hashes, I will certainly use your product. Or never ever, depending on my opinion of the readers' knowledge about computer security. Regards, Guido. PS, I got the name wrong: http://www.classicfm.com/composers/biber/guides/biber-vs-bieber/ -- 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] Does anyone know a celebrity who feels strongly about privacy issues?
Dear professor Ruiz. The real issue is to create an *easy* way to do hash validation correctly. Reading a hash on youtube is not going to make it. You use HTTPS without DNSSEC and DANE. Please use those first. It solves a lot of your server validation issues. At least it allows your users' browsers to validate code44.com. I repeat: Hashes are for computers, not for people. Plugging my own warez: I believe I've come up with a way to do DNSSEC and DANE in combination with a certificate repository. It allows the browser to validate the authenticity of a server certificate. When validated it can be sure that the javascript found at a page is indeed that what the page-author wanted. Please see: http://eccentric-authentication.org/blog/2013/03/23/Cryptographic-same-origin-policy.html And please ask if anything is unclear. I love to receive comments on where I'm right or wrong. Regards, 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] 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] Why ~not~ S/MIME?
On 30-07-13 09:56, Ali-Reza Anghaie wrote: For obvious reasons we're in another spike of everyone should PGP discussions - pretty much every direction you look. This always tugs at the back of my mind - why not push S/MIME a bit more? In my own experience the most common adoption problems with PGP for the uninitiated is getting the software to work where they want it and managing keys (including finding another person's key). Taking this from a push for adoption approach and not our ideal solution approaches, consider: - S/MIME is implemented in more places stock - S/MIME has at least one well supported Gmail option in https://www.penango.com/ - S/MIME directories are generally more apt to just work for the end-user once setup - S/MIME certificate management is more intuitive for first-timers IMO The two big objections to S/MIME I see more frequently are downloading your certificate from third-party and cost to get certificate. My biggest beef with S/MIME is the certificates of the CA's. The CA's validation policy requires you to prove your real world identity to them. Which they then write into the certificate. It means that each and every email is tagged with your true identity for life. No thanks There are certain good uses for it: give one to each politician. They might be more honest knowing there is no plausible deniability. :-) Other good use would be to sign the public records of a Notary public with S/MIME. Too bad the one CA for that market had lousy security: DigiNotar. Cheers, Guido. -- 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] Convergence: does anyone use it?
On 28-07-13 22:20, Patrick Mylund Nielsen wrote: On Sun, Jul 28, 2013 at 1:03 PM, Yan Zhu y...@mit.edu mailto:y...@mit.edu wrote: It seems to be the browser extension http://convergence.io/ that everyone talks about but nobody uses. For one, the original repository isn't actively maintained, and I found at least one unpatched issue that keeps it from working in recent Firefoxes (see https://github.com/moxie0/Convergence/issues). Is anyone running it? Thoughts on whether it's worth forking and patching? Perspectives, on the other hand, is a similar project that is quite active but seems to get less mentions: http://perspectives-project.org/ -Yan Unfortunate, since Convergence is based on the research done in the Perspectives project. Moxie deserves credit for sure, but he seems to be getting (almost) all of it. An Ubuntu-and-Debian-esque situation, if you will. Why is neither used by the masses? Because nobody changes their settings: https://www.imperialviolet.org/2011/09/07/convergence.html That's going to be a hard problem to solve. The reason I stopped using it is that the trusted notaries sign a certificate with their own CA-key. It removes the original certificate from view. It's therefore indistinguishable from a MitM attack. Perspectives, on the other hand, adds an extra out of band validation that tells me why it comes to a certain result. Please see screenshot with Convergence and plain Firefox: http://witmond.nl/conv-mitm.png Cheers, Guido. -- 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] WC3 and DRM
On 25-07-13 19:14, Jonathan Wilkes wrote: On 07/25/2013 07:14 AM, Mitar wrote: Hi! Some very good arguments *for* DRM on the web: http://unitscale.com/mb/bomb-in-the-garden/ On the first pages,the author makes this point: The web is good at making information free. Which he contradict in the next sentence: So the web has had to rely largely on an advertising economy. I don't agree that the web is making information free. The advertising industry is extracting rent in the form of monetized eyeballs. Part of the advertising revenue is used to pay for the servers and administrators of the content-platforms. Other part of the revenue is profits of the ad-industry and lost. I don't get 'free' content for that. The problem with the web is that is favours a central distribution model and forgoes geographical caching. For example, if I read an interesting blog and send to URL to a friend in the same room, the data that forms the blog has to travel all the way from the original site - over all the same paths - a second time for my friend. Just so he can have an identical copy. He gets an identical copy of the important bits that mattered: the blog. He might get different bits that don't matter, the advertisements. If we had an easy way for me to transmit the blog to my friend, the important bits would have an almost zero cost of transport while the unimportant bits need the expensive path. Here the waste of advertisement is showing. In technical terms, my computer/tablet/phone could cache the data in a way that my friend could retrieve. Transparent to all parties involved. This was the dream of many caching schemes. There were many reasons it failed. I would like to see a revival of those schemes. The W3C can lock down their version of the centralised net. I pursue the old dream of efficient distribution. It might work miracles on mesh networks, leaving no trails of me giving my friend a copy. Regards, Guido. -- 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] DecryptoCat
On 10-07-13 00:57, h0ost wrote: On 07/09/2013 06:25 PM, Petter Ericson wrote: What are the steps for sending Bob a message using Cables? This isn't rhetorical, I'd actually like to know what the steps are. Roughly I think this is correct: 0. Download https://www.dee.su/liberte 1. Boot any modern computer with the usb disk inserted 2. launch Claws email client 3) write message to bob's cable address and press send If you have a supported platform, you can skip 0-2 and replace it with 'install cables' - as one might install a modern browser. I do not think that installing a modern browser entails building it from source for most people. If you're going to say that using Gmail easily happens in any browser on any OS, I guess I'd tend to disagree. If we add securely into the picture, I guess I'd just laugh and laugh and laugh. Sadly. It is really a bummer that PRISM exists and that Google appears to be under the boot of that system. Though accessing Gmail with Chrome is clearly better than any other choice! Unfortunately, the question wasn't how to communicate _securely_, but how to communicate _at all_, which is what most people aim to do in the first place. Please do not pretend that hash@hash.onion is as easy to remember as j...@cervant.es or something similar, or that installing dependencies and building from source is similar to a one-click installer. Best /P Well, not be cynical, but I think people would have to exert a few more iotas of energy, and learn how use Tor or software like cables starting from now on. Unless their freedom is something not that important to them. I mean, people all over have learned how to lock their doors, right? It is definitely inconvenient for me to lock my damn doors at 8 o'clock in the morning, as I am rushing off to work. But I do it, because it has been impressed upon me that it is rather important to do so for obvious reasons. I think, it is too much to ask of people to change their ways. Most of the front doors around here fall into closed mode with a gentle push. The wedge shape part makes that automatically. Especially in an 8 o'clock rush. The reason people lock these doors is fear of theft. With email, there is no fear, nor theft. And there is nothing to hide... I believe the only way forward is to make using security easier than not using security. Ie, secure/privacy by design. That's what cryptocat is trying, dee.su/cables appears to do so in a spectacular easy to use way. Will have to check it out. And so do I try to reach that holy grail too with my eccentric-authentication. Cheers, Guido. http://eccentric-authentication.org/ -- 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] How to protect users from compelled fake ssl certs?
On 02-07-13 05:51, Anthony Papillion wrote: What is the most effective way to protect users against a compelled fake certificate attack? Since any CA can issue any cert and any US based CA could probably be compelled to issue a fake CA, how can we protect against this? My initial thought would be to publish the certificate fingerprint on a website and encourage users to verify that what they have matches every now and then. But this is a huge hassle for users. Yes, that's the way it is done. Check http://perspectives.project.org; Transparency: http://www.certificate-transparency.org/; or others. Are there any better ways? Publish the sites' TLS certificate in DNSSEC with DANE. Or use the CAA proposal. DANE: https://tools.ietf.org/html/rfc6698 CAA: https://tools.ietf.org/html/rfc6844 The difference is: (from the CAA-rfc) Like the TLSA record defined in DNS-Based Authentication of Named Entities (DANE) [RFC6698], CAA records are used as a part of a mechanism for checking PKIX certificate data. The distinction between the two specifications is that CAA records specify an authorization control to be performed by a certificate issuer before issue of a certificate and TLSA records specify a verification control to be performed by a relying party after the certificate is issued. Guido. -- 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] How to protect users from compelled fake ssl certs?
On 02-07-13 17:32, coderman wrote: On Tue, Jul 2, 2013 at 2:36 AM, Guido Witmond gu...@witmond.nl wrote: ... Check http://perspectives.project.org; Transparency: http://www.certificate-transparency.org/; or others. ... Publish the sites' TLS certificate in DNSSEC with DANE. Or use the CAA proposal. i would still prefer the best option where available: certificate pinning from the service and application provider directly. e.g. Google Chrome cert pins for Google services. Certificate pinning certainly provides the best protection when connecting to Gmail with a Google provided Chrome browser running a Google provided operating system. I don't expect them to provide anything less (secure) for their customers/users. But it does nothing to protect me when connecting to sites that Google does not include in their pinning list. There I have the same problem as before. you can also roll your own root and server certificate validation rules using out of band determination of valid server / ca certs if you don't trust third parties to do this properly! difficulty varies by application and platform... Those third parties have proven not to be trustworthy. That's why we need monitoring systems like Perspectives, CT. And DNSSEC/DANE or CAA to tell us which certificate authority to expect. Cheers, Guido. -- 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] What project would you finance?
Yosem Companys: Speaking of which... If you had an extra $2-3K to give to a liberationtech or crypto project, who do you think would benefit the most? I would sponsor http://genode.org/ to bring their capability os to a number of android capable devices. What's lacking in current operating systems is a good way to protect the end users' private keys while keeping it usable. Check http://en.wikipedia.org/wiki/Principle_of_least_authority why. Guido. -- 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] secure download tool - doesn't exist?!?
On 01-07-13 23:01, Eleanor Saitta wrote: On 2013.07.01 12.19, adrelanos wrote: - you still have to tell the user you must download tool X before you can download Y This, of course, is a global problem everywhere. A secure channel requires a shared secret, in this case between the developers and the end user. How does the user get their initial OS image if it didn't come with their machine or they didn't buy it in a brick and mortar store (both hard for FLOSS). Solutions in the non-general case are nice, but we should also remember that we have no general case solution either. There is a (partial) solution for this problem. The site operator creates a server certificate. Either a global TTP or self signed. (S)He publishes it with DNSSEC and DANE. The users who want to download can verify the server certificate with the Extended DNSSEC Validator add on for Firefox. It creates a trusted path between the site and the user. Now the user can validate the site certificate and trust the hashes on the page. The reason that it's a partial solution is that it defers the trust-seed-question to the plug-in distribution channel. But that need only be solved once for the whole to benefit. The reason that the DNSSEC-chain can be trusted is that it is *politically secure*. There are too many different parties pulling in too many different directions so the net result is a stable system. Any tampering from any party will be loudly complained by any other party. The only thing you need is to Pin the DNSSEC root key into your browser. Besides we need monitoring systems such as Perspectives and Certificate Transparency in the browsers to detect DNSSEC/CA manipulations. Caveat: the Ext DNSSEC Validator is not production ready but the gist is there. I think DNSSEC may or may not be the ultimate answer but it is a good way to go forward. The 64000 dollar question: Who is going to push Mozilla in this direction? Guido. -- 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] eternity USENET (Re: Internet blackout)
On 21-06-13 17:56, Michael Rogers wrote: On 17/06/13 14:12, Rich Kulawiec wrote: One more generic comment/observation: clearly, Usenet or a Usenet-ish mechanism will run on a smartphone. But I'm not sure that's a good idea. Given the existence of things like CarrierIQ, the propensity of repressive governments to strongarm (or take over) telcos, the geolocation capabilities of cellular providers, the extant research on re-identifying putatively de-identified data, the epidemic of smartphone malware (including in app marketplaces), etc., I've kinda arrived at the point where I think no smartphones is sound advice. I agree - no smartphones is sound advice. No phones is even better. But the problem is, nobody follows that advice. So we have to be pragmatic. Given that billions of people own mobile phones, carry them everywhere, and use them for communication they'd like to keep confidential, what's the best incremental improvement we can make? Just switch off the phone before driving. Saves lives (of others) and saves your battery too. Perhaps, start calling people that use their phone while driving 'road-terrorists' then the NSA will take care of that :-) Cheers, Guido. -- 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] eternity USENET (Re: Internet blackout)
On 14-06-13 21:22, Adam Back wrote: Kind of old now (1997) but take a look at USENET eternity for a distributed censor resistant web publishing system based on USENET, PGP and hashes/committments. The documents could either by public, semi-private (secret URLs) or secured. Content updateble only by the author using PGP, and yet browseable from a web browser with the plugin. The whole thing was a perl script, but you may find the approaches interesting. http://cypherspace.org/adam/eternity/ There's an old Phrack article describing it in more detail and a howto, and the software. Adam This was exactly my jumping-off point for Briar: take Usenet, remove the path header, remove cancellation messages, require message IDs to be cryptographic hashes of the content, and require link encryption. :-) Encrypting everything should stop article spoofing. (Although it doesn't stop article flooding, and an adversary could try to overwhelm the network by injecting large amounts of traffic. Deprecating the Path: header actually makes this easier for an attacker.) Doesn't Freenet already solve these issues by actively distributing content even wider when someone wants to censor something. A sort of built in Streisand Effect. https://en.wikipedia.org/wiki/Freenet Guido. -- 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] [tt] NSA Prism is motivated in part by fears that environmentally-linked disasters could spur anti-government activism
On 15-06-13 00:30, Shava Nerad wrote: Technically, it's the duty of the military to evaluate these scenarios and act on the information *wisely*. The original analysis read to me: We face severe problems that might lead to civil unrest. We need more population control, whatever the price. Now we also have civil unrest due to the population control. We need even more funds. Isn't diverting some of the military budget on population control towards research to prevent those problems a *wise* action? Guido. It is our duty as activists to hold them on that and that's where everything collapses, because there is a crisis of trust. Listen, there is not a single great civilization in the history of the world that has not fallen to war or environmental impacts -- and many that have fallen to conquest have fallen to conquest as a side effect of (human influenced) environmental impacts of some sort (for example, heavy metals contributions theory of the decline of Rome http://www.poweredbyosteons.org/2012/01/lead-poisoning-in-rome-skeletal.html). Much as I do not trust the conclusions of the military based on the simulations they may run through, it is, in fact, their duty to run through simulations based on the four horsemen scenarios they can imagine. And it is in fact their duty to to imagine that the environmentalists are going to trump them by lathering everyone up into freaking out that the sky is falling (because, nearly literally, it is, and the government are obscurantist cowards who want to get re-elected --- oops, was that my outside voice saying that inconvenient truth?) so just as they wiretap the Society of Friends (Quakers) in times when the peace movement is bucking a war effort and making their propaganda suppository of casus belli seem not so smooth an insert, yes -- they are going to track climate change activists if they are worried about panic in time of crop failure and rationing and empty shelves in the not-so-supermarkets of the breadbasket of the world. Short on petrochemicals? Most of our crops are made of them you know, between fertilizer, transportation, and various. Worried that revelations that disruptive health effects of glyphosphate (Round-up from Monsanto -- which is responsible for most of the corn/soy monocropping grown in the US now and a good proportion of other crops in this country and worldwide) in mammals may make revelations of DDT in the 60s look tame? Oops, there goes the 20% of the grain capacity of our current green revolution phase. That brings the planet down by a billion in carrying capacity, without global warming. These are the kinds of ecological messages that might make the military nervous. (Hi, for those of you who are listening! :) And they are correct to be nervous. They should be planning for rationing and unrest if a severe scenario comes up -- if for no other reason than that we will have hungry neighbors that will make a zombie apocalypse look pastoral. And these are ugly scenarios to think about. That's what we delegate to the military and law enforcement, ideally, as a sacred trust (the other side of sacred being taboo -- we don't *want* to have to ponder what happens in our neighborhoods when the food supply should go away for whatever reason and FEMA isn't the answer). So this is why one might, as a conservative even, think Prism is an UTTER TRAGEDY. Because it represents a broken social contract by pure dissonance, a lack of trust so profound, a disengagement so deep and suppurating, that we can't even imagine any more why it is that we would need a military to know these things that we could trust. (And as a disclaimer: I have family in the military, and have for generations, and have stubborn hope these things are fixable through both military/DHS/civilian elected/non-elected leadership) The problem is NOT that these scenarios are being spun out. They should be. The problem is, what is the response to each scenario proposed to be? I don't see that? And I expect that would be in executive control at the time of crisis. And there's where trust falls apart. Because this: http://www.gpo.gov/fdsys/pkg/FR-2013-04-12/html/2013-07802.htm essentially repeals this: http://en.wikipedia.org/wiki/Posse_Comitatus_Act ...and even with my background? I have a hard time with that. A very very hard time with it. This is not the cat is dead and not dead. The cat is DEAD, wrapped up in a brown shirt, weighted down with stones and dropped in the river. I am sorry, I do not understand how this can happen in this country without open discussion with the electorate. This is not something you do, undermining the Posse Comitatus by a snippet of regulation from the executive branch. That is not the way this democracy works. yrs, SN On Fri, Jun 14, 2013 at 3:26 PM, LilBambi lilba...@gmail.com mailto:lilba...@gmail.com wrote: Thanks for all the great food for thought. So much going on... On Fri, Jun 14, 2013
Re: [liberationtech] Guardian reporter delayed e-mailing NSA source because crypto is a pain
warning: plugging my wares [1] (again). On 12-06-13 10:05, Andrew Feinberg wrote: What exists is godawful at worse and cumbersome at best. For a cryptosystem to really, and I mean really become widespread enough to make an impact, it needs to be designed and implemented in such a way that a given user who wants to add that level of security to his** email need only install at the very least some manner of plugin to an existing client, or at most switch to an easy to use replacement which has that functionality built in seamlessly. Key exchange would have to be as easy as forming connections on a social network. Heck, a crypto-social network might be the best way to jump-start such a thing. plugI've come up with something that might fit your requirements. Technobabble: Users can create an cryptographic identity at the click of the mouse. With the verification methods I describe at the project site, it allows for man in the middle detection and prevention. His user agent takes care of all the crypto-details. User sees: he creates an account at a (web) site by requesting an account name to be his. No need for email addresses, or identity validation that CA's do. You can test it by downloading (or compiling) the user agent [2] and contact me at 'guidow@@dating.wtmnd.nl'. [3] /plug But let's be honest here -- I think we all are aware on some level or another that even if one was able to develop and deploy the easiest software imaginable (say, Apple's iCrypt that they'd allowed to be vetted, even made key parts open source) and the most robust algorithms known to man, it's not enough that it be easy to use -- it has to become widely adopted, at least among enough of the population that assuming easy key exchange, it would become a non-event for someone to send or receive an encrypted message. It would have to definitely be widespread enough that, if we also assume pervasive surveillance -- at least on a passive filtering level of some kind -- that to see cyphertext being transmitted back and forth would be common enough that it wouldn't raise alarms or attract attention of any sort. That's the problem, I'm facing, getting the initial seed planted. Let's get real -- assuming surveillance is the new normal, isn't it more likely that cyphertext in the datastream is -- at least as of this day and time -- more likely to attract attention from authorities than say, quality steganography or something like a carefully designed and well executed book code? Maybe the idea of pervasive surveillance and any resulting discomfort will raise interest in easy encryption among the general public, but given the state of the current crypto toolbox, I doubt it. I hope so too. The Tor datastream is easy to recognize amidst the sea of plain text connections. plugwith my plan, most connections are encrypted so those that need to rely on Tor have at least a better chance of hiding it. /plug Besides, with my protocol you really need Tor to protect your cryptographic identities against traffic analysis. Otherwise you're still fair game for the spooks. Guido. [1] my wares are found at http://eccentric-authentication.org/ [2] http://eccentric-authentication.org/blog/2013/06/07/run-it-yourself.html [3] http://dating.wtmnd.nl:10443/aliens (from within the proxied browser session). -- 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] Opt out of Prism
On 12-06-13 19:21, John Adams wrote: I like that you're promoting free and open tools, but your title is misleading. You offer people false hope here. By listing the tools and not listing what level of security they offer, people will assume they can just switch and be protected. This is one of the reasons why the EFF does not recommend tools. The issues associated with each tool are myriad and vast. What's sad is that the media picked up on this, amplifying the false hope you offer. A+ for effort, though. Although I can agree that many of these tools do not offer (significant) protection against unwanted data gathering. It's good that such a list comes to the attention of the people who are worried about their privacy. Even with false hope, a society without hope is doomed... I hope some people will take time to switch to some tools and spread that knowledge further. Guido. -- 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] Boundless Informant: the NSA's secret tool to track global surveillance data
On 11-06-13 12:21, Eugen Leitl wrote: On Mon, Jun 10, 2013 at 10:27:33PM +0200, Guido Witmond wrote: The big deal is that now it's become impossible to believe the lies, and that you [Americans] are forced to accept the truth. Reality check: https://twitter.com/_nothingtohide http://www.people-press.org/2013/06/10/majority-views-nsa-phone-tracking-as-acceptable-anti-terror-tactic/ No further questions, your honor. 1st step to recovery is denial... However, the question of Pew Research (in that second link) is not fair: Which is more important? A. Investigate terrorist threats; (or) B. Not intrude on privacy (of the general public) There is a third choice: C. Investigate terrorist threats AND not intrude on privacy (of the general public). We pay you people $X Billion dollars to do so. I tend to agree with Lauren Weinsteins opinion that it is rampant paranoia that lead us (the world) into this. http://lauren.vortex.com/archive/001044.html Realistically, we should be thankful for this brief flash of interest (already waning) and use it to reignite interest in stalled projects. I am very grateful for mr Snowden and Greenwald to leak this. Now it is ok for EU-commissioner mrv Viviane Reding to state that privavcy isn't a luxury but a right. Regards, Guido. PS: Check out the background picture on that twitter-page, sheep! -- 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] Boundless Informant: the NSA's secret tool to track global surveillance data
On 10-06-13 21:36, Jacob Appelbaum wrote: Maxim Kammerer: On Mon, Jun 10, 2013 at 12:01 PM, x zxhzh...@gmail.com wrote: Occam's razor would give us the following is what has actually happened in the past three days: a semi-clueless whistle blower fed an overzealous journalist a low-quality powerpoint deck, which met the privacy-paranoia and exploded. I agree. I also don't understand what's the big deal. The big deal is that now it's become impossible to believe the lies, and that you [Americans] are forced to accept the truth. And truth hurts! Especially when you want to believe the lies. Wanting to believe is easier than facing the truth, even when deep in your heart you've known the truth for a long time. Now is the time to come clear with your conscience, end this abusive relationship and kick the abusive partner out of your life. (ie: repeal the unjust laws.) Cheers, Guido. -- 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] Cell phone tracking
Dear mr Schoen, On 01-06-13 02:57, Seth David Schoen wrote: Arvind Narayanan has just pushed a two-part paper in _IEEE Security Privacy_ about exactly this point: http://randomwalker.info/publications/crypto-dream-part1.pdf http://randomwalker.info/publications/crypto-dream-part2.pdf Narayanan argues that a mis-alignment of incentives frequently occurs to discourage the use of cryptography to protect privacy (particularly in the strongest end-to-end sense) and that there is minimal demand for protecting data against intermediaries and service providers. (I find this paper extremely depressing, but it does describe actual events. If I were writing this paper, I would continue to ask how we can increase demand for cryptographic privacy mechanisms rather than declaring defeat.) I'm not so depressed by it. In fact the paper clearly outlines the problems and the way out. But there is the crypto-trap, it must be perfect or it is useless. It doesn't have to be that way. Here is a simple way to start. We won't start to solve the privacy problem. We attack other simpler problems with crypto. From there we can venture into more privacy. Here's how. With anonymous client certificates, we can solve the password problem when people sign up for an account. It eases the usability of websites (no more hassle with passwords or email addresses) and it makes site building easier as client side crypto is already part of every mature web server. By making it easier, time will come that passwords are considered more expensive than client certificates. The push comes from companies that need to pinch money. Once we've replaced password authentication, the same client certificates can be used to write authenticated messages. At first, it could be used by banks to communicate with their clients. By using client certificates as third-level authentication (in addition to pin-based TAN-generators) it can defeat most phishing attempts. Even if the customer falls for it and tries to log in at the phishers' site, the bank detects it and blocks the account. Here the demand for crypto comes from the financial pressure on banks to solve the phishing problem. The end user, although he has a privacy wish to protect him/herself against advertisement networks, doesn't have a clue on how to get that protection. He doesn't need it. He needs computers that do the protection for him. The system above to end the password problem and phising problem is aligned with the financial pressure. The things we need to get there are pointed out by Arvind Narayanan in his papers too: 1. We need completely automated key management, invisible to the user; 2. We need computers that are trustworthy. The good news, is: there is light at the end of the tunnel. I've been working on the first part with my eccentric-authentication 'protocol' [1]. It shows what we can do with anonymous client certificates. And there are plenty of people working on the trustworthy computers. Just like the drive to virtualisation on the server is a drive to compartmentalization, we see a rise of operating systems that bring that to client computers: genode.org, coyotos.org, qubes-os.org. Many more. With the high speed of replacement in the mobile and tablet markets, it offers opportunities that better not be wasted. * To pick up on Narayanan's argument, even if this kind of service is legal and even if carriers thought it was a reasonable service for them to offer, we might expect problems with demand for it. One problem for the level of demand for blinded e-cash payments for telecommunications services is that if users lose their mobile devices and don't have suitable backups, they lose all of their prepaid account value (because it existed only in the form of e-cash on the devices). To answer this with another current development: real time synchronization. Many people already use dropbox to synchronize their phone with their PC. Combine that with a fingerprint scanner (and pincode) at the phone to identify yourself to the phone and the loss/theft of the phone won't mean the loss of data nor e-cash. Respectfully, Guido Witmond [1]. http://eccentric-authentication.org/ -- 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] Microsoft Accesses Skype Chats
On 14-05-13 18:08, Julian Oliver wrote: ..on Tue, May 14, 2013 at 11:04:11AM -0500, Andrés Leopoldo Pacheco Sanfuentes wrote: I understand that the Skype traffic IS encrypted. The problem is that Skype itself (and now, Microsoft) holds the key, not the conversants.. Yes, this is correct. There's a good lesson here in encryption, key ownership and topology. Exactly what I'm trying to accomplish with [1]. 1: http://eccentric-authentication.org/ Guido. -- 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] BlackBerry and CALEA-II
On 04/29/2013 10:49 PM, Andrés Leopoldo Pacheco Sanfuentes wrote: Are there truly secure solutions? I don't think so.. especially not when we add the qualifier of mass consumption I'm not sure. But I've given it a try. I call it eccentric authentication. See [1], [2], [3]. In short: It uses client side certificates (with private keys). Each account at each site uses a different key and is a different identity. Each site signs the certificates for its own site *only*. It uses a First Party CA for that. That CA signs every request when the CommonName is still available. (that's important). But only that. By signing the site can recognise its customers based upon the certificate and private key. Customers can do more. They can sign blog entries at the site with their private key, creating an unforgeable identity amongst other site-users. I define a registry of (dis)honesty that keeps the sites and there CA's honest with respect to keeping the CommonName unique at their site. This is important. The protocol uses DNSSEC and DANE to distribute server keys. There can be only one First-Party CA for each domain name. These two make the CN@Sitename a global unique identifier, although completely pseudonymous. Use Tor to hide IP-addresses and become anonymous. With decoupling identities from message addressing we can have private, secure messaging between total strangers. The only thing they need to trust is their computer and software and the DNSSEC root key. Regards, Guido Witmond. [1] http://witmond.nl/eccentric-authentication/introduction.html [2] http://witmond.nl/blog/2012/10/22/announcing-eccentric-authentication.html [3] http://witmond.nl/blog/2012/10/22/the-worlds-most-private-dating-site.html -- 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] Explaining Different Types of Trust?
On 04/16/2013 03:25 AM, Nick M. Daly wrote: Hi folks, Apologies for abusing the word trust some more, but I don't know what other word to use. Feedback would be lovely. Sorry for the cross-post. Trust is earned, it can be given. It can never be forced. So, one of the goals folks worked out during FOSDEM was that each FreedomBox package should be able to explain to the user in a straightforward way (1) who the user is trusting, (2) for what purpose, (3) how that trust can be abused, and why such abuse would be bad for me (4). Explaining users is one of the six dumbest ideas in Marcus Ranum's list on computer security. For example, with DNS requests (2), I trust my router, my ISP, my DNS host (possibly Google, if I use 4.4.4.4), and (if I'm unlucky) anywhere in-between (1). Each of them can view the DNS requests I make and tamper with the responses (3), causing me to visit a fraudulent bank website, for example (4). They could also record these requests permanently (3) allowing them to track (4) and advertise (4) relative to my movements. Other harms based on that stored data are also imaginable, but perhaps too unlikely, in the average case, to be worth mentioning. The average user *expects* the systems to be secure and it will protect him. Bad things only happen to other people. Explaining the user all the parts that he is *required to trust* in order to get the security he expects is not going to help him. Instead, it's going to give *fear*. The only way he can use the system/network is to be in denial mode. The user will run away from the system that tries to help him be more secure (Freedombox) to a system that doesn't scare him (Windows/Mac/Google/Facebook). Scaring will make our user vulnerable to phishing scams that suggest to have a solution but instead gets him deeper into trouble. The DNS example above is a good example of all the parts that a user is *required* to trust. As you point out, the user is totally lost, security wise. So instead of educating the solution is to make things secure by default. It's what users expect of their computers, anyway. Our user expects his operating system and browser to validate all DNSSEC lookups. He expects a clear and easy to understanding error message when some validation fails. He wants a message stating. Sorry you cannot connect to example.bank because the security checks have failed. It's not secure! And don't give the user a button to override. From that security, our user can *gain trust* in the system to do his electronic banking safely, or to jabber with friends. Similar profiles can be drawn up for other services, such as Jabber, where an attacker can fake my buddy list and my buddies' conversations, and so forth. What are generic attacks that are service independent that would be widely useful here? I'm thinking: - Can Learn (Profile) To protect against profiling, there is only Tor. With regards, Guido. -- 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] Please Vote on Reply to Question
On 03/21/2013 05:33 PM, Trevor Timm wrote: Man, I really wish even if people are voting reply-all that you vote by just replying to Yosef. This is spamming everyone's in box with dozens of emails. Doesn't it prove the point of reply-to-poster? Guido. -- 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] Announcing a privacy preserving authentication protocol
On 03/21/2013 09:02 PM, Rich Kulawiec wrote: True, but phishing is not currently a solvable problem anyway; it falls into a class of problems that can't be solved no matter how much clever technology is developed because all of that technology presumes that end user systems are secure...and they're not. Sir, you are entirely correct. End user systems are insecure. That ship has left in 1980-1990 when everyone and their grandmother wanted a PC instead of an account on a managed main frame. We are suffering since. My protocol relies on the *assumption* that the end user system is secure. But it's ITs dirty little secret that *every* other protocol relies that the end user system is secure! - Passwords: no keylogger; - password manager: no malware; - encrypted password manager: no malware with sufficient patience; - crypto smart cards: no malware in the crypto layer; - TAN-generators for banks: I don't know if the transaction I'm authorising is the one that's displayed in my browser. One of my Dutch banks requires me to type in the amount in the tan-generator so the thieves are limited to that amount. A substantial percentage of end user systems are already compromised (in full or part) and more of them are being compromised while you're reading this. So unless this proposal or one like comes with a plan to remediate a few hundred million systems, it may be beautiful in theory, but it won't work in practice. Acceptance is the first step on the road to recovery. And I think the theory of my solution is more beautiful than the current ugly truth. If the only thing it gives is hope out of the current misery, I consider it a success. It may plant the seed for someone to change their current lousy operating system to something slightly more secure. That seed is what I want to plant. Please see: [1] on how a computer should behave towards its owner. In passing, let me note that banks and other financial institutions are aiding and abetting phishers by doing extremely stupid things like (a) sending email marked up with HTML (b) sending email with URLs (c) sending email with with web bugs (d) outsourcing their email. The irony is that while those entities are busy *training* their customers to be phished, they're constantly whining about how terribly awfully bad the situation is. There is insufficient scotch to dull the pain of that much stupid. Again, you're completely correct. With my protocol, that problem is out of the way when the banks and customers deploy it. But it's only a little step on the journey. The good thing, those who want can choose to use it. No need for the world to change. Regards, Guido. 1: http://witmond.nl/blog/2012/11/09/asimovs-laws-for-security.html -- 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] Announcing a privacy preserving authentication protocol
Thank you for your concerns, I think I have the issues you mention covered in the 'protocol' On 03/13/2013 12:31 AM, Kyle Maxwell wrote: I appreciate the intention, but I see a lot of problems here. Without doing an exhaustive analysis: A. This doesn't eliminate phishing because users will still enter their credentials at a site that doesn't actually match the one where the cert was previously signed. Otherwise, existing HTTPS controls would already protect them. Perhaps a bit unclear from my description is the fact that the User Agent handles all credentials. When the user browses to a site, the agent looks up the client certificates that are signed by the *same CA* as the one that signed the server certificate. Only the matching certificates will be offered to user to log in. A phisher may scare a person into browsing to the phisher's bank-look-alike, but the phisher cannot impersonate the certificates. The user agent sees it as a different site -- which it is -- and won't offer the certificates that the user has from his bank. This protocol is not meant be be used stand-alone to secure access to bank sites. When the user falls for the phishers, enters his username and password (at US-banks) or his token from his token generator (at EU-banks), the bank sees a correct log in coming from a different client certficate and *knows* something's fishy. The bank blocks the account. The user agent must not allow the user to pick a certificate that does not match. Doing so would lead to the current yes-clicking, because the user is really scared that the there is CUR 1500.- being deducted from his account. There is a small window of vulnerability here, when the user signs up for an Eccentric certificate at the first time. This must be solved at bank-account signup time. B. What zone would contain user keys for DNSSEC? I'm not sure what the question is. There are no user keys in DNSSEC, only the First Party Root certificates. That is stored according to the DANE/TLSA specification. ( http://datatracker.ietf.org/doc/draft-ietf-dane-protocol/ ) The way to retrieve client certificates by user name is unspecified. DNS could be a way. Or a well known url at the site. C. Your message transport protocol seems a little unclear - could you walk through it? In short, the site where a user has an account allows incoming 'blobs' from other people. These blobs would be messages, signed with the senders' private key and encrypted with the recipients' public key. The blobs include the certificate to prove ownership of the private key. The recipient (she) can decrypt the message and it gives her the public key of the sender (him). She validates senders' certificate against the Root certificate. She checks the global memory to check if there are not two or more certificates with the same common name. (that indicates a MitM from the senders' CA, or just an incompetent senders' CA). Notice, the recipient doesn't know the identity of the sender. To reply, she signs with her private key, encrypt with his public key and delivers it at the site specified by the Root certifcate of his certificate. Each site name is unique because it is specified in DNSSEC. Each client certificate has a unique name (protocol requirement) to make names unique for a site. Here two people can send encrypted messages without ever having to exchange keys beforehand. There are more issues here, but at a minimum I feel like it doesn't adequately address a broad enough threat model. I've designed it with these things in mind: - eliminate passwords; - eliminate email address requirements at account setup; - create anonymous accounts that are easier to set up than passwords, yet more secure against abuse. - use TLS everywhere - certificates are not forever. If a site requires an account to view it, create an account, view the site and delete the private key. Repeat for each visit. There are weak spots: - browsers handle certificates badly, very badly or not at all; - browsers make it difficult to use crypto-card, share keys over devices; - there is no protection against traffic analysis. Tor to the rescue. It's a bit longer than I expected but I hope it answers your questions. Please let me know if it raises more questions. with regards, Guido Witmond. -- 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] Announcing a privacy preserving authentication protocol
On 03/13/2013 08:33 AM, Petter Ericson wrote: Kyle: A. This doesn't eliminate phishing because users will still enter their credentials at a site that doesn't actually match the one where the cert was previously signed. Otherwise, existing HTTPS controls would already protect them. Not speaking for the protocol author, but afaict, the client cert is tied to the specific domain, meaning if you enter the wrong domain, you won't get a similar page where you enter your credentials - you'll get a page where you're not authenticated (the client cert is never sent to a different domain from where it was signed). Indeed, correct. The local CA root certificate is the *identity* of the site. The browser restricts accounts to the site. B. What zone would contain user keys for DNSSEC? I am not entirely sure what you are referring to here, but the server provides the (signed) user public keys to any who asks, no DNSSEC necessary. I am guessing a common API should be used for this (www.server.com/get-pubkey?uid=user or somesuch). That's how I foresee it now. It could be a DNS(SEC)-based directory. I'm not sure which way to go with that. Perhaps your WoT could help here. This does let the server MITM messages unless you have sidechannel pubkey verification, which is another reason why I find the message storage bit to be somewhat badly integrated. It does fit in badly. I foresee the messaging part to be used both for person-to-person messages like email but also to bootstrap other secure connections. For example, a dating site that lets people connect over ZRTP. The message could just contains the endpoints and keys for that session. See: [2]. XMPP might be a better fit. We'll see what happens though, but I'm at least somewhat hopeful. [1] though of course, a distributed/decentralised WoT-like construction for the complete DNS hierarchy may be preferrable overall It would reduce the risk of pressure on the registrars to block a site. The requirement for a replacement of DNSSEC/DANE needs a secure 1:1 mapping of human-readable name to FPCA-Root-certificate. With Regards, Guido Witmond. 2: http://witmond.nl/blog/2012/10/22/the-worlds-most-private-dating-site.html (warning: old text) -- 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
