0
$\begingroup$

This page on Wikipedia states

"Brute-force attacks can be made less effective by obfuscating the data to be encoded making it more difficult for an attacker to recognize when the code has been cracked or by making the attacker do more work to test each guess."

This might make sense, but are there any examples of widely used encryption software doing such a thing?

$\endgroup$
12
  • $\begingroup$ If I were inventing things instead of asking questions, I would have my software do a block cipher on the plain data and append the key to the newly encrypted data. I'd have it do this at least twice, now the data would look like uniformly distributed random data (because both the key and encrypted message are), and the attacker would have to number crunch at least 1 full decryption of the message for each brute force attempt. $\endgroup$
    – daniel
    Jun 21, 2017 at 11:53
  • $\begingroup$ Since most keys are random (not like passwords) and the key space is far too large to brute force I think such things are uncommon in practice. $\endgroup$
    – Elias
    Jun 21, 2017 at 11:57
  • $\begingroup$ @Elias but they still design systems to be strong against brute force attacks, that is why people keep making keys longer. Also en.wikipedia.org/wiki/RSA_Secret-Key_Challenge $\endgroup$
    – daniel
    Jun 21, 2017 at 12:09
  • 2
    $\begingroup$ I doubt any public software does that , since an attacker with a copy can just do the same as the software to unobfuscate/verify. $\endgroup$
    – otus
    Jun 21, 2017 at 12:15
  • $\begingroup$ @otus but this is all fine with Kerckhoffs 2nd. the attacker would have to do the same for every key he checks. Maybe obfuscate is the wrong word, but its not my wiki. $\endgroup$
    – daniel
    Jun 21, 2017 at 12:19

2 Answers 2

3
$\begingroup$

Since speaking about any software is not showing anything, I'll instead on how they do it and where they do it.

This "obfuscation" is very often done when passwords come into play. There are plenty of good passwords hashing functions, that slow attacker down by "obfuscating" it, then brute-force has to use that same "obfuscation" which is designed to be slow. This is done because users will always generate weak passwords, it isn't something we can fix. But this is still futile attempt at fixing something that is inherently broken (users will always devise poor and short passwords). It is far more effective to make passwords twice as long than making "password check" take twice as long. Increasing key by ONE BIT doubles security. Increasing check time by factor of 2 doubles security.

Apart from passwords, we almost never use such "obfuscations" because they are not effective at stopping attacker. Making key double length will increase security by unimaginable factor, doubling encryption will only double security!

If I were inventing things instead of asking questions, I would have my software do a block cipher on the plain data and append the key to the newly encrypted data. I'd have it do this at least twice, now the data would look like uniformly distributed random data (because both the key and encrypted message are), and the attacker would have to number crunch at least 1 full decryption of the message for each brute force attempt.

This would not help you. I'd simply take twice as long to decrypt your message. This is not a lot, as computing power increases very fast so at worst I'd wait a year to break your scheme. On the flip side, you would have to take twice as long to encrypt that message. We end up being hit same.

History likes to repeat itself. Germans tried to fix enigma by using more and more complex encoding schemes, it didn't help. RC4 was "fixed" by removing first X bytes, it didn't help in long run (everything before fix was compromised, everything after fix was safe for some years). It's easy to fall into pitfall of "I'll just change it a bit and it will be secure again", truth is we don't know how long it will be secure, so it's best to leave whatever is broken behind, making better, more effective algorithms.

but they still design systems to be strong against brute force attacks, that is why people keep making keys longer.

Problem is, you are not even making key longer. Key only makes sense if increasing key by X will increase security by larger margin than X. You instead make it so that it takes two times longer for you and attacker. It doesn't make difference in long run for attacker. RSA is special case, because RSA inherently has better factoring algorithms than bruteforce, and we move away from RSA now because it's not efficient enough. If RSA got cracked however, making better algorithms, we would probably totally move away from RSA, because we couldn't make key large enough for attacker to be powerless. RSA is also far different from symmetric ciphers, because of efficiency, breakage method etc. so comparing two isn't correct.

$\endgroup$
5
  • $\begingroup$ "I'd simply take twice as long to decrypt your message." I don't think the added time works like you think it does. The worst case time to brute force is: (number of keys needed to check)*(time to check one key) , obfuscation would increase the time to check one key, If an attacker chose or knew the plain text (or part of it) this would increase the time by a great deal for a small cost. $\endgroup$
    – daniel
    Jun 21, 2017 at 13:38
  • $\begingroup$ Also, a brute force method might only have to decrypt part of the message each key it checks depending on the encryption method (maybe the first couple of bytes of a 1 gigabyte message), if the plain text was obfuscated similar to how I outlined then they couldn't save time this way. $\endgroup$
    – daniel
    Jun 21, 2017 at 13:48
  • $\begingroup$ @daniel you cannot randomly assume that every message is 1 gigabyte. "there is a case where it helps" isn't compelling reason, choosing algorithm that has greater security margin and using shorter messages IS a compelling reason. $\endgroup$
    – axapaxa
    Jun 21, 2017 at 14:14
  • $\begingroup$ I didn't even assume the cipher that this is applied to. I'm pointing out this obfuscation method adds time for the checking, that the time for checking without it may be very small especially for chosen or known plain text, and that the time added is related to the message length for some forms of obfuscation. $\endgroup$
    – daniel
    Jun 21, 2017 at 14:24
  • $\begingroup$ @daniel 1.in "known plaintext" scenario, check won't be much shorter (in fact it is so short that we always assume it is negligible). 2.You assume cipher is broken, since you assume brute-force is viable option (it isn't with good cipher). 3.Messages are usually upwards of few kilobytes, because they are chunked. 4.You have assumptions that messages have to be huge, and rest of world just uses cipher that cannot be bruteforced. After all security of message is job of cipher. 5.You fail to acknowledge existence of MAC which nullifies your "improvements". Please read up on MAC and it's uses. $\endgroup$
    – axapaxa
    Jun 21, 2017 at 14:52
0
$\begingroup$

Obfuscation may just be an old fashioned way of describing different concepts that expanded on the idea of pre processing the plain text in some way, and are used in current cryptography systems such as All-or-nothing transforms, and Initialization Vectors in AES, given its description is a:

block of bits that is used by several modes to randomize the encryption and hence to produce distinct ciphertexts even if the same plaintext is encrypted multiple times

The list of ciphers that would have benefited by randomizing the plain text before using the rest of the encryption system can be found by looking for any that were broken with the assistance of chosen or known plain text attacks such as the PKZIP stream cipher.

The suggested method is probably flawed and may actually weaken the system by sending a key and cipher as the plain text as this may leak information, if its related to this answer.

So in summary an extra step is not needed for encryption like AES because the Substitution-permutation network randomizes the plain-text and is also expensive for the attacker to repeat for every key it checks, earlier encryption that is vulnerable to known plain text attacks could have benefited from such a step.

$\endgroup$
3
  • $\begingroup$ IV is public knowledge, and as such cannot be used to defend block cipher from plaintext attack. I also disagree that "obfuscation" is same as IV, since sole purpose of IV is randomization of message and chaining blocks. If key is known, IV can be undone very easily, something you consider "hard" in case of your "obfuscation". -1 $\endgroup$
    – axapaxa
    Jun 22, 2017 at 18:22
  • $\begingroup$ @axapaxa I'm just saying this randomization step would add security for something like a 10 character key Vernam cipher, but doesn't for AES. What should I change IV to, to fix my answer? $\endgroup$
    – daniel
    Jun 22, 2017 at 20:10
  • $\begingroup$ I still won't agree that it will add security, it might at best prevent some otherwise obvious attacks. If what you were looking for in your question is IV, then sadly you phased it wrong (you provided solution to problem that doesn't exist). I don't know how to fix your answer, you say you solve something that doesn't exist in modern cryptography and nobody cares about terribly broken ciphers (unlikely that it is their only problem). $\endgroup$
    – axapaxa
    Jun 23, 2017 at 12:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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