Hi there, you may be interested to know that all crypto primitives used in the Clipperz password manager are asynchronous and do not rely on web workers. You can find them here: https://github.com/clipperz/javascript-crypto-library/ The library includes: AES, SHA2, SRP and Fortuna.
For example, the asynchronous AES implementation is here: https://github.com/clipperz/javascript-crypto-library/blob/master/js/Clipperz/Crypto/AES.js#L800 While you can find some tests here: https://github.com/clipperz/password-manager/blob/master/frontend/gamma/tests/tests/Clipperz/PM/Crypto.html#L153 This approach will eventually become obsolete when all browsers and platforms will fully support web workers, but for the time being going asynchronous is probably the best way to achieve efficiency in most environments. You can also get some idea on how Clipperz handled array/string conversions. Regards, Marco -- Support Clipperz, donate now! http://www.clipperz.com/donations email: [email protected] mobile: +39 348 2476970 gtalk: [email protected] skype: mbarulli twitter: clipperz On Thu, Feb 16, 2012 at 1:04 PM, Carsten Wentzlow <[email protected]> wrote: > Hi! > ~~~ > > On 02/14/2012 06:57 PM, Sean Colyer wrote: >> So, I've been thinking about this a bit and I think the ideal situation >> would be to have openpgp.js implement worker threads so that the public api >> of encrypting/decrypting would stay pretty much the same except for the >> addition of callback methods. >> >> 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). >> >> Thoughts everyone? Carsten? > > Well, a very easy way to do this is to abstract the symmetric encryption / > decryption routine (openpgp_crypto_symmetricEncrypt and > openpgp_crypto_symmetricDecrypt) into a worker. These functions are not > requiring any additional secure random or reading from the storage so a > worker wrapper implementation should be straightforward. In a long term > perspective we might also have to put the asynchronous encryption routines > into a worker to stop the browser from freezing when creating or retrieving > an asymmetric encrypted session key for large key sizes. > > Another problem of the current implementation with big impact on performance > is the conversion between byte (int 0-255) array and string. I often made use > of the two conversion functions bin2str and str2bin to feed data in the > correct format into libraries. I think we should internally change this > behavior to only using arrays of integers after base64 decoding has been done. > > regards, > carsten > > _______________________________________________ > > http://openpgpjs.org _______________________________________________ http://openpgpjs.org
