[liberationtech] Request to test PassLok
I would like to invite the LiberationTech community to try PassLok, a free email encryption app based on NaCl and designed for ease of use, and report bugs or feature requests. PassLok is available as a web app at https://passlok.com/app, and also as extension/add-on for Chrome, Firefox, and their derivatives. A full listing of download links is at https://passlok.com. Since it is not based on PGP, PassLok is immune to the EFail attack reported recently. It can be used as a standalone app (PassLok Privacy), or integrated with the web versions of Gmail, Yahoo, and Outlook (PassLok for Email). PassLok is entirely client-based and does not require creating an account. Authentication is based solely of the user's secret password, which is not stored anywhere. If you wish to test PassLok by exchanging messages with me ( fruiz...@gmail.com), please follow the steps below. Thank you very much. The gibberish below contains a message from me that has been encrypted with PassLok for Email. To decrypt it, do this: 1. Install the PassLok for Email extension by following one of these links: Chrome: https://chrome.google.com/webstore/detail/passlok-for-email/ehakihemolfjgbbfhkbjgahppbhecclh Firefox: https://addons.mozilla.org/en-US/firefox/addon/passlok-for-email/ 2. Reload your email and get back to this message. 3. Click the PassLok logo above (orange key). You will be asked to supply a Password, which will not be stored or sent anywhere. You must remember the Password, but you can change it later if you want. 4. When asked whether to accept my new Password (which you don't know), go ahead and click OK. 5. If you don't use Chrome or Firefox, or don't want to install an extension, you can also open the message in PassLok Privacy, a standalone web app available from https://passlok.com/app --begin invitation message encrypted with PassLok== 327k7e5x30ntbfkkonLetazzy5Ldxc7tebexLp04ysnfv50ipg//gO6WlZNsojIs1vStZVOsdrJu matwm0Fxa29Y4BlpFleacH7FPiirmX7mO/hWhD4W3QewNu55Pq1jECnTwJTaLiYBNE4Ls4ULwA3aatrQ 2SK59dG1tIeijytuzGfRoAyJj2YZc3c+MISYIIozTHLQQk8eEmlXMJrgDl2zAugSZYnCPtBdLcSDNc/u /RHbrGu7ZlBlSAnfhE6rqMpk4P1iqNDkjkn5ESurjQMwlo0JOPCWlcf4/NpyDi9aRDDAcBBGIF6dN4Pk hkR+Zjzdp2PWm9iKZMkjTuyUuEEHb8JCwTChIzl/XBh2zi4oxxtJSj3jje/JOmThbgc3K/O/9+40aTTj cOvyf0heM5QSMRGVhAtp1tIrC4AONAor5tbp3UaWljOLHicCJqk8bLc47NEm6MqylMnLgwZ9QIHEcxzl DTJpmlisFRyf2VuOU7+rrlvtiajUx6icPXsqeP3D3Y9Qmtbd/150jsx4R+vWjvR3ncKaPpV7KC77J1Il eDZp2Zt0irY9BcV8B0Bgdf4moCe/yZBaJ0D2EeMBVsxyxr089zPYMT0dYCyBK7jIWpF1c3wacF/zIDf9 6JF/V6G+UI9rHIa8F4QYWuaH2V1mN/71WsjtcduL5B45kJw0fHabpsypY/N+j3DNLiijFwyibQe8JLUm RW/DPoUrhQuHJztDagjtJVv02syUy5H3gVOANkXU81nCLZWZxlRkI1Y1wFTVKpCUPkEygh8HWrVs/eL9 97hgmj2a4zZMATZIYv7YxMvCTFYfVgHG1kBwvMR7ZKd7GOTQG0kDbr7elgv4tP4oOOAOgHp0Y6owRPat 0vDYvFBqJ5x6Ni2t/GzyLzwp6h9zIfxGFvw3Z2Fl/0ir6ThgSZtSuAH5ndoK/JI8MwQpTNpq8j1xSJsQ RJtEe/pXH13lMq/eA5NYuGUHn8+1ZCaVvfQD9Z9GmAgsjnxe1znLRRe/OS0yvNQGYtav86mkrMAu+4qC LleoACEnvseMygUjJ6CW0OJ7xlLoUfTbjxeOaOZMPyjziEmaSFLZtNSkiXHSfNoyQZBsjj36MoE28ieM ADmJkW/PzF9e9z/Dn0tCFm+1pc6JHuOtiBn1JQQp36fA0STfUul8Qtd6eq7H4CK+l99saFY+oXPgse7m TdILnA ==-end invitation message encrypted with PassLok--- Once again, thank you! -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL23ezLok==327k7-e5x30-ntbfk-konLe-tazzy-5Ldxc-7tebe-xLp04-ysnfv-50ipg==PL23ezLok https:*//*www.*youtube*/watch?v=FFPG-UEotik -- 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 the moderator at zakwh...@stanford.edu.
[liberationtech] Announcing PassLok for Email beta
I am pleased to announce the open beta for PassLok for Email, a free Chrome extension that adds easy, secure end-to-end encryption to email services. Currently Gmail, Yahoo, and Outlook online are supported. You can get it from this private link: https://chrome.google.com/webstore/detail/passlok-for-email/ehakihemolfjgbbfhkbjgahppbhecclh PassLok for Email is based on the same crypto engine as PassLok Privacy, a free standalone app that can be found at https://passlok.com and other mirrors, plus the Chrome, Android, and iOS stores. This ensures compatibility with users outside the supported email services. We have worked hard to make PassLok for Email secure, powerful, and user-friendly. Some features: - Based on the NaCl crypto engine: 256-bit Xsalsa20 symmetric cipher plus Curve25519 ECDH asymmetric functions. - Written in JavaScript, BUT sandboxed as Chrome extension content scripts, out of reach for other extensions and the outside world. PassLok for Email interacts with the email services exclusively through DOM elements in the email page and makes no outside calls. - Key exchange is fully automated. Users never have to deal with private or public keys, which so many find hard to understand. This is possible because the public keys are very short (50 base36 characters), and can be added to every message without bloat. - PassLok for Email has no options to set or change. - A help page can be loaded as a separate tab with the click of a button. First-time users get special instructions on the interface. The technical document is linked from the help page (link below). - Choice between two kinds of encryption: Signed (stored messages can be decrypted later, as often as necessary), and Read-once (messages can be decrypted only once). Perfect forward secrecy in Read-once mode is achieved through ephemeral key pairs that are switched at every message sent or received. - Users can also create encrypted Chat Invitations which, when decrypted, start a real-time WebRTC chat session with participants directly connected to one another. The chat session can involve text, files, audio, and even video. - Encrypted attachments are supported, one per encrypted message. - Open source: https://github.com/fruiz500/passlok4email For under-the-hood details on how PassLok for Email is put together: https://passlok.com/files/passlok4email_technical_document.pdf If you like it enough to recommend to others to join the beta, go right ahead. PassLok for Email has a built-in method for spreading itself by means of Invitation messages. This email ends with my invitation, in case you want to establish an encrypted email conversation with me ( fruiz...@gmail.com). Please report bugs and submit feature requests at the project's GitHub page. Let’s work together to make this app the one where Johnny finally can encrypt ;-) Thank you. -- Francisco Ruiz Invitation created by PassLok for Email follows: -- The gibberish below contains a message from me that has been encrypted with *PassLok for Email*. To decrypt it, do this: 1. Install the PassLok for Email Chrome extension by following this link: https://chrome.google.com/webstore/detail/passlok-for-email/ehakihemolfjgbbfhkbjgahppbhecclh 2. Reload your email and get back to this message. 3. Click the *PassLok* logo above (orange key). You will be asked to supply a Password, which will not be stored or sent anywhere. You must remember the Password, but you can change it later if you want. 4. When asked whether to accept my new Password (which you don't know), go ahead and click *OK*. --begin invitation message encrypted with PassLok== 327k7e5x30ntbfkkonLetazzy5Ldxc7tebexLp04ysnfv50ipg@ppipK+rJrZi6A6YeEwe M%S5iVqKPTDK0j+AR2deQG/caYO1lczA7aTRd6iFLxPl5N+xeR/C6XCZFwUF+S8EQ+Dp9L GX4rIYy99IUfmzn2gF4FG3ITY6Vq+VyhDtZsWetdP3Eiikc77TmW66i9PHd0qjdIMcE2iQ mNduVa98uvi4HUawIf8OqzHCLGCH0gp6M9TSM7kYGhZ6TuTUPl/cyjJk/UyDEq/QWjtbx5 P3iYA2KVqoFhSyy76JwyxUOCYY72Su2lY9A8Dd/CxXi7AvrAsiCqG4hM1leQ6ICFGPP2sd RQPqzEaELF1Km89w ==-end invitation message encrypted with PassLok--- -- 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] Introducing SeeOnce
Hello LiberationTech subscribers, SeeOnce is a new web app that encrypts text and files with forward secrecy. This is achieved by changing keys with every message rather than using a server to store keys or encrypted material. SeeOnce consists of a single, relatively small html document, which doesn't connect to any servers. It is based on a javascript implementation of TweetNaCl, plus WiseHash, a dictionary-based key entropy meter that adds a variable number of scrypt key stretching rounds for weaker keys. Forward secrecy is obtained through a protocol similar to OTR messaging, except that communications are expected to be asynchronous. SeeOnce connects to the browser's default email through conventional mailto and web links, so users don't need to install anything. Removal of ephemeral data can be done via a single button. Another important goal is to make key exchange transparent to the user, so that even complete novices can use it right away. Please take a look at SeeOnce and give us any suggestions you might think appropriate. The preferred way is by starting Issues at the project's GitHub page at: https://github.com/fruiz500/SeeOnce The app is directly downloadable from https://seeonce.net. A Chrome app, able to synchronize its data through Google servers, is available at: https://chrome.google.com/webstore/detail/seeonce-privacy/jbcllagadcpaafoeknfklbenimcopnfc Thank you very much. -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL22ezLok=gqqjw-pq3eu-sgzpp-j87cn-fh7ik-6kvmn-comx2-b4xfn-gihga-s46e4=PL22ezLok h**ps://www 'dot' youtube 'dot' com/watch?v=UOJXI8E0lKY get the PassLok privacy app at: https://passlok.com <http://passlok.com> -- 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 voice options for china?
You may want to try a solution based on webRTC, which establishes a TLS-like communication directly between computers. There's vline.com and talky.io, but I'm not sure how secure they are at server level My own app, PassLok, does webRTC audio-only chat if that's what you want. The initiator makes an encrypted invitation that is sent by email (can be disguised inside a picture or as normal text, Chinese works fine), and then only those able to decrypt it are able to connect to each other from inside the app. PassLok is open source and available at several places, including passlok.com. On Thu, Feb 12, 2015 at 10:45 AM, Tim Libert wrote: > asking for a friend, can anybody suggest best ways to have a secure voice > conversation with persons located in mainland china from outside china? > threat model is interception by chinese authorities, other states/actors > are not of significant concern. email alone is insufficient for task. > > thanks. > > tim > -- > 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. > -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL21ezLok=1iw+0_y5xyh_66nby_u12x1_hmdw8_iioou_6yhud_a8/i9_jd4fj_fvv6i_swkrn_u773t_jb7yr_+d9nn_/b4h6_880py_vtf4L_o4zwr_6207u_v/bdd=354ad_7836e_52c1a_2cae9=PL21ezLok https://www.youtube.com/watch?v=A0LtNkM2RSs <https://www.youtube.com> get the PassLok privacy app at: https://passlok.com <http://passlok.com> -- 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] WebRTC security
I am in the process if adding WebRTC capabilities to my PassLok privacy app. In its current incarnation, PassLok's public key functions are used to generate an encrypted "chat invite" that only the intended recipients would be able to decrypt. Once decrypted, the invite contains the URL of a simple WebRTC webpage (based on Muaz Khan's demos on Github), including a 256-bit token generated by a cryptographically secure RNG. Users then start or join a WebRTC session, with signaling facilitated by Firebase and XirSys, with no further involvement of PassLok other than providing an iframe for the WebRTC to run. But I have some doubts about the security of this scheme: 1. In order to find each other, participants contact Firebase.io so their external IP numbers can be relayed back to them. There is also a connection via XirSys with pretty much the same goal. I don't understand WebRTC (or Muaz Khan's implementation of it) to understand precisely what is sent back and forth, but it seems that the connection with these servers is only needed in order to get around firewalls, and after the connection is established they are out of the loop. Still, it bothers me that any kind of servers must be involved to initiate each connection, since they might leak some information about the clients that might enable malicious listeners to obtain credentials that would enable them to establish unwanted connections. 2. Once a connection starts, it seems that the browser (Firefox, Chrome, Opera) deals with it very much as if a TLS connection had been established with a server, except that it is between clients. I wonder if this kind of connection can be trusted to be secure enough, though. 3. A third worry is about the scheme I'm using to ensure that the chatroom is indeed private, which is to add a random token to the chat URL itself. That URL is never displayed in my program, but I am wondering if it needs to be relayed to the signaling server in order to establish a WebRTC connection, in which case it might be compromised. Any help will be appreciated. Thanks! -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL20ezLok=1y2z7_6qg8r_wqv3n_7886/_tj4i1_11i3w_x92wj_2p6e1_co32z_uxz0t_qLrqh_fgz++_2km/d_k6bg/_2t3q9_75xjj_w581g_bfpzx_bjxde_jnd0j=PL20ezLok https://www.youtube.com/watch?v=YnPCfP7uPpw <https://www.youtube.com> get the PassLok privacy app at: https://passlok.com <http://passlok.com> -- 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] scrambler
Hi Michael, I see from the Amazon link that your software is 70k in size. Is that correct? If so, my guess is that your "one-time pads" are actually lists of pseudo-random numbers (or letters, in your examples) generated by the java program. Those are not true one-time pads. Real one-time pads are generated by a true random process, such as radioactive decay (or children playing ;-). The best you can do with a java program and a computer is generate pseudo-random lists. Then, unless you send the recipient the seed of your pseudo-random generator, which would become the key, and not a good one, you'd have to send the pseudo-random files by some secure channel, ahead of the encrypted messages. I'm sure there'll be experts who'd be willing to look at your code and give you some feedback, but not if they have to pay $20 for the privilege. On Thu, Aug 29, 2013 at 2:15 PM, Michael Hicks < scramblerencrypt...@yahoo.com> wrote: > ok so I guess I just send u guys the links and u check out my software and > Vet it? This was made for people to be able to protect their privacy and > the NSA can't hack it No One can it's impossible. all the information is at > scrambler.webs.com > > > -- > Liberationtech is a public list whose archives are searchable on Google. > Violations of list guidelines will get you moderated: > https://mailman.stanford.edu/mailman/listinfo/liberationtech. > Unsubscribe, change to digest, or change password by emailing moderator at > compa...@stanford.edu. > -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL13lok=WsH3zTgZn8V3hnIqjdbfPus+5YF5n+LBRPuH9USMMp8izPv+hsLoZKv+jaCFMapJFfiA11Q9yJU1K1Wo0TbjXK/=PL13lok get the PassLok privacy app at: http://passlok.com -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] SMS questions
You may want to take a look at PassLok, which has a special SMS mode to create encrypted messages that are exactly 160 characters long. I just made a more secure source server at: https://www.autistici.org/passlok. There is also a GitHub page at: https://github.com/fruiz500/passlok Since autistici.org is self-certified, you will get a warning. Then you'll have to decide whether your trust them or not, and whether you want to add their certificate. If you decide to test PassLok, please inspect the source code before you execute it. PassLok works completely client-side and does not connect to any servers or apps. Its output is encrypted base64 text, which you can copy and paste into SMS if you like. Be aware, however, that an intercepted SMS will look like what it is: encrypted stuff. If reprisals could come just from using encryption, then don't use PassLok. You should also be aware that other users of libTech believe that PassLok, like every app written in javascript, is inherently insecure. I believe that the same could be said of any compiled code, for that matter, but that's a different debate. I'm available for technical support if you need it. On Tue, Aug 27, 2013 at 11:36 AM, Richard Brooks wrote: > I have colleagues living in a small country, far, far > away with a history of rigged elections who want to > put in place a system for collecting information > using SMS. The local government keeps shutting > down the systems that they put in place. > > I think I understand their needs and wants. SMS is > really not my strong point. If anyone with an understanding > of SMS, SMS web interfaces, and/or related security issues > would be willing to point me in the right direction > (or discuss potential issues) I (and by extension > they) would be grateful. > > The alternative is for me to dedicate my excess cycles > to researching those issues from scratch, which sounds > time consuming. They kind of need help in the near future. > > -Richard > -- > 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. > -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL13lok=WsH3zTgZn8V3hnIqjdbfPus+5YF5n+LBRPuH9USMMp8izPv+hsLoZKv+jaCFMapJFfiA11Q9yJU1K1Wo0TbjXK/=PL13lok get the PassLok privacy app at: http://passlok.com -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Standalone JS apps vs. browser extensions, which is better?
Steve Weis wrote: >If delivered as a regular Javascript web app, then Francisco, anyone >at Site 44, or anyone at Dropbox can steal PassLok keys and messages >anytime they want. You're absolutely right. I don't feel good about this. But what if I set up my own server? I can do it here at the university. Otherwise, is there a https shared served that one can trust? On Mon, Aug 26, 2013 at 2:34 PM, Steve Weis wrote: > If delivered as a regular Javascript web app, then Francisco, anyone > at Site 44, or anyone at Dropbox can steal PassLok keys and messages > anytime they want. > > I do not think it's realistic to expect every single user to "look at > the code before [they] execute it" for every single page load. As > already discussed, Francisco's method of hashing the Javascript code > doesn't work across different browsers and encodings. Even if it > worked, users would need a client-side tool to verify it, which means > it is no longer browser-based. > > On Mon, Aug 26, 2013 at 11:44 AM, Francisco Ruiz wrote: > > > > So, I'm inclining toward keeping PassLok as a securely delivered, but > strictly self-contained web app. At least this way you can look at the code > before you execute it. > -- > 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. > -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL13lok=WsH3zTgZn8V3hnIqjdbfPus+5YF5n+LBRPuH9USMMp8izPv+hsLoZKv+jaCFMapJFfiA11Q9yJU1K1Wo0TbjXK/=PL13lok get the PassLok privacy app at: http://passlok.com -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Standalone JS apps vs. browser extensions, which is better?
Thanks, Griffin, Eduardo, I haven't gotten a lot of response to this issue, but I've been doing my own thinking, after some more testing of extensions similar to what I want. Here's by $0.01 worth: Extensions are cool, but those I've seen have these huge problems for my application (and probably any application where extreme portability is needed: 1. They don't follow you from machine to machine, even if, say, you log in with your Google ID. You must install them in each machine one by one. 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. 3. The code is hidden from view, so if an adversary changes it (by hacking into Google or by convincing them that it is of overriding national security interest), the user is kept in the dark. Me, the developer, is in the dark, too. So, I'm inclining toward keeping PassLok as a securely delivered, but strictly self-contained web app. At least this way you can look at the code before you execute it. Thanks! for all the feedback! On Sat, Aug 24, 2013 at 4:47 PM, Griffin Boyce wrote: > On 08/24/2013 05:13 PM, Francisco Ruiz wrote: > > > > My encryption app, PassLok, is currently in the shape of a standalone, > > static web page with two text boxes where users copy and paste plain > > or encrypted messages. I am considering the possibility of making a > > browser extension version out of it, probably along the lines of > > myMail-crypt or Mailvelope for Chrome, to provide a tighter > > integration with email programs (or at least with Gmail, which is very > > popular these days). > > > > I suspect you're going to get lots of different answers to this > question, but here is how I see it: > > Offering a browser extension or downloadable application is far > superior to having it in website format, because you can offer GPG > signatures and the user doesn't have to worry that you've been forced to > change the code server-side (or that they've got network interference). > > You shouldn't be storing collections of passwords on your server, in > any format, ever. This is just begging for trouble, either from hackers, > broken servers, or government agencies. > > Release your app as a proper downloaded app. Allow people to save > their passwords locally. And have someone help you with threat > modeling. It doesn't prevent all problems, but it turns a huge problem > into a few small problems, and puts much of the burden back onto the > user to secure their computer and local network. > > Just my $0.02 > > best, > Griffin > > -- > "Cypherpunks write code not flame wars." --Jurre van Bergen > #Foucault / PGP: 0xAE792C97 / OTR: sa...@jabber.ccc.de > > My posts, while frequently amusing, are not representative of the thoughts > of my employer. > > -- > Liberationtech is a public list whose archives are searchable on Google. > Violations of list guidelines will get you moderated: > https://mailman.stanford.edu/mailman/listinfo/liberationtech. > Unsubscribe, change to digest, or change password by emailing moderator at > compa...@stanford.edu. > -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL13lok=WsH3zTgZn8V3hnIqjdbfPus+5YF5n+LBRPuH9USMMp8izPv+hsLoZKv+jaCFMapJFfiA11Q9yJU1K1Wo0TbjXK/=PL13lok get the PassLok privacy app at: http://passlok.com -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
[liberationtech] Standalone JS apps vs. browser extensions, which is better?
My encryption app, PassLok, is currently in the shape of a standalone, static web page with two text boxes where users copy and paste plain or encrypted messages. I am considering the possibility of making a browser extension version out of it, probably along the lines of myMail-crypt or Mailvelope for Chrome, to provide a tighter integration with email programs (or at least with Gmail, which is very popular these days). But let me frame this as a general issue, since I am sure there are other developers who are wondering if browser extensions are the way to go. They tend to make things easier for the user, but at some cost. I’d like to know more exactly what is the trade-off. There is a lot going for making an extension that ties with a web mail service. For instance: 1. 1. Users would be able to store their contacts’ public keys within the app, so the extension would fetch them automatically once recipients’ emails are typed. 2. 2. Extensions, I am told, can be better protected from tampering by an enemy than a simple web page, even if that page travels by TLS/SSL. On the other hand: 1. 1. Users would be forced to trust me, the developer, concerning the security of the extension, while right now they can look at the code and decide for themselves if they want to use it. 2. 2. The extension could be broken by Google changing things in Chrome or Gmail, which would force me to be constantly updating it. 3. 3. In the examples I mentioned above, public keys are stored locally in the computer, which would break the principle of perfect portability that PassLok is based on. This would not be so much of a problem if the keys could be stored in the Cloud, but I haven’t seen an example that does it satisfactorily. 4. 4. There’s also the issue that Google does no longer have a clean nose concerning cooperation with spy agencies (with or without judicial warrants), so they could change my code and weaken the extension without my knowledge. 5. 5. Browser extensions don’t yet run on mobile devices, again against one of PassLok’s design principles. What do you think? Given the state of affairs these days, with some secure mail services compromised and others shutting down because of the threat of government interference, is it still worthwhile to invest the effort in developing an extension in order to streamline user experience? Thanks! -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL13lok=WsH3zTgZn8V3hnIqjdbfPus+5YF5n+LBRPuH9USMMp8izPv+hsLoZKv+jaCFMapJFfiA11Q9yJU1K1Wo0TbjXK/=PL13lok get the PassLok privacy app at: http://passlok.com -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] [Dewayne-Net] Are Hackers the Next Bogeyman Used to Scare Americans Into Giving Up More Rights?
Kyle, Government is always "the good guys" by definition, here and in Zimbabwue, especially in their literature. The line separating "sedition" from "civil disobedience" is usually drawn after the fact. On Thu, Aug 15, 2013 at 1:09 PM, Kyle Maxwell wrote: > On Wed, Aug 14, 2013 at 5:18 PM, Bernard Tyers - ei8fdb > wrote: > > My issue is with - "Hacking" is bad when people do it. It's ok when the > government do it. > > To play devil's advocate for a moment: isn't that true for a lot of > things? The State is, in general, very jealous about its monopoly on > things like violence and taxation, and (modulo anarchists, many of > whom I love and respect) the majority of people are okay with those > things. > > -- > @kylemaxwell > -- > Liberationtech is a public list whose archives are searchable on Google. > Violations of list guidelines will get you moderated: > https://mailman.stanford.edu/mailman/listinfo/liberationtech. > Unsubscribe, change to digest, or change password by emailing moderator at > compa...@stanford.edu. > -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL13lok=WsH3zTgZn8V3hnIqjdbfPus+5YF5n+LBRPuH9USMMp8izPv+hsLoZKv+jaCFMapJFfiA11Q9yJU1K1Wo0TbjXK/=PL13lok get the PassLok privacy app at: http://passlok.com -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Can JavaScript cryptography be trusted? (was: In defense of client-side encryption)
Hi Nadim, I read your article for the second time. I'm totally with you. Javascript is code, and therefore it is intrinsically neither more nor less secure than compiled code running on the OS. Sure, one needs to trust that the browser isn't doing funny things, but we need the same kind of trust when we run compiled code on an OS (usually developed by people who sit in the next cubicle from the browser people). I don't see why an OS deserves implicit trust and a browser doesn't. Unlike compiled code, javascript can be read by humans. Most people won't bother, but there are a few who will, and they'll report their findings on this mail list if they find something amiss. I'm experiencing that right now with my own PassLok web app. If I had compiled it, people would have to trust my commercial jabber, as they seem to do for server-side applications, but they wouldn't really know how good the app was until after extensive testing. Right now I'm wrestling with the issue of code authentication. The page is static and gets delivered by https, but what if someone manages to hack the server? My current solution is to publish the SHA256 of the source in the help page accompanying the code page. For added security, I post a youtube video of yours truly reading that hash (I'm trying to get Justin Bieber to do it for me, but no luck so far ;-). Problems so far: 1. Most people don't know how to take the SHA256 of a page that comes to their browser. If they succeed at viewing the source, there is a high chance that they'll save it to file with the wrong encoding, so the hash verification will fail. 2. Even if my face (or Justin Bieber's face) is familiar to them, they know a video can be faked. I'm trying to make it harder by playing background music so it's not easy to chop up the video (with sound) and rearrange it so they hear me reading a counterfeit hash, but certainly there are experts out there who can get around that. Now, nobody seems to be requiring this level of assurance from compiled code. You post a hash on your own website, and most people trust it. You add some CA's signature, and apparently you can go to the bank with that. Maybe I should just append to my code a comment containing someone's signature and forget about the rest. On Tue, Aug 13, 2013 at 2:09 AM, Nadim Kobeissi wrote: > Quickly adding my blog post on the matter to this thread. Would love to > hear discussion regarding it: > > http://log.nadim.cc/?p=33 > > NK > > On 2013-08-13, at 1:58 AM, Tony Arcieri wrote: > > > On Mon, Aug 12, 2013 at 3:07 PM, Ali-Reza Anghaie > wrote: > > I'm sorry but aren't we spending a lot of time conflating code > > quality, secure coding practices, software distribution, .. with > > ~JavaScript in a browser~? > > > > I think the title of the thread has a lot to do with that. Fixed! ;) > > > > -- > > Tony Arcieri > > -- > > Liberationtech is a public list whose archives are searchable on Google. > Violations of list guidelines will get you moderated: > https://mailman.stanford.edu/mailman/listinfo/liberationtech. > Unsubscribe, change to digest, or change password by emailing moderator at > compa...@stanford.edu. > > > -- > Liberationtech is a public list whose archives are searchable on Google. > Violations of list guidelines will get you moderated: > https://mailman.stanford.edu/mailman/listinfo/liberationtech. > Unsubscribe, change to digest, or change password by emailing moderator at > compa...@stanford.edu. > -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL13lok=WsH3zTgZn8V3hnIqjdbfPus+5YF5n+LBRPuH9USMMp8izPv+hsLoZKv+jaCFMapJFfiA11Q9yJU1K1Wo0TbjXK/=PL13lok get the PassLok privacy app at: http://passlok.com -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Passlok's broken security model
Hi Steve,
Some answers inline below, and thanks for taking all this time to help me.
> I changed my browser's default encoding. That changes the charset in the
> html tag, as well as some characters in the body. I tried UTF-8, Arabic,
> and Chinese encodings and they all saved with slightly different data,
> which will all fail to verify with your single hash value.
>
> Chrome ships with like 30 different supported encodings and each browser
> may handle this differently, so there are many potential hash values from
> your page.
>
So I guess I'd better leave it as UTF-8, which hopefully covers a lot of
users.
>
> I've spent a lot of time making the code run nice and polishing the user
>> interface. I didn't suspect code validation was going to be this difficult.
>> Truth is, most users are never going to bother with validating the code,
>> but a few will care intensely about this.
>>
>
> If users have to trust the code that is served every time they visit
> Passlok, then users have to trust you and your hosting provider Site44
> entirely. If Site44 were compromised or subpoenaed, you may not even know
> about it.
>
>
I guess not, but I'm only using site44 for the time being because it's
free. I'm also changing the code with some frequency. In a more final
installation, I'll have my own server. Perhaps you can recommend a shared
https server that can be trusted?
> You suggested users download the Passlok page, validate it themselves, and
> run their local copy. Now you say that nobody is going to bother, which
> means we're back to the security model of trusting you and your hosting
> provider entirely.
>
Most people aren't going to bother. Correct me if I'm wrong. For them, all
I can do is deliver the code with the greatest possible security. I guess
that means https or one of the fancier methods that some folks at libtech
are recommending, plus a server that won't be hacked/coerced easily.
The whole validation rigmarole is for those relatively few who might not be
so sure that SSL was secure and the server had not problems. Maybe they
want to save their copy of the code in a safe place of their choosing.
>
>
>> Ah, you saw that. It's the elliptic curve output. SJCL handles points and
>> exponents as complex recursive objects. In order to display them for the
>> user, I extract the data and convert it into base64. For reasons that I
>> don't fully understand (probably having to do with 521, the true bit length
>> of the elliptic curve numbers, not being divisible by 6), those strings
>> always start with "A". Since I intensely dislike displaying supposedly
>> random-looking strings that always begin with the same character, I strip
>> it, but instruct the functions that read those strings from the interface
>> to add it again before they do any calculations.
>>
>
> You admit you don't understanding what's going on with the encoding, but
> decided to intentionally corrupt an encoded key value because you didn't
> like a string looking non-random? The consequence is that you added
> unnecessary code complexity to fix the key value every time you want to use
> it.
>
I think "corrupt" is a bit strong of a word. The SJCL ECC routines always
spit out an "A" at the start of those base64 strings, perhaps because it is
not really a part of the number represented by the string but an artifact
caused by the encoding they use. If I had written those routines, they
wouldn't be doing that, but I chose to use well-known code so the combined
source is easier to audit.
Perhaps it would have been more "honest" to let that initial "A" be
displayed for the user to see, but in the end I thought it would be raising
unnecessary concerns ("what!, wasn't this supposed to be random?") and took
it out of the displayed strings, and put it back whenever it is needed,
before doing any calculation. All of this is amply documented by comments
in the source code.
>
> Did you change any other part of the crypto implementation based on
> aesthetics?
>
>
That's it for aesthetics. The crypto primaries aren't really affected, only
the display on the screen. There's a lot of aesthetic considerations on the
UI itself, since I wanted it to look good without any graphics, both on
mobile and PC.
Thanks for all your attention, Steve.
> --
> 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
Hi Steve. I want to thank you for taking your time to help me. Your comments are awesome. May I follow up with some short questions, right after some of your comments? Many thanks in advance. On Mon, Aug 12, 2013 at 7:18 PM, Steve Weis wrote: > Francisco, you assume that all browsers will save a static version of the > page identically. This is not the case. > > I ran a test using 'wget https://passlok.site44.com' and Chrome's "Save > As". The former will actually match the hash value you've posted, but the > latter does not. > > I spotted at least 5 differences in Chrome's saved output: > 1. Unicode: wget returned escaped Unicode characters. Chrome saved output > containing actual Unicode characters. Your suggested method of cutting from > view-source and pasting into a text editor may be unpredictable, and > dependent on a user's OS and locale. > I think the Unicode characters got in when I added the qr.js code, which had comments in Korean ;-) Do you think it's maybe best to get rid of anything that is not strict ASCII? The code doesn't need any special characters. > 2. Relative link re-writing: wget returned relative links. Chrome replaced > them with absolute links, so that links work locally. > I've toyed with the idea of making absolute the couple relative links in there: the png for making a mobil icon, and the help page. Maybe it's better if they are absolute so the browser doesn't change them, uh? > 3. Whitespace: Chrome stripped out some whitespace. > I've tried to make super-sure that the code has no leading and no trailing spaces or linefeeds, so maybe wget is adding spaces? 4. Style rewriting: Chrome replaced some style elements like > "background-color: #FFA0A0" with "rgb(230, 255, 230);". > 5. Chrome extensions: I have locally installed extensions that modify page > contents, e.g. AdBlock and DoNotTrackMe. My locally saved copy of Passlok > had elements that were injected into it by some extensions. > > Any of these will break your manual hash validation. These are specific to > my version of Chrome, but other browsers may alter saved content similarly. > I've spent a lot of time making the code run nice and polishing the user interface. I didn't suspect code validation was going to be this difficult. Truth is, most users are never going to bother with validating the code, but a few will care intensely about this. > > To work, you must assume that your user has a local client (say wget or > curl) that can save a canonical copy of your page without modification. > Browsers do not guarantee this. Then you must assume the user has a locally > installed tool to compute the hash, like sha256sum or openssl. Then they > would need to point their browser at the locally downloaded file to > actually use it. > > If you depend on locally installed software outside the browser and use > local storage, the user is better off just using locally installed software > to do the crypto. > > PS - I noticed some oddness glancing through the source. For example, the > makepub() function strips 6 bits of a Base64-encoded leading 0 for no > apparent reason. The rest of the code has to remember to keep adding back > in the missing Base64 character or else it will break. The only reason I > can think of someone doing this is because they didn't understand why the > randomly generated Base64 value always started with 'A'. > Ah, you saw that. It's the elliptic curve output. SJCL handles points and exponents as complex recursive objects. In order to display them for the user, I extract the data and convert it into base64. For reasons that I don't fully understand (probably having to do with 521, the true bit length of the elliptic curve numbers, not being divisible by 6), those strings always start with "A". Since I intensely dislike displaying supposedly random-looking strings that always begin with the same character, I strip it, but instruct the functions that read those strings from the interface to add it again before they do any calculations. Thanks again, Steve! > > On Sun, Aug 11, 2013 at 7:37 PM, Francisco Ruiz wrote: > >> I still have to read through the references you supply, but I can already >> see a misconception. They refer to the dangers of carrying out cryptography >> with javascript-containing dynamic pages. My previous posting referred to >> _perfectly static_ pages, which are supposed to be always the same coming >> from the server, not modified by the browser in any way, and which, in >> fact, you can save and store somewhere safe and never again have to get >> from the server. I believe the intrinsic security of this kind of >> javascript code is no dif
Re: [liberationtech] Does anyone know a celebrity who feels strongly about privacy issues?
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? Many thanks. On Mon, Aug 12, 2013 at 4:34 PM, Guido Witmond 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. > > 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. > -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL13lok=WsH3zTgZn8V3hnIqjdbfPus+5YF5n+LBRPuH9USMMp8izPv+hsLoZKv+jaCFMapJFfiA11Q9yJU1K1Wo0TbjXK/=PL13lok get the PassLok privacy app at: http://passlok.com -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Does anyone know a celebrity who feels strongly about privacy issues?
Hi Kyle, don't take it so hard. I asked this question so _everybody_ who'd like to try the celebrity video trick would be able to collect a few likely candidates. Likely others will beat me to it. On Mon, Aug 12, 2013 at 7:29 PM, Kyle Maxwell wrote: > I didn't know LibTech had become the PassLok development mailing list. > > On Mon, Aug 12, 2013 at 6:26 PM, Collin Anderson > wrote: > > The problem with occasionally looking at Huffington Post is that I'm > > subjected to such things... > > > > Matt Damon: > > > > "He broke up with me," the "Elysium" star said. "There are a lot of > things > > that I really question, you know: the legality of the drone strikes, and > > these NSA revelations they’re, you know, it’s like, they’re, you know, > Jimmy > > Carter came out and said we don’t live in a democracy. That’s, that’s a > > little, that’s a little intense when an ex-president says that. So, you > > know, he’s got some, some explaining to do, particularly for a > > constitutional law professor." > > > > > > > http://www.huffingtonpost.com/2013/08/09/matt-damon-obama-broke-up-with-me_n_3732426.html?utm_hp_ref=entertainment > > > > > > On Mon, Aug 12, 2013 at 11:44 PM, Yishay Mor wrote: > >> > >> Cory Doctorow > >> > >> - sent from my phone. > >> > >> On Aug 12, 2013 9:33 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. > >>> > >>> Aside from the fact that an adversary might be able to convince Justin > >>> Bieber to make a video reading a fake hash (not that I believe Justin > >>> doesn't care; it's just a hypothesis), the idea of getting a celebrity > for > >>> this kind of video has a lot of merit. I'd like to engage one for the > next > >>> update of my app. > >>> > >>> 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! > >>> > >>> -- > >>> Francisco Ruiz > >>> Associate Professor > >>> MMAE department > >>> Illinois Institute of Technology > >>> > >>> > >>> > PL13lok=WsH3zTgZn8V3hnIqjdbfPus+5YF5n+LBRPuH9USMMp8izPv+hsLoZKv+jaCFMapJFfiA11Q9yJU1K1Wo0TbjXK/=PL13lok > >>> > >>> get the PassLok privacy app at: http://passlok.com > >>> > >>> -- > >>> Liberationtech is a public list whose archives are searchable on > Google. > >>> Violations of list guidelines will get you moderated: > >>> https://mailman.stanford.edu/mailman/listinfo/liberationtech. > Unsubscribe, > >>> change to digest, or change password by emailing moderator at > >>> compa...@stanford.edu. > >> > >> > >> -- > >> 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. > > > > > > > > > > -- > > Collin David Anderson > > averysmallbird.com | @cda | Washington, D.C. > > > > -- > > Liberationtech is a public list whose archives are searchable on Google. > > Violations of list guidelines will get you moderated: > > https://mailman.stanford.edu/mailman/listinfo/liberationtech. > Unsubscribe, > > change to digest, or change password by emailing moderator at > > compa...@stanford.edu. > > > > -- > @kylemaxwell > -- > Liberationtech is a public list whose archives are searchable on Google. > Violations of list guidelines will get you moderated: > https://mailman.stanford.edu/mailman/listinfo/liberationtech. > Unsubscribe, change to digest, or change password by emailing moderator at > compa...@stanford.edu. > -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL13lok=WsH3zTgZn8V3hnIqjdbfPus+5YF5n+LBRPuH9USMMp8izPv+hsLoZKv+jaCFMapJFfiA11Q9yJU1K1Wo0TbjXK/=PL13lok get the PassLok privacy app at: http://passlok.com -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
[liberationtech] Does anyone know a celebrity who feels strongly about privacy issues?
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. Aside from the fact that an adversary might be able to convince Justin Bieber to make a video reading a fake hash (not that I believe Justin doesn't care; it's just a hypothesis), the idea of getting a celebrity for this kind of video has a lot of merit. I'd like to engage one for the next update of my app. 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! -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL13lok=WsH3zTgZn8V3hnIqjdbfPus+5YF5n+LBRPuH9USMMp8izPv+hsLoZKv+jaCFMapJFfiA11Q9yJU1K1Wo0TbjXK/=PL13lok get the PassLok privacy app at: http://passlok.com -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] In defense of client-side encryption
Hey Arjen, you make a huge point. Unfortunately the Netherlands aren't any better this way, are they? Looking around, it seems the only "safe" place for a crypto server these days would be Switzerland. I'm ready to move my stuff over there. Does anybody know of a good, cheap, SSL-enabled web host in Switzerland you can recommend? Gendo, maybe? Thanks! On Mon, Aug 12, 2013 at 6:46 AM, Arjen Kamphuis wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 08/11/2013 08:10 PM, Francisco Ruiz wrote: > > 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. > > For the 95.5% of humans on the planet that are not US citizens the > above statement is at best a belly-laugh, at worst a very sick joke. > > The US government is not restrained by law (of any kind) to do > whatever the hell it pleases (or pleases its financiers). The families > of 1.5 million dead Iraqi's will back me up on that statement. You did > notice that nobody went to jail for that? I mean; you did *notice* > that? Because the rest of the planet sure did. > > To trust *anything* to be 'protected' by US 'law' after the last > decade is a denial of reality that borders on psychosis. > > I still believe there are some places in Europe where things are a > little better (= sliding slower) but I may be wrong about that ;-) > > Client-side encryption means a Free Software code stack running on a > machine that is physically under your control at all time. Anything > else is BS. > > > - -- > Met vriendelijke groet/With kind regards, > Arjen Kamphuis > Gendo B.V. > > Main: +31 20 891 0330 > mail: ar...@gendo.ch > > gendo.ch(website) > gendo.nl/blog/arjen (Dutch blog) > gendo.ch/en/blog/arjen (English blog) > > about.me/arjenkamphuis (social media) > > files.gendo.nl/keys/ar...@gendo.ch.asc (public key) > PGP fingerprint: > 55FB B3B7 949D ABF5 F31B BA1D 237D 4C50 118A 0EC2 > > Gendo BV Wibautstraat 150, 1091 GR Amsterdam The Netherlands > P please consider the environment before printing this email > > This e-mail message and its attachments are subject to the disclaimer > published at the following website of Gendo: > http://www.gendo.nl/disclaimer Gendo B.V. is registered with the trade > register in The Netherlands under number 28116864. > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with undefined - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJSCMsSAAoJECN9TFARig7ChAwP/j3Ls2HTOBFFnpWC93OXAsB7 > +KRWr5sUDGc7HkG6Ui1U4TNeluSmeeglkfn1BFd/aQlM+LgbP8vjsXI+6+ZevzSN > WysbzgKXVXa4YJlEOtGvjlaRYKxIW6tH/yQc8XOM9dE8LlZ6kgmznMiT9qbwfI7o > eW5nwQuznx+Lp2yahu6/j0xqi4RazEGp0qYa1As7WSCxdD5tncZ3SMhceQ7V4rpK > o5ovqzztvg4IY7axlAX5eid4KGqBJenanWu79eSsHV2QBSW4gzB3tmuBeLuJcLz8 > 8FIIPbYFJxa1zK56MA+ZzZa2EZ0ALtRaWKroS+BWC9pDKdM4FmCer++UdBy9n1gT > 9yzw51T2ZOfxoQo7y4FshZjK3/lDaAAbp+HItkcwwx6F18XPTWT+4u70ARpmuuGM > SH7ZRBeutMLd7wcePEaDU6RvpdvF1xf7+1posJJeeBrEIWaY5j5ZFzpGEHVjjp5n > 03d5VLtArvn2Kcx7ymX1+ZtQoEPpobtNdCTA0N7vUMcKmdLDfsA+YX7Zw2jxVpcI > Nk9GJ6HkCTLth7dxpVmz2Iv/o3Chq91X+FXjLTy8titwYrK0UPnwlqd35PApl77C > w36eGIcmadWg1eEYEzpF9UicyzBnLmpQFM2Qm9aJanDRHziUL3YsFLxlHfFXs462 > CQZlJf1tbCRvS8UTPRnC > =wwxV > -END PGP SIGNATURE- > -- > Liberationtech is a public list whose archives are searchable on Google. > Violations of list guidelines will get you moderated: > https://mailman.stanford.edu/mailman/listinfo/liberationtech. > Unsubscribe, change to digest, or change password by emailing moderator at > compa...@stanford.edu. > -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL13lok=WsH3zTgZn8V3hnIqjdbfPus+5YF5n+LBRPuH9USMMp8izPv+hsLoZKv+jaCFMapJFfiA11Q9yJU1K1Wo0TbjXK/=PL13lok get the PassLok privacy app at: http://passlok.com -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] In defense of client-side encryption
Thanks for a thoughtful and extensive reply. Let me see if I'm understanding your position correctly. Running crypto code in a browser is inherently insecure because we don't really know what the browser is doing with it, regardless of whether it is communicating with a server. Of course, we can't be sure of what a high-level OS is doing, either, but at least it is one step closer to the hardware. Faced with this uncertainty, it seems to me that making compiled code based on NaCL still does not solve the basic problem that the user does not control (and can't even view) the OS. Even if it is shown to be safe today, there's no telling what an update might do to it in the future. Windows seems to get "security" updates every other day; it would be trivial to slip in one that undoes the security of a browser, as well as any NaCL-based code. I'm saying this without knowing much about NaCL, but I doubt it can withstand a malicious change in the OS. So, trusting the OS but not trusting the browser seems to me a curious case of double standard. They are made by the same companies, after all. The only really secure cryptography, then, would be that which does not use computers at all. Following this logic, I once made a stream cipher based on a calculator. You can see the description here: http://prgomez.com/nonfiction/crypto/17-crypto I tried to extend this work to some sort of public-key functions, but unfortunately calculators don't have the power needed to do the simplest powermod operation on which to base a Diffie-Hellman scheme. And this eventually led to PassLok, which uses the browser strictly as a powerful calculator. Unfortunately, it is written in Javascript. On Mon, Aug 12, 2013 at 5:12 AM, danimoth wrote: > On 11/08/13 at 09:37pm, Francisco Ruiz wrote: > > I still have to read through the references you supply, but I can already > > see a misconception. They refer to the dangers of carrying out > cryptography > > with javascript-containing dynamic pages. My previous posting referred to > > _perfectly static_ pages > [cut] > > I catched the point about secure delivery of the code, this is an open > problem and you suggested a youtube video with a spoken hash, assuming > no one could modify it. In this topic branch, let's assume that problem > resolved (but in others, specifically in the branch started by Guido > Witmond, it isn't). > > Talking about syntax (and so, the programming language) you and Nadim > are correct when sentencing "it's not a problem". I know, from my > background, that every programming language will finish into assembly > code, because it is the only one recognized by my CPU, so it isn't the > node of the question. The really interesting thing is the environment > where the code is executed, compiled, interpreted: in my point of view > (but in many others) browsers aren't the best places to do critical > things, because there a lot of points which aren't under our control. Is > it Windows XP with a lot of mess installed? Is it a Linux Live CD? I > don't know. Maybe the only way is throw away the entire technology stack > and go back. But, if I need to choose between browsers and OSes, I > choose OSes because they are closer to the CPU. > You could have different vision, but please take it in consideration > when presenting your product as the non-plus-ultra program of the year. > > Moving on the semantic aspect of the problem, I want to start saying my > model in every crypto thing is NaCL library. Few of us (and few in the > world) can safely play with little crypto bricks, joining them in new > and fashion protocols. This is clearly not the way of reasoning of the > majority of people: let's see for example the draft of Web Cryptography > API.. > So, you had an idea: making the 20-year old PGP in a new and simple way, > to permit inexperienced users to have the same functionality. You > used little bricks (AES, elliptic curves..), and provided high level > functionalities (Lock, Unlock, Stamp, Verify). > What about reverting this paradigm, using NaCL experience as background, > and so using something which already provides high level > functionalities, focusing on user experience following your ideas (one > simple place where doing all things, less buttons, less > configurations..) ? And yes, this is only an interface problem, because > you already have the background: GPG, NaCL, ... > > And don't think interface problems are trivial or stupid. They can make > differences.. big differences. > > -- > 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/libe
Re: [liberationtech] Tormail in trouble. Experts at Black Hat recommend Elliptic Curves: this is what PassLok 1.3 is based on.
Hi Greg,
It seems my reply didn't stick, so I'm replying again. Sorry about
that. I'm still trying to figure out hos this mail list works.
On Tue, Aug 6, 2013 at 3:20 PM, Francisco Ruiz https://mailman.stanford.edu/mailman/listinfo/liberationtech>> wrote:
>* Hi folks,*>**>* Thank you very much for your great feedback on the previous
>version. The*>* next version is now up at http://passlok.com, which redirects
>to*>* https://passlok.site44.com*>* This may come in handy now that there are
>problems with Tor, since PassLok*>* allows you to go to any computer to do
>encrypted mail, because there is*>* nothing to install. This is what PassLok
>was designed to do.*>**>* The other unforeseen endorsement came from the
>recent Black Hat conference.*>* Researchers Alex Stamos, Tom Ritter, Thomas
>Ptacek, and Javed Samuel*>* encouraged everyone to base their public key
>cryptosystems on elliptic*>* curves rather than RSA. Here's a link on this:*>*
>http://arstechnica.com/security/2013/08/crytpo-experts-issue-a-call-to-arms-to-avert-the-cryptopocalypse/*
You replied:
>Wait. You are using vague popular press FUD about RSA to promote a
>website hosted JS encryption tool? Really?>
>
>Your code generates random values like this:
>
>sjcl.random.addEntropy([a.x || a.clientX || a.offsetX || 0, a.y ||
>a.clientY || a.offsetY || 0], 2, "mouse")
>sjcl.random.addEntropy((new Date).valueOf(), 2, "loadtime")
>try {
>var s = new Uint32Array(32);
>crypto.getRandomValues(s);
>sjcl.random.addEntropy(s, 1024, "crypto['getRandomValues']")
>} catch (t) {}
>
>Meaning that if it's used someplace where crypto.getRandomValues()
>doesn't exist, it has only pure snake-oil-extract randomness.
>
>Really
This is what the SJCL code does. I didn't write this. I believe the
getRandomValues call is in addition to all the entropy collection the
SJCL is doing elsewhere. But you've got a worthwhile point. I'm adding
instructions to my code so entropy collection gets done a lot more
often, every time the user clicks or releases a button.
>If the randomness is poor, the nonce used in ECDSA will be predictable
>and the private key will be recoverable.
Absolutely. It is essential that the RNG be flawless.
>This isn't to say I've audited any of it, I just grepped for a couple
>likely mistakes. Part of the JS code has been whitespace compressed, I
>consider it unauditable.
Thanks for bringing this up. This was because the qr.js code I added
was minimized. I've corrected that. Hopefully you can read the code it
now.
>>* up to a whopping*>>* 200,000 iterations for lousy keys. Since keys made in
>>version 1.2 are no*>>* longer compatible, this prompts upping the version to
>>1.3.*>
>So, not implemented in slow-as-dirt JS 200,000 iterations should take
>a random desktop cpu about 100ms or so. This is hardly wopping. It's
>not far from the minimum I'd start with, for all keys not just weak
>ones. Generally user provided keys are a security disaster and should
>be avoided wherever it's possible, strengthening or no. Humans are
>horrific entropy sources and really can't self assess how bad they
>are.
The web app has to be able to run on a smartphone. 200k iterations require
more than a minute in an iPhone 4S. Totally unacceptable, which is why I
think this might entice users to select better passwords. The elliptic
curve multiplication needed to do anything with a private key is pretty
slow by itself, and it's always there. In that same iPhone, it is roughly
equivalent to 10k iterations, which take three seconds. Unfortunately,
using different iteration numbers depending on the platform would break key
compatibility.
Regards,
--
Francisco Ruiz
Associate Professor
MMAE department
Illinois Institute of Technology
PL13lok=WsH3zTgZn8V3hnIqjdbfPus+5YF5n+LBRPuH9USMMp8izPv+hsLoZKv+jaCFMapJFfiA11Q9yJU1K1Wo0TbjXK/=PL13lok
get the PassLok privacy app at: http://passlok.com
--
Liberationtech is a public list whose archives are searchable on Google.
Violations of list guidelines will get you moderated:
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe,
change to digest, or change password by emailing moderator at
compa...@stanford.edu.
Re: [liberationtech] In defense of client-side encryption
@Edulix (hombre, un paisano ;-) >I believe we need is an standard way to do client side encryption in >the web. We need secure end-to-end communications in the web, so that >we don't need to be trust and dependent on the html/css/javascript >given by any server. We have a "server in the middle" security >problem. This is different from a man in the middle, where there's >*potentially* someone spying in the middle: in the web, by design, >there's a server in the middle. We should not trust this server just >because it's part of the design. I believe the big problem that we are not addressing is precisely this. The server is a big liability, because a server can always be hacked or subpoenaed. We'd get better security from strictly client-side encryption/decryption. > This might seem like the holy grail, but it's not something >unachievable (but it's surely very difficult to solve in a nice >general way), here I talk about this problem: >http://edulix.wordpress.com/2012/01/08/the-server-in-the-middle-problem-and-solution/ >. BTW, as a funny note, I gave a lighting talk about the "server in >the middle" in Madrid Google's offices in 2012, showing in the slides >google as being that server. People assisting to the talk loved the >talk, but I think the google people didn't, as they didn't call me >again next year for the same event (which was "remote" Google I/O). It's servers that are getting shut down. If we move encryption to the client, then they can't shut them down. They might try to inject malicious code in a static page as it loads (not easier than injecting it into anything else, if it comes via SSL), but if the code is transparent, it can be detected. That's all I'm saying. Kind regards, too. -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL13lok=WsH3zTgZn8V3hnIqjdbfPus+5YF5n+LBRPuH9USMMp8izPv+hsLoZKv+jaCFMapJFfiA11Q9yJU1K1Wo0TbjXK/=PL13lok get the PassLok privacy app at: http://passlok.com -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] In defense of client-side encryption
@danimoth, sorry if this is duplicate. I'm re-sending this a different way so it can be seen by all. Thanks for the quick feedback. In there, you say, >First, it is in Javascript. Who needs cryptography, SHOULD NOT use >javascript. Google can help you ([1] for example, [2] if >you are coming from a 48h non-stop no-sleep marathon). I still have to read through the references you supply, but I can already see a misconception. They refer to the dangers of carrying out cryptography with javascript-containing dynamic pages. My previous posting referred to _perfectly static_ pages, which are supposed to be always the same coming from the server, not modified by the browser in any way, and which, in fact, you can save and store somewhere safe and never again have to get from the server. I believe the intrinsic security of this kind of javascript code is no different from that of compiled code, which also should be checked for tampering, so long as it uses standard functions that are not likely to be modified in browser updates. Sorry about the confusion. >Second, someone posted about your random number generator, and you >ignored it. But this is a minor problem, as all things are in >Javascript. I did reply, and the updated PassLok includes improvements based on that great piece of feedback. But perhaps it hasn't shown in the mail list because I replied directly to the poster. I'm still trying to figure out how to reply to a post on the daily digest. The criticism is actually about how SJCL handles entropy collection. I hope the SJCL developers will read it and respond to it. -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL13lok=WsH3zTgZn8V3hnIqjdbfPus+5YF5n+LBRPuH9USMMp8izPv+hsLoZKv+jaCFMapJFfiA11Q9yJU1K1Wo0TbjXK/=PL13lok get the PassLok privacy app at: http://passlok.com -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] In defense of client-side encryption
Thanks for the warning. I'll be more careful in the future ;-) BTW, I'm having trouble replying to postings in a way that will show in the log. I don't know what I'm doing wrong. Is there a help page detailing best practices for the mail list? -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL13lok=WsH3zTgZn8V3hnIqjdbfPus+5YF5n+LBRPuH9USMMp8izPv+hsLoZKv+jaCFMapJFfiA11Q9yJU1K1Wo0TbjXK/=PL13lok get the PassLok privacy app at: http://passlok.com -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] In defense of client-side encryption
Thanks for the warning. I'll be more careful in the future ;-) BTW, I'm having trouble replying to postings in a way that will show in the log. I don't know what I'm doing wrong. Is there a help page detailing best practices for the mail list? -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL13lok=WsH3zTgZn8V3hnIqjdbfPus+5YF5n+LBRPuH9USMMp8izPv+hsLoZKv+jaCFMapJFfiA11Q9yJU1K1Wo0TbjXK/=PL13lok get the PassLok privacy app at: http://passlok.com -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] In defense of client-side encryption (Guido Witmond)
In your message, you wrote: >1. I have to *run* it to get the hash of the application from the help >page. That is already a leap of faith to run unverified code. Good point. A counterfeit copy of the page might lead to a different server, and the help page thus obtained would display a different code which, of course, would check out all right. Both the active code and the help page come via TLS, but maybe this is not enough. In any case, this would be just about the same risk that anyone incurs when loading any page via https, so almost every crypto app out there would have the same security flaw.This is why I added the video verification, anyway. It's a lot harder to fake a video. >2. I have to verify the hash code with a spoken message in a youtube >video. The message is spoken by someone I've never met, so how do I >verify that it is you who's saying it and not an actor hired by a spooky >agency? Or just dubbed with a new audio score. Hollowood can do that >without a blink. I'm not Justin Bieber (thank God) and there's nothing I can do about that. But maybe someone in this forum knows a privacy-conscious celebrity who could be persuaded to do the reading. It should be possible to find one. Actors are into all kinds of causes these days... Concerning faking a video. Sure, it can be done too, but mere dubbing won't work because you have to sync the lips. Chopping the video into little pieces and reassembling it to make a different code won't be easy to pull off, either, especially with background music to serve as a sort of "tamper-evident paper". I'd like to see more discussion on this. >3. How can I validate that the youtube url is correct? They are all >gibberish to me. Again could be a fake by some adversary. This mail was >not encrypted and validated. Well, the URL leads to me (or a famous actor, in the future ;-) reading the hash for a particular version. If the guy in the video says something else, you know you don't have the right video. I think videos have great potential for authentication, since they are so much richer, and harder to fake, than a mere piece of text. >> There?s no legal action that can shut down PassLok because it consist of > >pure code, and pure code is speech, protected from government >> interference under the 1^st amendment to the US Constitution. >Theoretically you are correct. In practice, we've seen the value of your >US constitution... Lavabit and Silent Mail have shut down due to legal challenges rooted in US law. The same laws cannot be used to force a website (or many websites, for there should be mirrors) to stop delivering a certain document, unless it is pornographic or hate speech, because of the 1st Amendment. So far, free speech has been quite successfully protected in the USA. Thanks! -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL13lok=WsH3zTgZn8V3hnIqjdbfPus+5YF5n+LBRPuH9USMMp8izPv+hsLoZKv+jaCFMapJFfiA11Q9yJU1K1Wo0TbjXK/=PL13lok get the PassLok privacy app at: http://passlok.com -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
[liberationtech] In defense of client-side encryption
Twice again, privacy has taken a hit across the land. Lavabit and Silent Mail are gone, and to quote Phil Zimmermann, “the writing is on the wall” for any other encrypted email provider located in US territory. This is sure to be repeated for servers located in Europe and other countries. Is this the end of encrypted email? It might well be the end of encrypted email _servers_, at least for a while, but not of encrypted email itself. I’ve posted this a few times here, but let me repeat it: you only get real security if the encryption is handled completely client-side. Then you don’t rely on a server that can be shut down. You can use any mail system, web-based or otherwise. They’d have to shut down every mail provider and every text provider in order to shut you down. This is what PGP was when it started. We need to go back to that. And yes, client-side today might mean JavaScript. What’s so wrong with that? Sure, it is easy to intercept and modify, but it is also transparent and easy to check. If the user is willing to check a hash of the source code, JavaScript isn’t any less tamper-proof than compiled code. And who even gets to look at compiled code these days (especially if it resides in a server)? This is one of the reasons why I am developing PassLok. Thanks to feedback from members of this forum, the security provided by PassLok is stronger than ever, but you don’t have to believe me. Download it from its source at https://passlok.site44.com (once you have it once, you have it forever), look at it, run it, test it. Get its SHA256 hash from its help page and check it. If you’re as paranoid as I am, you can watch me reading that hash (with some nice background music to make tampering with it more difficult), in this youtube video: https://www.youtube.com/watch?v=VHR_w0FCkC0 There’s no legal action that can shut down PassLok because it consist of pure code, and pure code is speech, protected from government interference under the 1st amendment to the US Constitution. If you don’t think this is enough, let us all know. Let’s come up with a solution. Meanwhile, I appreciate any suggestions on how to make PassLok more secure and easier to use. -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL13lok=WsH3zTgZn8V3hnIqjdbfPus+5YF5n+LBRPuH9USMMp8izPv+hsLoZKv+jaCFMapJFfiA11Q9yJU1K1Wo0TbjXK/=PL13lok get the PassLok privacy app at: http://passlok.com -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
[liberationtech] Tormail in trouble. Experts at Black Hat recommend Elliptic Curves: this is what PassLok 1.3 is based on.
Hi folks, Thank you very much for your great feedback on the previous version. The next version is now up at http://passlok.com, which redirects to https://passlok.site44.com This may come in handy now that there are problems with Tor, since PassLok allows you to go to any computer to do encrypted mail, because there is nothing to install. This is what PassLok was designed to do. The other unforeseen endorsement came from the recent Black Hat conference. Researchers Alex Stamos, Tom Ritter, Thomas Ptacek, and Javed Samuel encouraged everyone to base their public key cryptosystems on elliptic curves rather than RSA. Here's a link on this: http://arstechnica.com/security/2013/08/crytpo-experts-issue-a-call-to-arms-to-avert-the-cryptopocalypse/ In addition to needing nothing to install and doing 521-bit elliptic curves on top of AES-256, which PassLok has done for a while, here's the new stuff in version 1.3: 1. Much more resistant to dictionary attack and rainbow tables, thanks to variable key stretching using PBKDF2. PassLok analyzes your key and applies more iterations if it feels your key is less than perfect, up to a whopping 200,000 iterations for lousy keys. Since keys made in version 1.2 are no longer compatible, this prompts upping the version to 1.3. 2. Increased resistance to tampering. Now there is a link to a youtube video of me reading the SHA256 hash of the source code. This is going to be darn hard to fake by an attacker. 3. There's a detailed PDF manual. It is invoked from the help screen. 4. The built-in subliminal channel has been extended to signatures as well as encrypted messages. It is free, so please feel free to use it and tell me how to improve it further. The link is repeated at the bottom -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL13lok=WsH3zTgZn8V3hnIqjdbfPus+5YF5n+LBRPuH9USMMp8izPv+hsLoZKv+jaCFMapJFfiA11Q9yJU1K1Wo0TbjXK/=PL13lok get the PassLok privacy app at: http://passlok.com -- Liberationtech list is public and archives are searchable on Google. 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
[liberationtech] How do I prevent a Javascript program from being tampered with?
Hi folks, here's me again seeking ideas to make PassLok the best it can be. PassLok (link at the bottom) is a free web app that does public-key cryptography using elliptic curves. Since it consists only of a single html file with Javascript code (all processing is client-side), there is a chance that an attacker might intercept the code or hack it at the source, and the user would be no wiser. To prevent this, I publish the SHA256 of the code (which PassLok itself can compute, though it is better to use an external utility), and then I read the resulting string in a Youtube video, with some background music. Both are linked from the PassLok help file. Here's the video I just made: https://www.youtube.com/watch?v=ZXWcIvLs4t0 I think that an attacker would have a very hard time making a fake video for the SHA256 of a counterfeit program, and therefore get away with tampering with the code. What do you think? Can you give me a better idea? Thanks! -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL12lok=KpYv+bqJ7pq0eqC664UlIcwfl1P8f8p12NUqFdg2bQ2gTQTBuOo09BQs3GGiYOQUuQmtnoceAxJoSzjvYEYOM0q=PL12lok get the PassLok privacy app at: http://passlok.com -- Liberationtech list is public and archives are searchable on Google. 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
[liberationtech] PassLok updated based on feedback from LiberationTech
Thanks for the excellent feedback, folks. I have taken to heart your recommendations and updated PassLok. The version number is still 1.2 because keys and messages remain compatible. The updates include, in addition to bug fixes (thanks everyone): 1. Visual aids (triangles) to cue users about titles that can be expanded into a help section (thanks, Karl). 2. The Make Lock function has been given its separate button. Same for the make ID function. 3. Some boilerplate has been added to the source for filters to recognize the code as freeware (thanks hellekin). 4. A revamped Key strength meter, which won't give a perfect score until the user has appended his/her email to the Key. This is to combat a powerful attacker (like the NSA) who might be able to make a rainbow table containing public keys for a whole dictionary's worth of likely private keys (Thanks, Michael; not quite the same as adding a random salt, but I think this achieves the objective without inconveniencing the user too much). You can get the program from http://passlok.com, which sends you to https://passlok.site44.com I have a few more questions to ask those kind enough to check out PassLok: 1. PassLok includes a function to display QR codes, which I added so that users could exchange Locks (public keys) from smartphone to smartphone while offline. But this makes the code larger by 30kB and, according to some, makes harder the job of those inspecting the source code. Is it worth keeping the QR-making ability? 2. In the updated version, I have attempted to thwart a rainbow table attack by encouraging users (through help text and the key strength meter) to add their email address to their private Key. The best way to achieve the objective, however, would be to add a random salt in the public key generation process, which would be appended to the public key. When a user wants to use his/her private key, he/she would have to fetch the public key from whatever location it has been published, and enter it along with the private key. Would the increased security be worth the hassle to the user and additional complexity of the program, though? 3. Some users are confused by having both symmetric and asymmetric encryption available, so they end up encrypting messages with their private keys, which no one else has. Would it be better to hide or eliminate the symmetric encryption mode, so this doesn't happen? Can you offer a better solution? 4. Then, there is the issue of authenticating the code so users have some assurance that it has not been modified by an attacker. Currently the PassLok help file directs users to do a "view source" in their browsers and take a SHA256 hash of the source (whether using the ID function of Passlok itself or an external utility), and compare it with the hash published in the help.html file (obviously, it must be a separate file). Now, an attacker might be able to modify the help file as well as the main file. Should the two files reside in completely different servers? I think it might be better to quickly replicate both files to several mirrors, but I don't know how to go about that. Any other strategy that might work better? Thank you very much. -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL12lok=KpYv+bqJ7pq0eqC664UlIcwfl1P8f8p12NUqFdg2bQ2gTQTBuOo09BQs3GGiYOQUuQmtnoceAxJoSzjvYEYOM0q=PL12lok get the PassLok privacy app at: http://passlok.com -- 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] PGP is hard to use and needs stuff installed on your computer. Use PassLok instead.
@Tony On Sun, Jul 28, 2013 at 1:32 PM, Francisco Ruiz https://mailman.stanford.edu/mailman/listinfo/liberationtech>> wrote: >* - How do I communicate a password to Bob? Before I "get a crucial bit*>* of >information" to Bob, I need to first get a crucial bit of information*>* to >Bob?*>**>* Alice should send her Lock (public key) to Bob rather than >anything*>* secret.*>** How? At the very least Alice/Bob need an authenticated/trusted channel for this. If Alice sends Bob her "public key" over an untrusted channel, it can be intercepted by an MitM posing as Bob who can then intercept all traffic between Alice/Bob -- Tony Arcieri Hi Tony, I actually worried about this quite a bit. The best solution I could think of is making a hashed ID of the public key (PassLok has a button for that), which Alice/Bob can dictate over the phone, thus authenticating the key. Any other ideas? Francisco -- 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] PGP is hard to use and needs stuff installed on your computer. Use PassLok instead.
@JulianOliver: I've thought about having a more polished interface, including multilevel menus, etc. They've told me all of this would be possible with jquery. But then PassLok would have to call a (large) piece of outside code, which would violate the offline rule. It can probably be done with pure javascript, but my knowledge of the language doesn't go that far. Any suggestions will be appreciated. Thanks for your great comments. On Sat, Jul 27, 2013 at 8:07 AM, Julian Oliver wrote: > ..on Fri, Jul 26, 2013 at 03:42:02PM -0500, Francisco Ruiz wrote: > > Scenario: you, Alice, realize you're under NSA surveillance. You need to > > get a crucial bit of information to your friend Bob, right away. > > You've been using PGP, but now you suspect the NSA may have installed a > bug > > on your machine. Your keystrokes are being recorded. > > > > What can you do? Use PassLok instead. > > > > I wrote PassLok with three guiding principles in mind: > > 1. Absolutely nothing should be installed or even written in the > computer. > > Alice should be able to go to the local library or borrow someone else's > > smartphone, and leave no traces behind. > > 2. Best security available. No compromises. > > 3. Graphical interface. Only one screen, as clean as possible. > > > > Therefore, PassLok is written entirely in javascript. Once you load the > > page at https://passlok.site44.com (http://passlok.com redirects you > > there), you can save the file and you have PassLok even offline. You can > > view the source and convince yourself that it is not connecting with any > > server. If you know some cryptography, you can see that it is using the > > well-known SJCL routines for AES encryption/decryption and elliptic curve > > functions. Since the elliptic curves implemented in the current version > of > > SJCL only go up to the 384-bit NIST curve, I added the 521-bit NIST curve > > (equivalent to a 15000-bit RSA key in predicted security) so that PassLok > > uses that as a default. Even at 521 bits, the public keys are small, as > you > > can see from my lock (public key) below. > > > > PassLok performs public-key cryptography using the Diffie-Hellman key > > exchange rather than RSA, so you can use whatever secret key you want. > > Hopefully something that is both very hard to guess and easy to remember, > > so you never have to write it down. PassLok will help you to come up > with a > > strong key, but won't force you in any way. > > > > PassLok can sign and verify signatures, too (many PGP implementations, > such > > as Mailvelope, cannot), and can also include a second secret message > under > > a separate key, to beat the "rubberhose attack." If you are not sure > about > > the authenticity of something, PassLock can make a short ID that you can > > read over the phone. All of it from a single screen. > > > > I want people to use PassLok and uncover any bugs it might still have, > > before I move on to a Gmail plugin based on its engine. I believe it is > > already very secure and easy to use by those who know a little > > cryptography. Hopefully the metaphor used throughout PassLok, about locks > > and keys rather than private/public key pairs, will also make it usable > by > > novices. > > > > I'll appreciate any feedback you can give me. The link is repeated at the > > bottom. > > I haven't given it an audit but so far it appears to be a very nice > implementation. Congratulations. And yes, it passed the offline, locally > hosted > test ;) > > I feel clicking on the title 'Key / Lock Conbination' for instructions > would > baffle most people. The 'step by step instructions' page is good, but I > think it > could be more helpfully integrated. Perhaps you could have a drop-down > menu for > each use case, with instructions appearing as hints in each field. > > Again, great work and a great contribution! > > Cheers, > > -- > Julian Oliver > PGP B6E9FD9A > http://julianoliver.com > http://criticalengineering.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 > -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL12lok=KpYv+bqJ7pq0eqC664UlIcwfl1P8f8p12NUqFdg2bQ2gTQTBuOo09BQs3GGiYOQUuQmtnoceAxJoSzjvYEYOM0q=PL12lok get the PassLok privacy app at: http://passlok.com -- 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] PGP is hard to use and needs stuff installed on your computer. Use PassLok instead.
@SteveWeis: - How do I communicate a password to Bob? Before I "get a crucial bit of information" to Bob, I need to first get a crucial bit of information to Bob? Alice should send her Lock (public key) to Bob rather than anything secret. - You assumed a keylogger is installed. If I type the password in the browser, isn't it compromised? Alice uses someone else's machine, or even stops someone on the street and uses his smartphone. Because PassLok doesn't need anything to be installed, this will work as well as if she used her own machine (except for the keylogger). - JavaScript is delivered from your server. How do I know it's not already compromised? Yes, I know you plan to write a plugin. Why not do that from the start instead of something immediately broken? This is the toughest problem, IMO. If Alice does not have a genuine copy of PassLok stashed in a cloud service somewhere, she will have to get it from a server, then verify it before use. I am publishing the SHA256 of the source code in the help.html companion page, which she can check using a separate utility. In order to prevent an attacker from changing this string as he changes the program, it would be best if they can be accessed from multiple sources or mirrors, so the attacker would have to change all of them. Any suggestions on this will be highly appreciated, for I realize this is a weakness. - You modified SJCL and added a 521-bit curve. How do I trust your changes? "You can audit my code" is not the answer I'm looking for -- I don't want to proof-read curve values from NIST documents I submitted the 521-bit parameters to the SJCL Google group a few months ago. Hopefully they will check them and eventually add them to the official SJCL code. In any case, having the wrong parameters would not necessarily make the code insecure, only non-standard as far as test vectors etc., which is a minor concern for one-to-one encryption. - No source. No docs. Untrusted third-party dependency on qrcode.js. qrcode.js is not called from a separate server, but is actually a part of the code so it can be inspected. PassLok does not call any external code at all. Not even images. The code is all in the one source file. I wonder about the usefulness of the QR code function, though, for it makes the program larger by about 30k and harder to inspect. Maybe you can tell me if having the ability to transfer public keys from phone to phone without Internet is worth the trouble. I also wonder whether using SHA512 instead of SHA256 for stamps (signatures) is worth the extra 10k of code that it entails. - I've seen dozens of JavaScript crypto projects like this over the years. How is this approach different from all the others that failed? I'm quite new to this, so I can't quite answer this question. I'm only familiar with Javascrypt, by John Walker, which only had symmetric AES encryption. PassLok started as an attempt to add public-key functions to Javascrypt. But if I had to guess, I'd say one problem they might have had is needing to contact outside servers or load outside code, which should be a no-no IMO. Excellent comments, though. I'm correcting the code based on all this feedback. Any other suggestions will be greatly appreciated. F. Ruiz On Fri, Jul 26, 2013 at 5:51 PM, Steve Weis wrote: > If you assume communications are monitored and your machine is > compromised, this has some fundamental flaws: > - How do I communicate a password to Bob? Before I "get a crucial bit > of information" to Bob, I need to first get a crucial bit of information > to Bob? > > - You assumed a keylogger is installed. If I type the password in the > browser, isn't it compromised? > > - JavaScript is delivered from your server. How do I know it's not > already compromised? Yes, I know you plan to write a plugin. Why not > do that from the start instead of something immediately broken? > > - You modified SJCL and added a 521-bit curve. How do I trust your > changes? "You can audit my code" is not the answer I'm looking for -- > I don't want to proof-read curve values from NIST documents. > > - No source. No docs. Untrusted third-party dependency on qrcode.js. > > - I've seen dozens of JavaScript crypto projects like this over the > years. How is this approach different from all the others that failed? > > On Fri, Jul 26, 2013 at 1:42 PM, Francisco Ruiz wrote: > > Scenario: you, Alice, realize you're under NSA surveillance. You need to > get > > a crucial bit of information to your friend Bob, right away. > > You've been using PGP, but now you suspect the NSA may have installed a > bug > > on your machine. Your keystrokes are being recorded. > -- > Too many emails? Unsubscribe, change to digest, or change password by >
Re: [liberationtech] PGP is hard to use and needs stuff installed on your computer. Use PassLok instead.
Thanks for your excellent feedback, David, PassLok 1.2 is a perfectly static page. Therefore, I don't believe it is vulnerable to the standard XSS attack, as CERT says: "A web page contains both text and HTML markup that is generated by the server and interpreted by the client browser. Web sites that generate only static pages are able to have full control over how the browser interprets these pages. Web sites that generate dynamic pages do not have complete control over how their outputs are interpreted by the client. The heart of the issue is that if mistrusted content can be introduced into a dynamic page, neither the web site nor the client has enough information to recognize that this has happened and take protective actions." (CERT Coordination Center). Now, I am worried about an attacker replacing the original page with another page with broken or backdoor encryption. This is why requests to download PassLok are redirected to https. I've tried to hide the identity of the server as best as I could but there is still the possibility that someone might find the server, hack it somehow, and change the code, even replacing the self-check string in the help file. I think the best defense against this is mirroring, so an attacker would have to hack multiple unrelated servers to get away with it. It would be great if people could provide some mirrors. I would list them all in the help page (or even the index page, if they are not too many), and let the user download several and do a file comparison. Again, any ideas in this respect will be greatly appreciated. Francisco On Fri, Jul 26, 2013 at 3:59 PM, wrote: > You should use ContentSecurityPolicy to help avoid XSS attacks: > http://content-security-policy.com/ > https://people.mozilla.com/~bsterne/content-security-policy/ > > Regards, > > David > > On Fri, 26 Jul 2013 15:42:02 -0500, Francisco Ruiz wrote: > > > Scenario: you, Alice, realize you're under NSA surveillance. You need to > > get a crucial bit of information to your friend Bob, right away. > > You've been using PGP, but now you suspect the NSA may have installed a > bug > > on your machine. Your keystrokes are being recorded. > > > > What can you do? Use PassLok instead. > > > > I wrote PassLok with three guiding principles in mind: > > 1. Absolutely nothing should be installed or even written in the > computer. > > Alice should be able to go to the local library or borrow someone else's > > smartphone, and leave no traces behind. > > 2. Best security available. No compromises. > > 3. Graphical interface. Only one screen, as clean as possible. > > > > Therefore, PassLok is written entirely in javascript. Once you load the > > page at https://passlok.site44.com (http://passlok.com redirects you > > there), you can save the file and you have PassLok even offline. You can > > view the source and convince yourself that it is not connecting with any > > server. If you know some cryptography, you can see that it is using the > > well-known SJCL routines for AES encryption/decryption and elliptic curve > > functions. Since the elliptic curves implemented in the current version > of > > SJCL only go up to the 384-bit NIST curve, I added the 521-bit NIST curve > > (equivalent to a 15000-bit RSA key in predicted security) so that PassLok > > uses that as a default. Even at 521 bits, the public keys are small, as > you > > can see from my lock (public key) below. > > > > PassLok performs public-key cryptography using the Diffie-Hellman key > > exchange rather than RSA, so you can use whatever secret key you want. > > Hopefully something that is both very hard to guess and easy to remember, > > so you never have to write it down. PassLok will help you to come up > with a > > strong key, but won't force you in any way. > > > > PassLok can sign and verify signatures, too (many PGP implementations, > such > > as Mailvelope, cannot), and can also include a second secret message > under > > a separate key, to beat the "rubberhose attack." If you are not sure > about > > the authenticity of something, PassLock can make a short ID that you can > > read over the phone. All of it from a single screen. > > > > I want people to use PassLok and uncover any bugs it might still have, > > before I move on to a Gmail plugin based on its engine. I believe it is > > already very secure and easy to use by those who know a little > > cryptography. Hopefully the metaphor used throughout PassLok, about locks > > and keys rather than private/public key pairs, will also make it usable > by > > novices. > > > > I'll appreciate any fe
[liberationtech] PGP is hard to use and needs stuff installed on your computer. Use PassLok instead.
Scenario: you, Alice, realize you're under NSA surveillance. You need to get a crucial bit of information to your friend Bob, right away. You've been using PGP, but now you suspect the NSA may have installed a bug on your machine. Your keystrokes are being recorded. What can you do? Use PassLok instead. I wrote PassLok with three guiding principles in mind: 1. Absolutely nothing should be installed or even written in the computer. Alice should be able to go to the local library or borrow someone else's smartphone, and leave no traces behind. 2. Best security available. No compromises. 3. Graphical interface. Only one screen, as clean as possible. Therefore, PassLok is written entirely in javascript. Once you load the page at https://passlok.site44.com (http://passlok.com redirects you there), you can save the file and you have PassLok even offline. You can view the source and convince yourself that it is not connecting with any server. If you know some cryptography, you can see that it is using the well-known SJCL routines for AES encryption/decryption and elliptic curve functions. Since the elliptic curves implemented in the current version of SJCL only go up to the 384-bit NIST curve, I added the 521-bit NIST curve (equivalent to a 15000-bit RSA key in predicted security) so that PassLok uses that as a default. Even at 521 bits, the public keys are small, as you can see from my lock (public key) below. PassLok performs public-key cryptography using the Diffie-Hellman key exchange rather than RSA, so you can use whatever secret key you want. Hopefully something that is both very hard to guess and easy to remember, so you never have to write it down. PassLok will help you to come up with a strong key, but won't force you in any way. PassLok can sign and verify signatures, too (many PGP implementations, such as Mailvelope, cannot), and can also include a second secret message under a separate key, to beat the "rubberhose attack." If you are not sure about the authenticity of something, PassLock can make a short ID that you can read over the phone. All of it from a single screen. I want people to use PassLok and uncover any bugs it might still have, before I move on to a Gmail plugin based on its engine. I believe it is already very secure and easy to use by those who know a little cryptography. Hopefully the metaphor used throughout PassLok, about locks and keys rather than private/public key pairs, will also make it usable by novices. I'll appreciate any feedback you can give me. The link is repeated at the bottom. Thanks! -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology my PassLok lock: PL12lok=KpYv+bqJ7pq0eqC664UlIcwfl1P8f8p12NUqFdg2bQ2gTQTBuOo09BQs3GGiYOQUuQmtnoceAxJoSzjvYEYOM0q=PL12lok get the PassLok privacy app at: http://passlok.com -- 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
