Skip to content
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

Open
bjorndm opened this issue Oct 17, 2024 · 6 comments
Open

Zip file encryption is weak #20

bjorndm opened this issue Oct 17, 2024 · 6 comments

Comments

@bjorndm
Copy link

bjorndm commented Oct 17, 2024

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.

@LikeLakers2
Copy link

LikeLakers2 commented Oct 17, 2024

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 .tar.gz (a common container format that does not have built-in encryption). This would make it clearer that the encryption is done entirely separately from storing them in the containing archive.

@bjorndm
Copy link
Author

bjorndm commented Oct 17, 2024

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.

@bjorndm
Copy link
Author

bjorndm commented Oct 18, 2024

Good, then that should be mentioned though, otherwise it is confusing (at least to me).

@LikeLakers2
Copy link

LikeLakers2 commented Oct 18, 2024

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.)

@Progdrasil
Copy link
Contributor

@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.

@bjorndm
Copy link
Author

bjorndm commented Oct 23, 2024

Thanks, good to see this confirmed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants