Prev: A published list of rare tetragraphs?
Next: A discrepancy in literatures on permutation polynomials
From: Phoenix on 13 Jan 2010 09:19 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 13 Jan 2010 12:10 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 13 Jan 2010 14:06 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 13 Jan 2010 15:40 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 13 Jan 2010 15:44
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!) |