Ok, so I've just pushed a commit that has the outlines for key generation as I think it should integrate.
The call is available via openpgp.generate_key_pair. It returns key_material objects as well the armored text that will allow us to easily export the generated keys. There are still things to add to it such as S2K (which will allow for passwords) and subkeys which is pretty important, but I think the outline fits well into the framework. General view of the changes: I've added a high level call into openpgp.js, which calls openpgp.crypto.js. I've added write methods to openpgp.packet.keymaterial.js to create the key_material objects that we can consume. I've changed rsa.js for RSA key creation. Few other tweaks, only a little existing code was changed. Hope we all agree that the way I've built it fits in well, feel free to send feedback. Sean On Wed, Jan 11, 2012 at 5:48 PM, Alex (via GPGTools) <[email protected]>wrote: > Hi Sean, > > you might want to create separate tickets... ;) > > Best regards, Alex > > > On 11.01.2012, at 16:09, Carsten Wentzlow wrote: > > > Hi! > > ~~~ > > > > On 01/10/2012 05:53 AM, Sean Colyer wrote: > >> A couple of thoughts/questions so far: > >> > >> * When the framework creates errors/messages it often contains some > HTML formatting. I think we need to consider a different way of logging, > perhaps an object that contains the message, or some code for a message, > and then formatting could be a different value for that object? > >> > > > > Good idea. I only added HTML formatting to have it in gpg4browsers. For > using util.print_* it is necessary to have the function showMessages(html) > defined on the page. I think it would be a good approach to extend this and > to add a type which message is transmitted to the "to be implemented" > function (e.g. showMessages(type [debug,info,warn,error], string text)). > > > >> * There seems to be a number of places where when parsing/reading > keys we return an array but I'm not sure when they would be useful? There > seems to be a lot of priv_key[0] or similar for public keys. I couldn't > think of a good use case for these off the top of my head, but I could > easily be overlooking something. > >> > > > > Well, in some cases it is an array because key ids are not representing > the identity of the key so multiple keys can exist with the same keyid. In > other cases it is like that because exported public key blocks (e.g. > openpgp.read_privateKey function) can contain several public keys in one > block. > > > >> * When retrieving keys from they keystore, I think they should be in > the same format as what would be returned from an openpgp.read_privateKey > (or publicKey). Any reason not to change it to work that way? > >> > > > > No. Please go ahead. > > > >> * I'm planning on adding Fortuna based key generation (probably > based off of the implementation here: https://github.com/wxfz/fortuna). > I'm thinking the best way to do this is basically to use some of the > existing methods to create an armored text and then re-read that in using > the existing openpgp calls. Thoughts? > >> > > > > Hmm. I don't understand this. Why creating armored text and doing a > re-read? For generating keys all functions required are present: The > BigInteger lib (jsbn) provides all prime check functions required. The > window.crypto.getRandomBytes() function provides secure random. All we need > to do is to implement a write_packet function to write a key into openpgp > packets and three gen_key functions (or a > openpgp.packet.keymaterial.create_key(algo, size) function) in rsa.js, > dsa.js and elgamal.js. > > > > If you want to introduce a PRNG into openpgpjs it would be great too. On > browsers where window.crypto.* is currently not supported an entropy > gathering daemon using a prng could be implemented. Therefor the > openpgp.crypto.openpgp_crypto_getSecureRandom() / > openpgp.crypto.openpgp_crypto_getSecureRandomOctect() must be adjusted. To > choose a good PRNG system is another task a crypto expert should do. Check > out: http://baagoe.com/en/RandomMusings/javascript/. > > > >> Again, we've made great strides so far, and I'm hoping we can continue > that moving forward. > > > > Me too. > > > > > > best regards, > > carsten > > > > _______________________________________________ > > > > http://openpgpjs.org > > > > > -- > http://gpgtools.org > http://gpgtools.org/about (Google+, Twitter, RSS) > > _______________________________________________ > > http://openpgpjs.org >
_______________________________________________ http://openpgpjs.org
