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)
