Tag Info

Hot answers tagged

11

According to 7-Zip, Use ZipCrypto, if you want to get archive compatible with most of the ZIP archivers. AES-256 provides stronger encryption, but now AES-256 is supported only by 7-Zip, WinZip and some other ZIP archivers. So really there is some balance to be played with. Do you require better security at the sacrifice of compatibility or more ...


11

There is at least one way in which compression can weaken security; it has to do with the fact that essentially all methods of encrypting arbitrarily long message will inevitably leak information about the length of the input. The only way to avoid this leak is to pad all messages to a constant length before encrypting them — but if the messages are ...


9

Technically, if you use a cryptographically secure encryption algorithm with a fresh random key in a confidentiality mode such as (full block) CFB, you don't have to worry about the redundancy of the plain text, since the cipher + mode combination is supposed to be secure even if significant parts of the plain text are known to the adversary. If the cipher ...


9

Well, your definition of entropy is known as Kolmogorov complexity, and it's not so much that it is incorrect, as it is that it is inapplicable to what gzip does. For example, the value $\pi$ can also be generated by a short program; however, if you attempt to compress a 2.2Mbyte sample of the binary expansion, you'll also find that gzip will also not be ...


5

Yes, a ciphertext of a bulk encryption algorithm normally should not be compressible to less than the plaintext size¹ (at least, if the compression function does not know the encryption key), other than in some corner cases which will occur only with negligible probability (like you hitting the one plaintext which will encrypt to the all-zero-string). ¹Of ...


5

Short answer: “No”. The latest research shows that compression actually harms security. "Reducing redundancy" is an outdated concept from the late 20th century. The intuition was that if our ciphers turned out to be weak, we might avoid a practical loss of confidentiality by giving attackers less information to work with. For example, in the following ...


4

Compressing the data increases the security a number of ways. It reduces an attacker's ability to affect the decrypted output by flipping ciphertext bits. It removes regular patterns in plaintext (it might create other regular patterns, but they aren't directly the plaintext). There are a number of attacks on OpenPGP that are thwarted by compression. Most ...


4

Well, the data structure of a compressed data is whatever the decompression algorithm needs to be able to reconstruct the original data (assuming a lossless compression method; it's an approximation of the original data if we're talking about a lossy compression method). That might not be the answer you're looking for; you might be looking for details on ...


4

Also any twin-encryption algo-s around?: by which I mean, suppose I have 2 data strings (alphanumeric only, say for now) -- Using them both, and an algo, I produce the encrypted output - I take in a pair, and produce a pair. The procedure is algo-based and not key-based. One fundamental fact (or perhaps I should say "assumption") in cryptography is that ...


4

Unlike some crypto tasks like encryption+authentication combining compression+encryption have nothing in common/non synergies, so combining them into one algorithm offers no advantages. In practice this means you first compress your data, and then encrypt it, because encrypted data is uncompressable. That way you cleanly separated the separate concerns, and ...


4

Daniel J. Bernstein mentioned your way of compressing RSA public keys in his paper "A secure public-key signature system with extremely fast verification". The naive way you outline roughly doubles the work for each extra bit. If there were a better method which did not run very slowly then it could be repurposed as a factoring algorithm. So if it were ...


3

For cryptographic hash functions we usually want to avoid collisions as much as possible (and even more we want to avoid any way to get from the output back to the preimage). So what you want certainly is not a cryptographic hash function, but something else. On the first look, something like a CRC (cyclic redundancy check) could fit your bill. These have ...


2

Actually, it appears that we can do a bit better by using an unbalanced RSA key; that is, one composed of two primes of different sizes. For example, suppose we have a 512 bit p and a 1536 bit q; to generate a key, we can select a random 512 bit prime p, and then for q, we search for a prime in the range $(C/p, (C+2^k)/p)$ (where $C$ is our 2048 bit ...


2

Read about the CRIME and BREACH attacks. They are the classic example where compression before encryption can leak information about the input. The length of the compressed data leaks information about the contents of the data itself. See also http://security.stackexchange.com/q/19911/971 and http://security.stackexchange.com/q/20406/971 and ...


2

You are basically using gzip to convey the length of the given message. As long as your implementation of AES-CBC is secure (e.g. by using a random IV) then the given scheme should be secure against padding oracle attacks. This is easy to prove as there is nothing that removes the padding from the plaintext. CBC padding in general does not add any security ...


2

This hash function has a 64-bit output. Therefore, it is not collision-resistant. It is easy to find a collision in any hash function with a 64-bit output. Since this appears to be a homework, I'm going to leave it to you to figure out why this is the case. In general, please don't just post a homework question and expect us to solve it for you. We're ...


2

If you have known plaintext, namely one input file that is known in its entirety, this is trivial to break. So I'll explore methods that might lead to a break, if you don't know what's in the input file that was compressed. I suggest that you start by analyzing the DEFLATE stream format carefully (see also these handy notes). This will probably help you ...


1

The problem is not with compression and encryption, it is with the protocol that is being used, and the type of data being compressed (or not) prior to encryption. The most damning leaks are on protocols that were either designed to be compressed without encryption, or encrypted without compression. The best example I have is VOIP systems that use a ...


1

Selective format-compliant JPEG encryption as you are trying to do it is a great idea, but it won't work... not like this. To keep the reasons short and simple: JPEG uses lossy compression (and even lossier recompression). If you really want to create a format-compliant implementation, you'll have to take care that you're independent of any ...


1

It won't compress because data that is encrypted with AES becomes pseudo-random-like and thus as close to maximum entropy as possible. As you pointed out, the clear text input is low entropy. Additionally, entropy can be used as a way to detect clear text (given the clear text isn't pseudo-random itself). The output entropy from failed AES decrypts ...



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