Hello, On Sat, Feb 18, 2012 at 8:03 PM, venom00 <[email protected]> wrote: > On Sat, 2012-02-18 at 20:42 +0100, Arturo Filastò wrote: >> On Feb 18, 2012, at 8:16 PM, [email protected] wrote: >> >> > Hello Fabio, >> > >> > Clipperz's implementation does not use typed array, as they are too >> > new and too little supported for our target. >> > >> > But Clipperz is wrapping all the binary data manipulation into an >> > abstract BinaryArray class [1]. This abstract class had a few >> > different implementations, one using untyped arrays, another using >> > regular strings and a third one using hex strings. The hex string >> > implementation performed very badly, and also the string one was not >> > working great, so at the moment only the array based implementation is >> > left. >> > >> >> Yeah a custom BinaryArray class i generally the way to do it. Also sjcl the >> stanford crypto library does that. >> >> https://github.com/bitwiseshiftleft/sjcl/blob/master/core/bitArray.js
Stanford Java Script Library was released a couple of years ago (~2010); Clipperz's library is available since 2007. Just to have some perspective. :) > Beware because if you use typed arrays wrapped in another object and > access through an accessor (.byteAtIndex(...)) you could lose the > advantages. I'm not completely sure, but if you don't see a performance > gain this could be the reason. I will try to write the code and then we may be able to make some measure. > I've tried to use typed array with SJCL but it's harder than what you > think, as they store the length in bit of partial word after the 32nd > bit. And if you use a typed array all the information after that bit > gets lost. > > Here's their perverse way of storing the length of a partial word: > https://github.com/bitwiseshiftleft/sjcl/blob/master/core/bitArray.js#L114 > > It took me half day to understand what they were trying to do. I tried > to put up an alternative solution compatible with typed arrays. > Basically I was boxing the partial word in a Number object and adding a > property .bitLength, however there are some problems and currently I'm > very busy. > >> > But it would be trivial to add another implementation based on typed >> > arrays; and it would also be possible to have both implementations >> > available, and selecting the right one based on the browser where the >> > code is going to be executed. >> > >> >> It may be a good idea to have a default that goes for typed arrays and fails >> over to a generally compliant version. >> >> I would consider the fact for Clipperz to use already existing open source >> javascript >> libraries for handling the crypto. It's bad to reinvent the wheel. >> >> SJCL is very widely used and academically studies it might be a good idea to >> switch to that. > > I definitely agree. From my performance test they always win over other > libraries. I'll share my results with you as soon as I've some spare > time. When the SCJL team did they performance evaluation with Clipperz's library, they compared our async version with their sync version [1]. And in our async implementation there was a timer tuned for older browser implementations that was behaving very poorly on newer browser. Since then I have update the code in order to be self-tuning, and pick the best value for the timer in order to maximize the crypto performance without blocking the browser. Anyway, in a JavaScript environment, more than the actual AES implementation, the actual PRNG used is what may create a real difference on the overall security of the processed data. Cheers, Giulio Cesare [1] Clipperz's library is, as far as I know, still the only asynchronous JavaScript crypto library not using web workers _______________________________________________ http://openpgpjs.org
