@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 <stevew...@gmail.com> 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 <r...@iit.edu> 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 > 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
