I'm not going to try to jump in here and answer all of these questions, but I would like to make a few points.
As I mentioned, I am working on getting the s2k working for key generation, but even when that is implemented, private keys should still be regarded exactly the same as they are without a password. Brute forcing pgp keys (even with s2k type 3: salt + iterator) should be regarded as a viable attack for security considerations. Generally addressing security: security is all about tradeoffs, so I think it's important to recognize that we are focusing on minimizing risk within our domain. I don't say this to imply that concerns should be written off by any means, but rather that we are going to focus on the things that we have control over. High level security concerns: --Application Distribution - These concerns are largely the same as binary application distribution. How does a user acquire a binary to run? How does a user verify that that code is the code they think it is (MD5/SHA1?)? I think from designing the framework the best that we can do here is to make recommendations as to how other developers implement our system. I think the most important is to basically wrap all OpenPGP in SSL/TLS. We all know there are problems with SSL/TLS particularly in regards to CA's, but it is currently the best institution available (and could be compatible with alternatives such as Moxie's Convergence). The original discussed blog proposes using either SSL or PGP, but I think we're using PGP for a different function. The scheme being addressed in the blog post seems to hint at eliminating SSL for communication between user and web server, the purpose of our PGP encryption is not between user and web server but rather between user and user, communication between user and web server should be secured using best practices. I think additionally OpenPGP has great possibility as an extension. I personally am most interested in this aspect because it grants us the ability to encrypt communication of existing web applications without drastically changing user experiences. This has it's own set of concerns. --Standards - This is generally a huge concern regarding cryptography and custom implementations for a given need. We are lucky in this regard because we are able to implement the existing RFC 4880 - OpenPGP. This means that some of the concerns --such as how do we handle passing session encryption keys? How do we handle what determines a public key? Etc.-- have already been addressed and we do not need to reinvent the wheel. The risk from this perspective is to properly implement the standard. I think this is why it's important to test interoperability with other OpenPGP compliant applications (I've been testing against GPG). --Key Management - This is something that is currently an optional, modular component of openpgp.js. There could be multiple implementations of this, however currently as defined it is using html5 local storage. This is advantageous because the access is limited to a certain domain -- this application works very well for extensions which have their own domain, because they are isolated from virtually everything else. However, this might be imperfect for typical browser usage because then users would need to add their keys to each domain that they use. Additionally, from a security perspective if bad code were able to be injected into the website then they could perhaps access this storage (further advantage of SSL all interactions). I would be interested in other suggestions for key management. --Cryptography - CSPRNG is absolutely the biggest concern in my mind here. Having weak random numbers is a serious flaw in security, that would undo most of the value of encryption, and could go overlooked. window.crypto.* by definition is a CSPRNG. This is browser dependent and is not fully implemented across browsers yet. Since we directly use this for random values, testing is dependent on browsers. I think we could consider supplementing with additional entropy, however, as browsers converge on this standard I think that should eventually be unnecessary. I believe Clipperz uses a fortuna-based csprng in JS. Good CSPRNG problems are by no means limited to JS implementations (between recent news of bad RSA keys and Dan Kaminsky overloading random values), but is something to be aware of for all cryptography. We are generally using/modifying existing code for symmetric/asymmetric encryption -- however if these implementations were broken or had issues, then it's highly likely that these messages would be unreadable. I would love to have external auditing/reviewing of openpgp.js, and documentation to help ensure proper implementations. I think some of the concerns raised are beyond the scope of project, but there are definitely concerns we need to continue to address moving forward. Sorry this is a bit long I just wanted to talk about a few of the issues and where I think this project fits into the picture. Any additional expertise that people can contribute is very welcome.. Thanks, Sean On Sat, Feb 25, 2012 at 6:09 PM, Nils Kenneweg <[email protected]>wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 25.02.2012 23:47, schrieb Tankred Hase: > >>> I think before defending against some difficult attacls it > >>> would make sense to start at those basics :) > >> > >> Passphrase protected means it is encrypted with a key, so if it > >> is passphrase protected with a strong passphrase (30 keys +) it > >> should be uncrackable. > > > > Yeah but I can only generate a key without a passphrase with the > > library at the moment. I dont want my users to have to do that with > > gpg on the commandline. Im my opinion security wont help the > > average user if its too difficult to use. > > Yep, true, feature definitly needs to be added. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.17 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJPSWodAAoJECvXQ9f0b0HoWSwH/jIw18cA6A3XpU1tMZMAS1qm > yEYyZwiVQGUMIVikuicUGVmcsH3qjvOeoV63Hi1nCPYiW6BQ4gWfSjCRgnRoWSKI > Gp3wrpub7MT0R1OjSM2aHGk3LA+kKo04MuoHjYs8a+r0S2LPIbkZJSw/6hxJJcWw > 3Vtjy1dQyu7Bbk0A5fokz+6oOnxWTdNhAyP0pNbqYC93x0AVWyMXM113yVExYHI5 > USxPUTyl+oD4ZyOl6/FBpFOnmOlwojnT2cePXte3biGkAd1pYpJGcGBWMGkcMZSN > Pz2B6FyaNjaalHUMAJfQS124KSPyFPn704Q63W4H7VhmX/MMsJpc/Sl3F+9EtC0= > =mz0E > -----END PGP SIGNATURE----- > _______________________________________________ > > http://openpgpjs.org >
_______________________________________________ http://openpgpjs.org
