Very slow encrypt speed

[xqdoo00o]

Every 16 bytes a async func subtle.encrypt is the most doubtful reason, too much async functions, and it's serial runs.

But If use Web Crypto API, it's necessary to do it, because the ctr mode counter is difference with NIST standard.

So I recommend use sjcl to do it.

I read this 101arrowz/fflate#45 , then I try to use, and found the issue.

[gildas-lormeau]

I agree that encryption is slow for the reasons you mentioned. I'll try to integrate sjcl and do some tests. I'm not sure it will be faster though.

[xqdoo00o]

I compared with this Stuk/jszip#696 , It's 10x faster on my machine even without fflate(using pako) .

[gildas-lormeau]

@xqdoo00o Out of curiosity, wouldn't you want to contribute to zip.js in order to integrate sjcl?

[xqdoo00o]

I will if I have time

[gildas-lormeau]

I'm asking you this because I looked at your implementation and I'm realizing you have a certain level of expertise with sjcl that I don't have.

[gildas-lormeau]

I rollbacked the changes, the implementation is still buggy...

[xqdoo00o]

To simplify the code, if using pako to deflate, the pako output chunksize is alway 16384 except the last chunk. so don't need pendingInput in AESEncrypt constructor if it's pako mode, the fflate mode need.
And the AESEncrypt constructor need a ctrgladman instance.

[xqdoo00o]

I could modify the code today or tomorrow

[gildas-lormeau]

Actually, my unit tests worked with my implementation of Deflate/Inflate. However, there was an issue when It tried the implementation with the demos. It was a bit late so I preferred to rollback, I don't think it's a big issue. Hopefully, I'll be able to fix it today. I'll keep you updated :)

[xqdoo00o]

Ok, I find a issue that the commit make fromBits return Uint8Array instances, the output length is not input length, so the commit is total useless.

[gildas-lormeau]

Oh thank you! As I said, it was late. Sorry for that totally useless commit.