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 <[email protected]> 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 [email protected] or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
