search

transcend-io / conflux

Zip/unzip files of any size in the browser using streams.
MIT License
98 stars 15 forks source link

Password protection #7

Open jimmywarting opened 5 years ago

bencmbrook commented 5 years ago

Are we using this standard?

Since we'll have to choose a content encryption algorithm, I'd strongly recommend we go with AES 256. Seems that the standard only supports the CBC mode of operation, which is fine, but we'll have to be careful to choose cryptographically random IVs.

jimmywarting commented 5 years ago

I would like (if possible) to use web crypto instead of importing any large dependency. that is, if you can encrypt individual chunks.

Like i told earlier, WebCrypto don't support streaming. Would require https doe. so it would make it a https only feature.

Touffy commented 3 years ago

I'm glad I didn't find this project last year. Wouldn't have implemented ZIP myself if I had, and learned wasm ;)

CBC is "cypher block chaining", so you stream by cutting your input into 16-byte blocks (yes, even with AES-256: the "256" is only the key size) and passing the result of the previous block instead of the IV to the AES function for the next block. Easily doable with WebCrypto's primitive (you can use multiples of 16 bytes, of course ; just slice the last 16 bytes of the result to get the next vector).

Touffy commented 2 years ago

Someone requested this feature for client-zip and I spent some time studying the APPNOTE, so I thought I'd leave my conclusions here too.

First of all, implementers of what the APPNOTE pompously refers to as "strong" encryption (as opposed to the older encryption scheme with antique algorithms and cleartext metadata) are asked to contact PKWare for a license. Their encryption scheme is so convoluted that they feel it should be patented. Personally, I think PKWare should pay us for the time spent reading that spec.

Encryption with password derivation seems doable (just very complicated since you'll be encrypting each file with its own AES key and salt, then you'll encrypt the central repository, and also you have to include some Zip64 stuff even if the archive isn't bigger than 4 GB, just because the basic format couldn't be adapted to encode the encrypted metadata). The zip programs I have on hand (the default macOS utility, and Keka which is based on 7Zip) both support password-protected files.

The APPNOTE also defines a certificate-based encryption method, where the AES keys are random and wrapped with the RSA public keys of each intended reader. It's more secure, but even more complicated than password derivation, and I can't find an open-source program capable of understanding that encryption. For me, the whole point of doing Zip files instead of, say, tar+gzip+PGP which is far more sensible, was that Zip is more widely supported. So, I see no reason to bother with the RSA encryption.