|
My thanks to you and your team for having developed this. The cost of crypto is, at present, far too high for mainstream use - or so it seems. Undoubtedly, the challenges inherent with its correct implementation are a part of the reason for that high cost, but the media's depiction of the field is certainly no help either. How technical is your audience? It's been posed elsewhere in these comments, but one area that I'm particularly interested in is your proposal for key exchange. For example, your site warns the user to never email or IM their password: that's great advice, but I don't see any suggestion of a suitable alternative. Granted, I would consider your primary audience to be proxy: that is, the recipients of encrypted messages compelled to install your extension on their machine. Your take may be different, and of course these individuals may simply use-it-and-forget-it, but I'm sure that some of them would want to become your users as well. In those cases, the copy for this section may be confusing or thought incomplete. What happens to my plaintext once its recipient has decrypted it? From the source, after passing the encrypted data to sjcl, it looks as though the plaintext is simply appended to the DOM in place of the encrypted message. Are we certain that Google is not performing any kind of DOM analysis? I don't know how Google behaves in this regard; what assurances do I have that my decrypted messages are still secure? With a lack of deeper technical details regarding your implementation (understandable considering your proposed audience), should I assume that you're using the sjcl default of 128 bit AES in CCM mode? Would you consider publishing these details on your website? My apologies if I've overlooked them. I'd like to echo IgorPartola's sentiments and upvote, however little that may be worth. Usability is crypto's silver bullet and any reasoned discussion which furthers our attention to this problem certainly has value in my opinion. |