-2
$\begingroup$

In general (if possible to determine) which would make an output harder to turn into plain text with a computer?

  • Extreme Length (minor complexity change)
  • Extreme algorithmic complexity (minor length change)

(Assuming these are hidden patterns of course)

Possible simple example for length might be a sentence turned numerals by changing to unicode identifier (like A=0041), this being translated back into words i.e. zero zero four one and for good measure each of those words characters turned back into unicode.

Using example of letter A…

=0041
=Zerozerofourone
=005A00200065002000720020006F0020007A00200065002000720020006F002000660020006F00200075002000720020006F0020006E00200065

So, in this example each character becomes extremely long, and a couple permutations would cause it to become even longer.

I do not have an algorithm to use for an example opposing this, but assuming no difference in character lengths between output and input are the same, but the way in which the character's are encrypted is complex. (not necessarily duplicating, large base of character to choose from, etc.)

I hope this hasn't been too cryptic.

|improve this question
$\endgroup$
  • $\begingroup$ First, let me throw in the well-vetted “You don’t roll your own crypto” quote. Next, let me ask you something: Have you tried to break your it yourself? Did you compare the results? What were your findings? See, if you would have done your own research and tests, you would quickly have noticed that your idea doesn’t add any kind of security or resistance against any attack… since you’re merely encoding things, not encrypting them. Reversing such things is simple… there’s no “break” needed. $\endgroup$ – e-sushi Aug 22 '14 at 7:39
  • $\begingroup$ In fact, if you're thinking of how to encode text before encrypting it, your kind of lengthening will only make it easier for patterns to be detected statistically. You'd be better off compressing your plaintext. $\endgroup$ – Bristol Aug 22 '14 at 8:12
  • 2
    $\begingroup$ @Bristol Indeed. Yet, there are some potential pitfalls when compressing data before encrypting it, which should be made aware of… because compression “can” (not “will”) weaken security, depending on the implementation and/or protocol. There are some related questions and answers here at Crypto.SE that provide a bit of an insight related to that: Is compressing data prior to encryption necessary to reduce plaintext redundancy? and How does compression before encryption leak info about the input? $\endgroup$ – e-sushi Aug 22 '14 at 10:14
  • $\begingroup$ @e-sushi you are right I do not know enough about encryption, which is why I am asking questions from people who would know. I was just trying to figure out if a long CT length (with actual encryption, not my encoding) would be more difficult vs the process by which the the PT was encrypted. I was only trying to find a way to illustrate this analogically but unfortunately all analogies are faulty, and this was probably a bad one. I am open to edits or how to improve this answer or even material to research (along with one in comment) as an aside at this moment now cannot open links $\endgroup$ – No Time Aug 22 '14 at 15:16
1
$\begingroup$

Basically, "length" increases the time a brute force or other generic attack takes, while "complexity" makes it more difficult or less likely to find attacks faster than those.

However:

  1. The length in question varies depending on the algorithm or operation. It can be the length of keys, the block size of a block cipher, the state size of a PRG or the output length of a MAC or hash function.

    Typically a string is not encrypted as a longer ciphertext (except due to IV, padding etc.). You could do that, but there isn't really a reason to: the number of possible ways to encrypt $n$-bit plaintext as $n$-bit ciphertext is so large for $n \ge 128$ that there is no need to expand it.

  2. The complexity in question isn't normal algorithmic complexity (Kolmogorov complexity). For example, many cryptographic algorithms must be non-linear to be secure. No matter how complex you make a linear algorithm, it will lose to a simpler non-linear algorithm in such cases.

    Instead, it is computational complexity. For an encryption algorithm to be secure, decryption must be impossible for computationally bounded adversaries without the key. The algorithm itself can be fairly simple (e.g. modular exponentiation in ElGamal) as long as there is no way to reverse it without the key.

|improve this answer
$\endgroup$
  • $\begingroup$ I am glad you understood what I was trying to ask. When you are saying non-linear I am assuming you mean asymmetric encryption rather than symmetric. $\endgroup$ – No Time Aug 26 '14 at 2:14
  • $\begingroup$ @NoTime, I meant symmetric algorithms. A block cipher or hash function cannot be linear. $\endgroup$ – otus Aug 26 '14 at 6:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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