1
$\begingroup$

On top of my mind comes caesar cipher, but that is not really secure

so what is the most secure encryption algorithm that doesn't affect entropy or even lowers it?

I know this might not be as secure as normal encryptions, but I'm asking about what is the most secure among these types of encryptions?

basically I have a series of bytes, and I want to encrypt them in a way that a machine that only checks the entropy to detect encryption gets bypassed. so basically this encryption doesn't affect the entropy, or even better if possible, lowers it.

I thought maybe I can just replace each byte with another, but was wondering is there any better method? keep in mind that security is my second priority and keeping or lowering entropy is my number one priority

$\endgroup$
  • 1
    $\begingroup$ If you distinguish AES from PRP, you will be famous! $\endgroup$ – kelalaka Oct 2 at 13:40
  • 1
    $\begingroup$ Welcome to crypto.stackexchange - Can you edit your question to clearly define what you mean by "secure"? Does the information need to remain confidential? Who is the adversary and what are the adversaries capabilities? Are they limited exclusively to examining the output of this "entropy checking" machine, or can they analyze your scheme and try to construct distinguishers based on that knowledge? Do they have known/chosen plaintexts? Without this kind of information, answering this question will not be easy/useful. $\endgroup$ – Ella Rose Oct 2 at 15:05
  • $\begingroup$ @EllaRose i edited the title, and yes they only examine entropy of a series of bytes to check if its encrypted or not, usually if its above ~7.1 they say possibly encrypted so i need to keep it below 7 $\endgroup$ – Max Oct 2 at 15:21
  • 1
    $\begingroup$ @Max Keep in mind that all the classical methods are dust in the wind--Caesar's cipher, Vigenere, columnar transposition, autokey, etc.--so none of that is what you are after; that is, unless you go to some extraordinary effort. Don't think that Caesar's cipher counts for anything more than stopping your little sister. But the one-time pad is a horse of a different color. $\endgroup$ – Patriot Oct 2 at 15:32
  • $\begingroup$ Encryption requires decryption. As what you put in is the same as what you get out, you cannot lower the entropy of the ciphertext, you can only increase it (through the key and - for multiple messages - the IV). $\endgroup$ – Maarten - reinstate Monica Oct 2 at 17:06
1
$\begingroup$

This seems pretty simple if your 'isEncrypted' distinguisher looks for a cipher text entropy rate in excess of 7 bits byte. But it's not exactly an encryption. Just hex encode it.

All good cipher text is computationally indistinguishable from perfectly pseudo random. Take the most securely encrypted cipher text from any decent algorithm. It will be 8 bits/byte if occupying all the bits within a byte. Then hex encode it to ASCII base 16. You now need two bytes to encode any single original byte of cipher text. Ergo the entropy rate has been halved to only 4 bits/byte and you still maintain maximum security. Your message would of course get correspondingly longer.

In extremis, go to UTF-32 binary encoding which could just be a series of two really funky characters. Perhaps two Egyptian Hieroglyphs of your choice, each occupying 4 bytes. Mean entropy rate = 0.25 bits/byte.

$\endgroup$
  • 1
    $\begingroup$ Base64 is 6 bits per byte, better compression $\endgroup$ – Richie Frame Oct 2 at 23:30
  • $\begingroup$ @RichieFrame You're correct of course in terms of rates. I didn't mention it as I hate it. It's difficult to read and the worst invention since signed bytes in Java. Signed bytes? $\endgroup$ – Paul Uszak Oct 6 at 12:05

Not the answer you're looking for? Browse other questions tagged or ask your own question.