-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Zip file encryption is weak #20
Comments
Perhaps I misunderstood the draft (please correct me if I'm wrong!), but I don't believe zip file encryption is being used here? What I understood is that the files are encrypted individually, before being compressed into a single zip archive. The zip archive is not what encrypts them - it's merely a container for the already-encrypted files. That said, if we're concerned that the usage of zip archives may continue to cause this sort of confusion, I might suggest switching to something like |
Well, Zip files do support a certain type of encryption on a per file basis. The draft is a bit unclear there, but I am suggesting not to use this. |
Good, then that should be mentioned though, otherwise it is confusing (at least to me). |
(For context for anyone wondering, I reiterated that the spec isn't using zip file's built-in encryption. I deleted the comment because I thought I had misunderstood the comment I was responding to, hence the missing response.) |
@LikeLakers2 is right, we don't use zip encryption, but rather HPKE as defined in RFC 9180 to encrypt each file individually. We then zip the bundle of encrypted files. That being said, the use of zip is likely to change depending on the protocols response mode in order to handle large payloads. Zip will still play a part in the indirect and self modes, but direct mode might do away with it all together. There are many parts of the specs that could use clearer explanation, this is one of them. As we expand the use of the different response modes and zip's part in them, we'll be sure to be clear that zip encryption MUST NOT be used. |
Thanks, good to see this confirmed. |
In the draft, the CLX is just an encrypted zip file. Encrypted zip files only use weak encryption. I would rather think it should be a tar archive encrypted with some elliptical curve, Iike a PASETO V4 token is. Thanks for your consideration.
The text was updated successfully, but these errors were encountered: