> > I think the best places to break it down are between the higher level > process and the encryption/decryption mechanism. Initially my thought was > to have a wrapper around all types of the packet objects, however I think > this is largely unnecessary. Since the vast majority of encryption effort > is in the encrypted integrity data packet (tag 18), and the vast majority > of decryption effort is in the encrypted session key packet (tag 3), I > think it makes most sense to focus on these first. > > I don't think it makes sense to have the keyring run in a thread of sorts, > so the only window issue I think is the window.crypto problem. I believe > the way to solve this is have the root openpgp.js call listen for messages > and pass back secure randoms from the window as is necessary. (I'm not sure > on the overhead this will add but perhaps it will be best to do this in > large chunks). >
I'm not familiar with the codebase yet. But that sounds logical. I'm just letting thinking out loud here, but I read in the Github Issues, that one goal would be to provide a node.js module ( https://github.com/openpgpjs/openpgpjs/issues/24). Couldn't modularizing for a web worker also help with that effort... two bird with one stone if you will ;) Tankred
_______________________________________________ http://openpgpjs.org
