From: Phoenix on

Mike, in my opinion you do not need that:
See:

If you want do encrypt a plaintext i.e "FKR" with an simple algorithm
that right move the characters by the value of key.
And if the key is i.e. "1", you have "GLS"

Then encrypt "GLS" with a new key i.e. "2", you have "INU"

Is the same with a just one key i.e. "3" and just one pass.

This is a small example to show you, in my opinion, that is no need to
encrypt more then one.

I my self, and others conjecture to that if we have a *good* algorithm
and a key with *good* entropy, we have no need more than one
encryption pass.
Even if the various encryption do not prejudice the safety, It costs.

Another way to see this is:

Pick a coin and flip it. The result is in the field (0,1).
If you flip it more times, you still have the results in same field
(0,1)

I think is possible to mathematically prove it, but this is another
story.
From: unruh on
On 2010-01-13, Phoenix <ribeiroalvo(a)gmail.com> wrote:
>
> Mike, in my opinion you do not need that:
> See:
>
> If you want do encrypt a plaintext i.e "FKR" with an simple algorithm
> that right move the characters by the value of key.
> And if the key is i.e. "1", you have "GLS"
>
> Then encrypt "GLS" with a new key i.e. "2", you have "INU"
>
> Is the same with a just one key i.e. "3" and just one pass.

Fortunately most cyphers are more sophisticated than the Caesar cypher.
In particular if you encrypt twice with two different cyphers, that is
NOT the same as encrypting once with any one of them. For most cyphers I
believe it is not even known that encrypting twice with the same cypher
is the same as encrypting once with some different key (grooup
property). The number of permutations of a set of 128 numbers say(for a
block cypher) is far far far larger than the set of keys (128 bits long
say) The number of permulations is of the order of e^(2^128)) while the
number of keys is just 2^128 (for a 128 bit key).

>
> This is a small example to show you, in my opinion, that is no need to
> encrypt more then one.

While I agree with this conclusion, I do not with the reason.

Remember that most encryption schemes (DES, AES) are a concatenation of
a whole bunch of simple, weak, encryption schemes (the rounds). The sum
is far stronger than the individual rounds. So in principle,
concatenating encryption schemes are stronger than any single one. The
whole question is whether or not it is worth it-- considering the cost
in speed, complexity, key management,... Certainly for the purposes of
the OP, I do not believe it is. There are far far larger holes in his
security, and spending any time at all on this question is a complete
waste of time, considering that time could be better spent on the issue
of those other holes (the key management).
The encryption is already so so much more secure than that aspect that
it becomes ludicrous.



>
> I my self, and others conjecture to that if we have a *good* algorithm
> and a key with *good* entropy, we have no need more than one
> encryption pass.
> Even if the various encryption do not prejudice the safety, It costs.
>
> Another way to see this is:
>
> Pick a coin and flip it. The result is in the field (0,1).
> If you flip it more times, you still have the results in same field
> (0,1)
>
> I think is possible to mathematically prove it, but this is another
> story.

It depends on the encryption scheme. For some yes (eg OTP, Ceasar) for
others no.

From: Tom St Denis on
On Jan 12, 2:06 pm, Michael B Allen <iop...(a)gmail.com> wrote:
> My first thought is to simply encrypt the data multiple times using
> different algorithms and key sizes (e.g. AES128 -> RC4 -> AES256)
> using different segments of a randomly generated 32 character
> alphanumeric password. The rational is that if / when an algorithm is
> broken, the enclosed encrypted layer would look random and thus not
> give the attacker any feedback as to their success. They would have to
> successfully crack all layers simultaneously. Is this reasoning valid?

Don't.

Also why has nobody mentioned that encryption even times is vulnerable
to MITM attacks?

Tom
From: unruh on
On 2010-01-13, Tom St Denis <tom(a)iahu.ca> wrote:
> On Jan 12, 2:06?pm, Michael B Allen <iop...(a)gmail.com> wrote:
>> My first thought is to simply encrypt the data multiple times using
>> different algorithms and key sizes (e.g. AES128 -> RC4 -> AES256)
>> using different segments of a randomly generated 32 character
>> alphanumeric password. The rational is that if / when an algorithm is
>> broken, the enclosed encrypted layer would look random and thus not
>> give the attacker any feedback as to their success. They would have to
>> successfully crack all layers simultaneously. Is this reasoning valid?
>
> Don't.
>
> Also why has nobody mentioned that encryption even times is vulnerable
> to MITM attacks?

Possibly because the memory requirements are so huge. (2^128 memory is a
bit beyond most people, planets,...)

>
> Tom
From: Peter Fairbrother on
unruh wrote:
> On 2010-01-13, Tom St Denis <tom(a)iahu.ca> wrote:
>> On Jan 12, 2:06?pm, Michael B Allen <iop...(a)gmail.com> wrote:
>>> My first thought is to simply encrypt the data multiple times using
>>> different algorithms and key sizes (e.g. AES128 -> RC4 -> AES256)
>>> using different segments of a randomly generated 32 character
>>> alphanumeric password. The rational is that if / when an algorithm is
>>> broken, the enclosed encrypted layer would look random and thus not
>>> give the attacker any feedback as to their success. They would have to
>>> successfully crack all layers simultaneously. Is this reasoning valid?
>> Don't.
>>
>> Also why has nobody mentioned that encryption even times is vulnerable
>> to MITM attacks?
>
> Possibly because the memory requirements are so huge. (2^128 memory is a
> bit beyond most people, planets,...)

And possibly because he's satisfied with the security of one encryption,
which even times encryptions doesn't diminish.

-- Peter Fairbrother (Hi Tom!)