"padding" resulting when encrypting binary file data out of ArrayBuffer

[Erik Jacobs]

Hi all,

I had the same problem with CryptoJS so I am assuming that it is actually not directly related to the JS libraries, but I am using an ArrayBuffer to read in a file in the browser and then encrypt it.

I have some sample code (referencing CryptoJS) here:
https://gist.github.com/thoraxe/4d4fa78bdc0b4605eed9

The binary file in question is attached - a 1pixel GIF file.

Here's my post on the CryptoJS list:
https://groups.google.com/forum/#!topic/crypto-js/_aey7e7rQPM

Long story short, when encrypting and then decrypting the file, I am ending up with extra bytes.  Original file:

$ xxd 1pix.gif
0000000: 4749 4638 3961 0100 0100 8000 00ff ffff  GIF89a..........
0000010: ffff ff21 fe11 4372 6561 7465 6420 7769  ...!..Created wi
0000020: 7468 2047 494d 5000 2c00 0000 0001 0001  th GIMP.,.......
0000030: 0000 0202 4401 003b                      ....D..;

And here's the hex for the resulting file produced with SJCL:

$ xxd 1pixtest.gif
0000000: 4749 4638 3961 0100 0100 c280 0000 c3bf  GIF89a..........
0000010: c3bf c3bf c3bf c3bf c3bf 21c3 be11 4372  ..........!...Cr
0000020: 6561 7465 6420 7769 7468 2047 494d 5000  eated with GIMP.
0000030: 2c00 0000 0001 0001 0000 0202 4401 003b  ,...........D..;

This thread on SJCL list references BinaryString:
https://groups.google.com/forum/#!topic/sjcl-discuss/iVbb6X9S2a0

But I would think that, if not slicing, using BinaryString on a large file might be quite painful.

Is ArrayBuffer really the problem, or is my understanding of how to use it the issue? Encrypting the ArrayBuffer directly definitely did not work, so I was essentially using this method:
http://stackoverflow.com/questions/20324339/sjcl-encryption-results-wrong-file-size

This effectively converts the ArrayBuffer contents to a Uint8 array.

I'm totally lost on how to make this work.

[Erik Jacobs]

I created a new gist that is a 100% "self contained" HTML + Javascript that exhibits this behavior, both across CryptoJS and SJCL:

https://gist.github.com/thoraxe/465b9e1418b6270d5dc6

There is no external server involved. The data is encrypted out of the binarystring (not using ArrayBuffer anymore) and then decrypted out of the page itself. I am still using the 1pix.gif

Any thoughts?

[Ron Garret]

You (almost certainly) have a unicode encoding problem somewhere.  The second version is the first version treated as a latin-1 string encoded into bytes using utf-8.

--
You received this message because you are subscribed to the Google Groups "SJCL discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sjcl-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
<1pix.gif>

[Erik Jacobs]

So I did a little more digging in the JavaScript console, and I found something interesting:

>>> reader.result

"GIF89a � �€��ÿÿÿÿÿÿ!þ Created with GIMP�,���� � �� D �;"

>>> reader.result.length

56

>>> sjcl.decrypt(key,sjcl.encrypt(key,reader.result)).length

56

So the number of bytes isn't changing with SJCL. That means that, after decryption, it's the getting the file prepared for download by the browser that is causing the issue. Basically, everything after line 62:
https://gist.github.com/thoraxe/465b9e1418b6270d5dc6#file-crypt-js-L62

I have to do some banging on the HTML5 / Javascript / Download / Blob thing... but I think therein actually lies the problem.

[Erik Jacobs]

The issue appears to purely be related to creating the Blob. I've thrown this up on Stack Overflow:
http://stackoverflow.com/questions/23795034/creating-a-blob-or-a-file-from-javascript-binary-string-changes-the-number-of-by

The sole question I guess is how to turn a JavaScript binary string (which is what you get by decrypting binary stuff) into a Blob that isn't somehow munged between Latin-1 and UTF-8.

That's outside the scope of this mailing list, though... so thanks for the input!