9

I'm doing clientside encryption for a file transfer protocol (so even the server won't know what the file is.) My current method is to import the file into a browser filesystem, break up the file into 1 MB chunks, store each chunk in memory, encrypt each chunk with AES, then concatenate all the chunks and upload. This prevents the memory from getting overloaded, but it's rather inefficient. Is there a better method? A way to encrypt a whole file in a browser filesystem? Thanks!

Raphie
  • 153
  • 1
  • 5
  • Encryption schemes like AES typically work in chunks anyway, so I'm not sure there's much benefit (if any) to chunking the file yourself. Have you tried using [SJCL](http://crypto.stanford.edu/sjcl/) on the whole thing and seeing how well (or not) it works for you? – Matt Ball Dec 02 '11 at 03:03
  • The chunking is to prevent RAM overload since loading a large file would crash the page. – Raphie Dec 02 '11 at 03:07
  • Can you define a 'large' file? – Will Bickford Dec 02 '11 at 03:26
  • Possible duplicate: http://stackoverflow.com/questions/793812/javascript-aes-encryption Also take a look at http://crypto.stanford.edu/sjcl/ which was linked from there. – Will Bickford Dec 02 '11 at 03:28
  • 100+ MB would crash the page. I want this to be able to work with 1 GB+ files. – Raphie Dec 02 '11 at 03:31
  • Specifically, I'd like to encrypt files in the [filesystem](http://www.html5rocks.com/en/tutorials/file/filesystem/). – Raphie Dec 02 '11 at 03:35
  • Are you aware this won't really help? Unless your users read the source each time they use it, you or an attacker could replace the Javascript code with one that doesn't encrypt at all, and they'd have the user's data in plaintext. – Nick Johnson Dec 06 '11 at 23:11
  • 3
    Did you ever find a solution for this @Raphie? – Vineet Aug 12 '17 at 14:25

1 Answers1

1

The use of encryption or any other cryptographic primitive should not be made without first creating a credible threat model. What threat to your application do you plan on preventing by using JavaScript based encryption? If the threat is someone on the network, then we have amazing tools to prevent network based attacks - we call it HTTPS with TLS, and its free to use - and an alternative cannot be made in JavaScript..

Some experimental "end-to-end" (e2e) chat applications use JavaScript based encryption. But this "promise not to peak" encryption doesn't actually protect clients from the server - malicious JavaScript can access these keys and the server chooses not to read them - this isn't security.

Any local attacks (or RCE), or cross-domain attacks (XSS) would not be prevented by JavaScript based encryption - also HTTPS can't prevent these attacks. The lack of a creditable threat actor is why encryption is never done by the client - but rather is commonly performed by application server or backend database to encrypt sensitive fields at rest. This is because the backend can keep secrets safe from untrusted clients.

If you want to better understand how developers write secure applications consider reading the OWASP Top 10 ("JavaScript Encryption" is not featured.)

rook
  • 66,304
  • 38
  • 162
  • 239
  • While related to the question being asked I don't think it's really an answer to his question. You assume that he is encrypting for security but he could be encrypting purely for privacy reasons. – spazworm Jul 22 '20 at 04:05
  • IT Security is commonly considered to consist of Confidentiality, Integrity and Availability (although I personally think that that's a limiting concept, but let's roll with it). Encrypting for "privacy" is directly linked to confidentiality. So above comment makes very little sense to me; why would you ever encrypt if not for a security reason? – Maarten Bodewes Jul 29 '20 at 13:27
  • Is this answer Still valid in 2022 with webcrypto api? Im Aldo trying to för something similar. Or is it not safe to encrypt in client. – Tan Apr 01 '22 at 19:06