Timeline for Is there an existing cryptography algorithm / method that both encrypts AND compresses text?
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 12, 2020 at 22:24 | comment | added | David Cary | @supercat: Yes, some more code operators use "cut numbers", which are (as you said) "shorter representations for digits" -- "Where did cut numbers come from"; and "CW Shorthand - Cut Numbers"; etc. | |
| Apr 13, 2017 at 12:48 | history | edited | CommunityBot |
replaced http://crypto.stackexchange.com/ with https://crypto.stackexchange.com/
|
|
| Oct 23, 2015 at 22:41 | vote | accept | Grant Miller | ||
| Oct 22, 2015 at 16:03 | comment | added | supercat | @IlmariKaronen: That sounds similar to what I had in mind, though that raises another interesting question: since Morse Code optimizes the pulse patterns for letters at the expense of those for digits, did any operators use shorter representations for digits when sending non-alphabetic transmissions? If a dot or letter space is one unit and a dash is two, digits will take 6 to 11 units to send, with an average of 8.5, but there are eleven patterns which are five units or less (including the letter space). | |
| Oct 22, 2015 at 10:23 | comment | added | Ilmari Karonen | @supercat: The closest thing I can think of, off the top of my head, is the use of straddling checkerboards in some WWII-era and later Soviet ciphers. But those ciphers had numerical ciphertext anyway, so they weren't particularly quick to transmit by Morse anyway. | |
| Oct 22, 2015 at 2:35 | comment | added | supercat | One thing I've wondered about is whether anyone during World War II ever tried to avoid the "opposite" issue when sending encrypted messages over Morse code; I would think transmission efficiency could be improved by replacing certain common pairs of letters (e.g. EE, ET, TE, etc.) with letters like Q, W, or Z and vice versa before encryption and again after, since sending a single Q, W, or Z takes longer than sending EE, ET, or TE. | |
| Oct 22, 2015 at 2:00 | comment | added | Cort Ammon | One workaround: if the input has fewer bits of entropy than total bits (such as if one or more possible inputs are known to simply not occur), then it is possible to compress the bits, then encrypt them, and meet the OP's needs. However, it is never possible to do so beyond the number of bits of entropy in the original message (as the OP worded the scenario, one doesn't get to make the assumption needed for my little workaround, but it seemed worth mentioning as a loophole) | |
| Oct 21, 2015 at 19:52 | comment | added | corsiKa | By definition, if you could compress encrypted data, that would be a massive indicator of a flaw in the encryption. | |
| Oct 21, 2015 at 10:10 | history | answered | Ilmari Karonen | CC BY-SA 3.0 |