Encryption and/ as file compression

Edi

Im not exactly sure how encryption works, but, I think, it basically just scrables the alphabet, if you will. So somthing like "dusk" would become "ftjo" if red withot the decryption key. (of course, it is more complicated and in binary, but still..) Right?

So.. if so, and if encryption keyy is generated randomly, is there a chance that something like "dusk" would actually read as "dawn" when scrabbled?

Assuming that this is at least somewhat correct, I will ask this: is it possible to use this effect in our advantage?
By making the encryption key not-random, by calculating what encyption key would be necessary for an existing file to be red as something completely else, but readable, when red with the key and creating/ saving the key instead of the new file we want to save?
How large could that kind of key be, if possible at all?
/brainstorm

jhae2.718

Modern cryptography is based heavily on Shannon's information theory.

Basically, there are two main principles: confusion and diffusion. Confusion is the scrambling most people think off, while diffusion aims to make the frequency distribution of ciphertext as uniform as possible.

There is an information-theoretic secure cipher called a one-time pad which XORs (or adds modulo 26 if you're doing it by hand) a true random key with the plaintext to produce ciphertext. You can only use a key to encrypt a single message. Theoretically, every possible key is equally likely and thus any ciphertext could be the result of arbitrary plaintext. (You might ask why one-time pads aren't used all over the place. The answer is that, in practice, they're almost impractical to use. Also, defining what a truly random key is is not a trivial task. And, if you reuse a key it is trivial to extract both messages.)

What you're describing is something that comes up every now and then when discussing plausible deniability. The idea is that, having two possible decryptions, one can be the actual message and the other a "duress" message that would be less sensitive/condemning, though still enough not to arouse suspicion. This is trivially easy with a one time pad. Simply write your "duress" message and XOR it with the ciphertext. The result is your fake key.

In the end, for most use cases it turns out that this is probably not necessary. Modern cryptography is very, very good, and is perhaps the strongest link of the security "chain". We are in fact much better at the mathematics and algorithms of cryptosystems than we are at actually implementing them. "Side channel attacks" like recording the times it takes to complete processor operations or the power usage of a machine can allow an attacker to get at a message with considerably less effort than actually breaking the cipher. Additionally, software has bugs that may leak key information or that may have even been backdoored to record encryption keys -- very few people check, or even know to check, their software to see if it's been tampered with.

Edi

To be clear, I dont want it to be crypted (secure) and compressed. Im just interested if files can be stored that way (compressed) and how large would that key be. .. for, you know, compressing information on storage devices.

jhae2.718

I don't see any benefit over conventional compression algorithms. I mean, theoretically you probably could, but why?

phinds

Compression has nothing to do with encryption. Compressed files can be encrypted or not. Compression does not use a "key" so much as it just uses a compression algorithm. Google "Huffman encoding" for example.

Edi

I know compression does not use key, but, I guess, im not talking about usual compression. First responce, about "duress" mesage, got the idea.

Edi

Well, I was thinking something along the lines of this:
If you can actually have any sequence of bits (1 and 0) red as usable information/ file using a specific key, then you could create a file system where the only information that is saved on memory module is - length of the sequence to be generated[*] and the key.[*] The sequence would be pre-programmed in OS, a simple binary counting system, for example, which could be generated as long as needed. Telling to generate 1 TB would take mere 104 + a few bits marking the start and end of command.
The key would be made when file is created.

.. how large could that kind of key be for a file of x size?

rcgldr

Normally files that are compressed and encrypted are compressed first then encrypted. Part of the point of encryption is to make the compressed data appear more "random" which would interfere with compression algorithms. As mentioned above, compression doesn't use a "key", although it may include a "huffman" encoding table. For example, wiki includes an article on "deflate" compression algorithm:

http://en.wikipedia.org/wiki/DEFLATE

Edi

Well, yes, but what I am talking about is a theoretical new system. It is described above.
A key could be used to read string of bits, that are generated by computer. (binary counting string or something else, that any computer can generate as long as needed)

NemoReally

I doubt whether key length would be the issue; what you're describing would effectively be finding a "Shakespeare's Monkey" key for a conventional encryption algorithms (I also doubt that a 'universal' key would be possible). It would probably require a new encryption algorithm that would, say, have to ensure that the result was a proper English (Russian, Chinese, German, Latin, whatever) sentence.