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
