streaming ZIPpin and AES encryption with javascript

[Gijs Molenaar]

Hello Amsterdam.js,

I'm doing research on file upload encryption for a project. The idea is
that a file uploaded with a regular HTTP POST form is encrypted in the
browser.

I have this sort of working for Google Chrome and Firefox. It is a bit
messy since I'm new to JS but is a proof of concept:

https://github.com/gijzelaerr/FileBender/tree/master/static/js

It reads the file in chunks, BASE64 encodes the trunk and encrypts it
with SJCL [1]. Speed is acceptable, higher than the average home upload
speed.

Now somebody i was talking to came up with the idea to generate a ZIP
file encrypted with AES. This way there is also the option to download
the file outside of our encryption system and unzip it with for example
winzip.

I found a nice new javascript ZIPpin lib [2], but AES encryption isn't
high on the todo list. Next to that, it is not streaming. I need to do
some sort of chunking to reduce memory usage - I want to zip & encrypt a
part, uploaded it and then proceed to the next part.

As far as I know there is no streaming ZIPpin and AES encrypting
JavaScript library. We probably need one. Creating one may take some
time and effort but doesn't seem impossible. Are the any people here
with experience in this stuff and/or has a useful suggestion?

Thanks you very much,

--
Gijs Molenaar
http://pythonic.nl

[1] http://crypto.stanford.edu/sjcl/
[2] http://jszip.stuartk.co.uk/

[Gijs Molenaar]

Hi all,

Thanks for the X-mas special. For the people who don't know, I was the
guy with the brown cap.

I was hoping that somebody would reply to my previous e-mail about
encryption and JavaScript. Maybe it is the wrong mailinglist or maybe
the combined knowledge about encryption and javascript is not common. I
don't know - please let me know if you think you know :)

Let's say it in different words; I'm looking for freelancer or something
who thinks he/she can make/modify a javascript lib that can create AES
encrypted zip files in a streaming/chunked way. Everything will be open
sourced. This stuff will eventually be used by a dutch hospital for
exchanging sensitive information.

Also if you think I'm looking in the wrong direction please let me know.

Thanks,

--
Gijs Molenaar
http://pythonic.nl

[tg]

On Thu, 22 Dec 2011 11:32:44 +0100, Gijs Molenaar wrote:
> I was hoping that somebody would reply to my previous e-mail about
> encryption and JavaScript. Maybe it is the wrong mailinglist or maybe
> the combined knowledge about encryption and javascript is not common. I
> don't know - please let me know if you think you know :)
>
> Let's say it in different words; I'm looking for freelancer or something
> who thinks he/she can make/modify a javascript lib that can create AES
> encrypted zip files in a streaming/chunked way. Everything will be open
> sourced. This stuff will eventually be used by a dutch hospital for
> exchanging sensitive information.
>
> Also if you think I'm looking in the wrong direction please let me know.

Hi,

you're better off doing encryption with a proven crypto library
written in C. There are quite a few problems with JS crypto:

http://www.matasano.com/articles/javascript-cryptography/
http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/

--
tg

[Gijs Molenaar]

It is not decrypted. The idea is that the file leaves the computer
encrypted and is stored server side this way. We want to have the
encryption as close to the user as possible, without the requirement to
install 3rd party software or plugins. The key or password is
transmitted to the receiver via a different channel, like SMS.

We will also use HTTPS, but that's for securing the authentication etc.

Thanks for your thoughts,

- Gijs

On 12/22/2011 11:48 AM, Alexander Fritze wrote:
> Hi Gijs,
>
> What happens to the encrypted file at the other end - do you decrypt
> it there? Or, to put it another way, doesn't your usecase fall under
> something that could just be achieved by transferring the data over
> https, possibly secured with client certificates?
>
> Cheers,
> Alex

[Gijs Molenaar]

Hello tg,

Thanks for your interesting answer.

We are aware of all points discussed in these pages. We evaluated all of
them and still we want to do it.

It is not replacing any security, it is a added feature. The only
problem I see is possible a bad random number generator but this is a
thing that can we worked on like by using mouse movement.

One other interesting point is about trust - if you want to upload a
encrypted file to a party that also supplies you the encrypting code the
process is flawed. The thing is, we want to separate the storage and
webserver in isolated environments. Even if the storage server is hacked
or a sysadmin goes berserk he can't access the content. The single point
of failure is the hacking of the webserver and a replacement of the
crypto code. We are aware of that.

- Gijs

[Patrick Simpson]

Hi Gijs,

While I fully agree with tg's comment that you're better off with a proven library, I understand what you're trying to do and if you don't want any plugins, I don't see any option other than using JS crypto. The issues in the links posted by tg are valid, but that is a different use case where the server and client need to share a key. As that is not the case in your approach, I don't think there are any architectural weaknesses to overcome.

Having said that, you're looking at a lot of implementation issues. For starters, I do not know of any actively maintained crypto libraries for JS. There are some AES implementations floating around, but it'd be hard to say how many weaknesses they might have without taking a very close look. Writing an implementation from scratch is not something you'd want to do. Seriously. Even if you get it working correctly in all cases, it'll be unbearably slow compared to existing ones.

Then you're facing the issue that these mostly do block-to-block encryption, which is not practically useful for any purpose, so you'll want to make them operate in something like CBC or CTR mode, depending on your exact requirements. Not a major issue, but one that can quickly lead to insecurities and incompatibilities if done wrong. And then there are the compatibility issues with existing implementations, which you'll most likely want. Imagine two weeks of pumping your data into OpenSSL only to get -1 back.

Then there are all the general security issues related to web delivery and computing in general. These are fixable to a certain extent, but not completely. Then again, no amount of plugins is going to help you if your users have keyloggers installed, so not being completely secure is just a risk you'd have to accept.

With regards to zipping, you're mostly looking at implementation issues. There are a few JS implementations out there, which I've never tried. Writing one from scratch would be a pain.

The frustrating thing is that all the code you need is in any browser's implementation, just not accessible to JS :( Anyway, if all of this doesn't put you off, send me a message. I'm a free-lancer with a lot of crypto experience and some JS.

Cheers,

Patrick

[Gijs Molenaar]

On 12/22/2011 04:05 PM, Patrick Simpson wrote:
> Hi Gijs,
>
> While I fully agree with tg's comment that you're better off with a
> proven library, I understand what you're trying to do and if you don't
> want any plugins, I don't see any option other than using JS crypto. The
> issues in the links posted by tg are valid, but that is a different use
> case where the server and client need to share a key. As that is not the
> case in your approach, I don't think there are any architectural
> weaknesses to overcome.

> Having said that, you're looking at a lot of implementation issues. For
> starters, I do not know of any actively maintained crypto libraries for
> JS.

I'm under the impression that SJCL is a well written and good maintained
library. But to say this for sure more investigation is needed. For now
I'm using SJCL to encrypt the chunks of a file and upload it.

> There are some AES implementations floating around, but it'd be hard
> to say how many weaknesses they might have without taking a very close
> look. Writing an implementation from scratch is not something you'd want
> to do. Seriously. Even if you get it working correctly in all cases,
> it'll be unbearably slow compared to existing ones.
> Then you're facing the issue that these mostly do block-to-block
> encryption, which is not practically useful for any purpose, so you'll
> want to make them operate in something like CBC or CTR mode, depending
> on your exact requirements.

Yes for my purpose I wanted to make AES distribute over string
concatenation (AES(A) + AES(B) == AES(A + B) but later I realized that
would be a very bad idea (it's block-to-block). These modes and
terminology are on the edge of my encryption knowledge at the moment.

> Not a major issue, but one that can quickly
> lead to insecurities and incompatibilities if done wrong. And then there
> are the compatibility issues with existing implementations, which you'll
> most likely want. Imagine two weeks of pumping your data into OpenSSL
> only to get -1 back.
>
> Then there are all the general security issues related to web delivery
> and computing in general. These are fixable to a certain extent, but not
> completely. Then again, no amount of plugins is going to help you if
> your users have keyloggers installed, so not being completely secure is
> just a risk you'd have to accept.
>
> With regards to zipping, you're mostly looking at implementation issues.
> There are a few JS implementations out there, which I've never tried.
> Writing one from scratch would be a pain.

I would be so happy if I could combine JSZip and SJCL in a simple and
easy way, but probably that is never going to work.

> The frustrating thing is that all the code you need is in any browser's
> implementation, just not accessible to JS :(

Probably we are going to restrict the usage to a specific version of
Google Chrome.

> Anyway, if all of this
> doesn't put you off, send me a message. I'm a free-lancer with a lot of
> crypto experience and some JS.

I'm very happy with your answer, you seem to know what you talk about.
I'm going to think about your and the previous responses and maybe i'll
come back to you.

Thanks,

- Gijs

> Cheers,
> Patrick
>
> On 22 December 2011 15:35, Gijs Molenaar <gi...@pythonic.nl

[Patrick Simpson]

> Having said that, you're looking at a lot of implementation issues. For
> starters, I do not know of any actively maintained crypto libraries for
> JS.

I'm under the impression that SJCL is a well written and good maintained
library. But to say this for sure more investigation is needed. For now
I'm using SJCL to encrypt the chunks of a file and upload it.

That's true actually. I don't know how good it is, but it is actively maintained.

 

Yes for my purpose I wanted to make AES distribute over string
concatenation (AES(A) + AES(B) == AES(A + B) but later I realized that
would be a very bad idea (it's block-to-block). These modes and
terminology are on the edge of my encryption knowledge at the moment.

As a rule of thumb, any operation you can do on encrypted data that doesn't garble your data is wrong ;)

 

> With regards to zipping, you're mostly looking at implementation issues.
> There are a few JS implementations out there, which I've never tried.
> Writing one from scratch would be a pain.

I would be so happy if I could combine JSZip and SJCL in a simple and
easy way, but probably that is never going to work.

I think conceptually it's very simple, there's just a lot of implementation hassle.

 

> The frustrating thing is that all the code you need is in any browser's
> implementation, just not accessible to JS :(

Probably we are going to restrict the usage to a specific version of
Google Chrome.

I think it's not exposed through any of their APIs, not even for extensions.

 

Cheers,

Patrick