549
Order (programming.dev)
top 31 comments
sorted by: hot top controversial new old
[-] Mic_Check_One_Two@reddthat.com 118 points 1 year ago

Chaotic evil is encrypting, compressing, then encrypting again.

[-] UtMan1988@lemmy.world 50 points 1 year ago

Then decompress after. Let fear be your cypher.

[-] InfiniteStruggle@sh.itjust.works 32 points 1 year ago

When playing football, to keep the socks from riding down our legs, we used to put loose rubber bands on top of them, near the top of the sock. Then to avoid the rubberbands from riding up above the sockline, we used to fold the sock over the rubberbands downwards. Then to avoid the fold from being undone during play another rubberband had to be put on top of the folded part.

Sounds similar to this. Just thought it was notable.

[-] UtMan1988@lemmy.world 11 points 1 year ago

So, when you foot turns purple from the multitude of rubber bands, did it make you play any better?

Nope. It was uncomfortable and I'd argue we played worse because of the discomfort. We were also pretty bad at the game so I think we wanted the socks with rubber bands as a scapegoat instead of accepting we were shit.

[-] Anticorp@lemmy.ml 5 points 1 year ago* (last edited 1 year ago)

Why didn't you guys just buy good socks? Or those sock suspenders?

That costs money

[-] yum13241@lemm.ee 1 points 1 year ago

That's like md5(sha512("somefile.blah"))

[-] corytheboyd@kbin.social 90 points 1 year ago

The encryption: base64 encoding

[-] Aceticon@lemmy.world 37 points 1 year ago* (last edited 1 year ago)

Nah, you just XOR the data with itself and it becomes uncrackable.

Also after encryption like this the result can be compressed down to 4 bytes as long as the data is not larger than around 4Gb, 8 bytes if you need more.

[-] CoderKat@lemm.ee 17 points 1 year ago* (last edited 1 year ago)

My god, that is absolute perfect encryption (completely uncrackable by brute force) and compression. This is genius and I'm gonna switch all my data to this encryption scheme. Now I just need somewhere to store the decryption keys...

[-] LostXOR@kbin.social 12 points 1 year ago

You are truly a mastermind.

[-] towerful@programming.dev 9 points 1 year ago

What an excellent username for such a chain of comments

[-] kakes@sh.itjust.works 10 points 1 year ago
[-] koper@feddit.nl 24 points 1 year ago

The real question is do you encrypt-and-sign or sign-and-encrypt?

[-] Eufalconimorph@discuss.tchncs.de 32 points 1 year ago

Encrypt then sign. Always authenticate before any other operations like decryption. Don't violate the cryptographic doom principle.

[-] tvbusy@lemmy.dbzer0.com 30 points 1 year ago

Encrypt then sign. Verification is often much faster than (or at worst as fast as) decryption. Signature can also be verified without decryption key, making it possible to verify the data along the way.

[-] bioemerl@kbin.social 12 points 1 year ago* (last edited 1 year ago)

Don't compress encrypted data since it opens you up to attacks like CRIME, unless it's at rest and static data.

[-] Mubelotix@jlai.lu 16 points 1 year ago

Encrypted data cannot be compressed anyway

[-] DrQuint@lemmy.world 0 points 1 year ago

It can. Just not lossless. Which it means it can't.

[-] bastian_5@sh.itjust.works 15 points 1 year ago

If that's true, what's to stop someone else from just compressing it themself and opening the same attack vector?

[-] harbor9964@lemmy.world 4 points 1 year ago

Compressing what themselves? Compress then encrypt leaks information about the data being encrypted if an adversary can affect some part of the data being encrypted. If the data is at rest and repeated encryptions are needed , then this isn't a concern.

[-] bastian_5@sh.itjust.works 13 points 1 year ago

Compress the encrypted data. You're talking about encrypting compressed data, this was talking about compressing encrypted data.

[-] bioemerl@kbin.social 2 points 1 year ago

Technically you would be fine to compress the encrypted data, but encrypted data doesn't compress well so it's not really worth your time

[-] bastian_5@sh.itjust.works 1 points 1 year ago

Depends on if you're using lossless or lossy compression. Lossless compression will usually make it bigger, because it relies entirely on data being formatted so their are common patterns or elements that can be described with fewer parts. Like, an ok compression algorithm for a book written in English and stored as Unicode would be to convert it to ASCII and have a thing that will denote Unicode if there happens to be anything that can't convert. An encrypted version of that book would look indestinguishable from random characters, so compressing it at that point would just put that Unicode denoter before every single character, making the book end up taking more space.

[-] bioemerl@kbin.social 1 points 1 year ago

The problem is that when you compress before you encrypt, the file size becomes a source of data about the contents. If an attacker has control of part of the data - say - a query string, they can use that to repeatedly add things to your data and see how the size changes as a result.

[-] bastian_5@sh.itjust.works 1 points 1 year ago

So it sounds like compression before encryption should only be done in specific circumstances because it can be a security issue depending on use case, but encryption before compression should never be done because it will almost always increase the size of the file

[-] astarob@sh.itjust.works 1 points 1 year ago

Don’t know about gz but zip files can be encrypted using passwords

this post was submitted on 10 Aug 2023
549 points (98.1% liked)

Programmer Humor

19187 readers
1100 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 1 year ago
MODERATORS