183

Is there such a thing? Absolutely. Feeding malicious input to a parser is one of the most common ways of creating an exploit (and, for a JPEG, "decompression" is "parsing"). Is this description based on some real exploit? It might be based on the Microsoft Windows GDI+ buffer overflow vulnerability: There is a buffer overflow vulnerability in the ...


88

First of all, that multi-encryption scheme is ridiculous. The algorithm used by 7-Zip is AES-256 which is considered secure. But if someone would find a flaw in it which would make it breakable, then they would likely be able to break all your encryption layers with equal effort. So either you trust the encryption algorithm used by 7-Zip, then one ...


54

Very good question. Yes, by default, WinRAR leaves traces of temporarily extracted files. WinRAR does indeed create temporary files when opening them directly from the archive. It also performs a normal deletion once WinRAR is closed. However, deleted files do physically stay on the disk after you delete them. Normal delete operations only delete the file ...


53

Agreeing with others to say yes this is totally possible, but also to add an interesting anecdote: Joshua Drake (@jduck), discovered a bug based on a very similar concept (images being interpreted by the OS) which ended up being named "Stagefright", and affected a ridiculous number of Android devices. He also discovered a similar image based bug in libpng ...


38

This is over engineering on a scale I've never seen. This is a BAD THING ™ because it increases the complexity of your solution without adding any security benefit. The encryption mechanism is either safe, or it is not. You will not be more protected by encrypting multiple times. If the encryption is secure, it's useless to add additional layers of ...


27

First off, breathe. Encryption efforts often fails if you forget to breathe. Something about going unconscious causes us to have a hard time encrypting things! Second, it sounds like you are in need of a threat model. A threat model describes what sort of adversaries you are worried about facing. Without a threat model, all security is security theater ...


17

I read that this should be avoided because of CRIME/BREACH attack, is this correct? It depends. The CRIME attack is already mitigated in current browsers in that they don't use TLS compression and have special handling of contexts in HTTP/2.0. BREACH is only relevant in the context of HTTP level compression if the following two conditions both apply at the ...


16

Encrypted data should be indistinguishable from random noise. Random data cannot be compressed. Therefore, compress data first and then encrypt it.


14

Encryption leaks data length: for any given input message, the encrypted output will have a length which will be close to that of the input message. If using a padding-less encryption mode (e.f. CFB, as used in the OpenPGP format that PGP implements), then the cleartext data length can be recovered exactly. This is a property common to all encryption systems,...


13

Unrealistic? There was recent critical bug in font definition parsing: https://technet.microsoft.com/en-us/library/security/ms15-078.aspx and libjpeg changenotes are full of security advisories. Parsing files[1] is hard: overflows, underflows, out of bounds access. Recently there were many fuzzing tools developed for semi-automatic detection of input that ...


13

File compression utilities like Winrar or ZIP or 7zip encrypt the password and store it inside the archive. I don't know where you got this information (claims without source are always bad) but I'm sure you got it wrong. This would not make any sense and the question would also be which key would then be used to encrypt the password. With ZIP you can look ...


12

No, what you are trying to accomplish is impossible. Encryption tries to keep information confidential. For this it takes one input message out of all possible input messages and encrypts in such a way that the output doesn't leak any information about the input message. Obviously you do not want that messages encrypt to the same output because in that case ...


12

Compression before encryption is a problem if the attacker can control parts of the transferred data and then use the detectable compression ratio (i.e. amount of transferred data vs. original data) to make conclusions about some of the traffic. This was in TLS used within BREACH and CRIME attacks to infer cookies and CSRF tokens. Making such attacks work ...


10

Encrypting does not inherently make a file larger. However, in practice, encrypted files are larger than their non-encrypted counterparts for a number of reasons: Symmetric ciphers in current use have the property that every possible ciphertext can be decrypted to a plaintext, or in other words, if somebody tampers with the encrypted file, it can still be ...


10

support the new Brotli compression algorithm over HTTPS only. In theory yes. In practice Chrome will currently accept brotli compressed answers with plain HTTP too, even though it does not announce support for brotli in plain HTTP. Firefox only supports answers in HTTPS. If my understanding of BREACH (and the related CRIME attack) is correct, compression ...


9

How safe is it to decompress untrusted files Just looking at the CVE's for unzip you will find several possible code executions, modifying the permissions of existing files, overwriting arbitrary files outside the current directory.... The CVE list for unrar is shorter but includes also code execution. What steps can be taken to minimize the threat ...


9

According to Wikipedia: "... G.711 passes audio signals in the range of 300–3400 Hz and samples them at the rate of 8,000" Nyquist criteria limits the top frequency to be less than half the sample rate, or less than 4 KHz in this case. Further G.711 filtering apparently cuts this down to 3.4 KHz top. A quick impromptu experiment Laying the ...


7

If an attacker can trick you into repeatedly encrypting (and consequently compressing) nearly the same plaintext over and over again, then I suspect that such an attack might be possible, but getting into those circumstances seems unlikely. (You'd need plaintext that combines something secret to the attacker and something attacker-controlled as well.) ...


7

The source of the "1032:1" figure is given on the zlib site where it is told that: The limit comes from the fact that one length/distance pair can represent at most 258 output bytes. A length requires at least one bit and a distance requires at least one bit, so two bits in can give 258 bytes out, or eight bits in give 1032 bytes out. A dynamic ...


6

This isn't possible/feasible, for two reasons. Compression doesn't "work" on random data - it won't actually significantly reduce the size of your data, and in fact, may increase the size. A one time pad must be greater than or equal in length to the data being encrypted. So if you're using the "remaining," unused part near the end of your one time pad to ...


6

CRIME and BREACH are attacks on the client. Their setup is that some hostile code is running in the client with limited capabilities (i.e. it is Javascript in a Web page). The attacker also controls the external traffic of the victim: he can inspect it, but also block it. This limits what the server actually sees. In both cases, the hostile Javascript will ...


6

I've been pondering this and I don't think your networking department is justified in this opinion. It does all depend on your threat model, but given the threat model of "hacked content to slip through the clients antivirus scanner", this opinion makes no sense. First, let's drop minification, because it's in plain text. There is no security reason or ...


6

The password is required to decrypt the archive, so storing a copy of the password inside the archive would be pointless - anyone who could decrypt the archive already has the password. The only things that get stored unencrypted in the archive are the encryption type, and perhaps the file structure and file attributes. Perhaps you're confused about how ...


6

To exploit the compression, as in CRIME/BREACH, the attacker must perform a chosen-plaintext attack. In other terms, this means that the attacker must already have an exploit on your computer: Either a RCE, in which case your VPN, encrypted or not, will not help you as you are already pwned; or a CSRF or similar, which is fairly uncommon on classical ...


5

RAR uses AES256 for encryptionsource, thus the question is whether AES is cryptographically resistant to a known-plaintext attack. At present there is no known method that allows retrieving AES encryption key given unlimited number of plaintext inputs and corresponding outputs faster than brute-force. Although there is no proof that it is impossible. See ...


5

Reversible hashes aren't compression Even hashes which we can reverse cannot be used as a compression. Assuming that we could reverse sha256 wouldn't make current compression obsolete, because there are infinitely many large files, but finitely many (2^256) sha256 values, so infinitely many large files will have the same sha256 hash - this is known as the ...


5

There's no contradiction here as long as you consider the issue in probabilistic terms. For example: The reason I'm confused is that I thought that all encryption was supposed to do is make it as difficult as brute forcing the key to go from the cipher text to the plain text. It seems to me like there could be an AES key that would produce an all 0 ...


5

It likely won't make a difference. The reason being is that the vast majority of traffic going through your VPN tunnel will already be encrypted at a different OSI layer. So the traffic that you see in your VPN tunnel will have very high entropy, and high entropy cannot be compressed. As a result, enabling compression will likely not change anything at all, ...


4

If your site is vulnerable to BREACH, an attacker can guess anything in the body of the response one character at a time. The attacker does multiple requests, one per guess, and can see if he guessed correctly. For example, the attacker may try these guesses: csrftoken=a csrftoken=b csrftoken=c etc. After a while he figures out the first character of the ...


Only top voted, non community-wiki answers of a minimum length are eligible