37
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 19 Nov 2023
37 points (97.4% liked)
Open Source
31358 readers
224 users here now
All about open source! Feel free to ask questions, and share news, and interesting stuff!
Useful Links
- Open Source Initiative
- Free Software Foundation
- Electronic Frontier Foundation
- Software Freedom Conservancy
- It's FOSS
- Android FOSS Apps Megathread
Rules
- Posts must be relevant to the open source ideology
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
- !libre_culture@lemmy.ml
- !libre_software@lemmy.ml
- !libre_hardware@lemmy.ml
- !linux@lemmy.ml
- !technology@lemmy.ml
Community icon from opensource.org, but we are not affiliated with them.
founded 5 years ago
MODERATORS
Isn't that also true of an encrypted checksum, though? For some plaintext block q there is a checksum r, but the attacker can only see and modify the encrypted q (Q) and encrypted r (R). How any change to Q would modify q (and R to r) can't be known without knowing the encryption key, but the attacker would need to know that in order to keep q and r consistent.
Possibly the source of any confusion here is when the encryption and when the compression takes place? Maybe some more details about how you are using xz and encryption would help.
As far as I can tell, xz doesn't do anything with signatures or encryption, but it does perform checksums like you stated, which is very cool and I'm glad you shared this.
Edit: I am re-reading your post above. You are compressing with xz, then encrypting, got it. So yes, if any part of the payload is tampered with, then it would be detected by the decryption, depending on the algorithm, or by the decompression because of the checksums like you said. Sorry for the confusion! You've got it all straight lol.