0

If I use different encryption methods but provide no indication in the ciphertext output of which method I use (for example, attaching an unencrypted header to the ciphertext) does that make the ciphertext harder to decrypt than just the difficulty implied by, for example, the keylength? The lack of information as to what encryption protocol and parameters to use should add difficulty by requiring a potential decrypter to try some or all the various encryption methods and parameters.

  • possible duplicate of [Why is security through obscurity a bad idea?](http://stackoverflow.com/questions/533965/why-is-security-through-obscurity-a-bad-idea) – Andy Hoffner Jun 01 '15 at 22:49
  • If an attacker has access to your software, then it can be reverse engineered in which case hiding the encryption method doesn't increase the security. – Artjom B. Jun 01 '15 at 23:06
  • I don't think it a matter of obscurity unless not knowing the encryption key is also obscurity. I am assuming the decrypter doesn't have access to anything but the ciphertext. – Stephen Marney Jun 02 '15 at 00:07

1 Answers1

1

Well, in general you should not rely on information in the algorithm / protocol itself. Such information is generic for any key you use, so you should consider it public knowledge. OK, so that's that out of the way.

Now say you use 16 methods and you somehow have created a protocol that keeps the used encryption method confidential (let's say by encrypting a single block half filled with random and a magic, decrypting blocks at the receiver until you find the correct one). Now if you would want to brute force the key used you would need 16 more tries. In other words, you just have increased the key length with 4 bits, as 2 ^ 4 = 16. So say you would have AES-256 equivalent ciphers. You would now have equivalent encryption of 256 + 4 = 260 bits. That hardly registers, especially since AES-256 is already considered safe against attacks using a quantum computer.

Now those 4 bits comes at a very high price. A highly complex protocol using multiple ciphers. Each of these ciphers have their weaknesses. None of them will have received as much scrutiny as AES, and if one breaks you are in trouble (at least for 1 out of 16 encrypted messages). Speeds will differ, parameters and block sizes will differ, platforms may not support them all...

All in all, just use AES-256 if you are not willing to accept AES-128. If you must, encrypt things twice using AES and SERPENT. Adding an authentication tag over IV & ciphertext probably makes much more of a difference though. See this answer by Thomas over at the security site.

Try GCM or EAX mode of operation. Much more useful.

Community
  • 1
  • 1
Maarten Bodewes
  • 90,524
  • 13
  • 150
  • 263
  • "In other words, you just have increased the key length with 4 bits, as 2 ^ 4 = 16." Yes that answers my basic question. And, as you say, not worth the effort. – Stephen Marney Jun 02 '15 at 18:57