Introducing dynamics into block encryptions
in [Cryptography]
|
Prev: Generic Crypto APIs ?
Next: in ElGamal, could you hardcode the generator for a public key and not lose security?
From: Tom St Denis on 4 Mar 2010 10:14 On Mar 2, 5:23 pm, Mok-Kong Shen <mok-kong.s...(a)t-online.de> wrote: > I don't think the issue of technical errors is anything grave, given > today's hightech standard. For all transmission errors are well dealt > with in lower layers of protocol and computers are more reliable than > ever in my humble view. Or do you mean human handling errors? But > also an overwhelmingly large part of what was previously done by humans > in matters of communications has been taken over by machine and often > data entered by humans are checked for plausibility by machine. > Certainly the human factor can never be completely eliminated. But I am > of the humble opinion that one could neglect the disadvantages of > eventual consequences resulting from remaining chance errors in view of > the advantages achievable from (almost) full automation. The problem is not all communications go over TCP. And even TCP is malleable it only uses a simple checksum for integrity. So you need a MAC at least, but ideally your cipher should be recoverable from bad packets [hint: think radio links]. So instead of having a TCP cipher, UDP cipher, radio cipher, etc... why not have one cipher that is good for all of them [and good at it too]? Also, in general key-dependant or data-dependant cipher choices are usually bad since they lead to the concept of weak keys/plaintext where the algorithm is less secure. For example, attacks on RC5 so far tend to be based on predicting the rotation value for certain types of plaintext. Tom
From: Mok-Kong Shen on 4 Mar 2010 10:53 Tom St Denis wrote: > The problem is not all communications go over TCP. And even TCP is > malleable it only uses a simple checksum for integrity. So you need a > MAC at least, but ideally your cipher should be recoverable from bad > packets [hint: think radio links]. > > So instead of having a TCP cipher, UDP cipher, radio cipher, etc... > why not have one cipher that is good for all of them [and good at it > too]? > > Also, in general key-dependant or data-dependant cipher choices are > usually bad since they lead to the concept of weak keys/plaintext > where the algorithm is less secure. For example, attacks on RC5 so > far tend to be based on predicting the rotation value for certain > types of plaintext. At least one could say that, if one's communication medium is error free (on the application level), then the idea could be exploited. (If I and my partner "always" use TCP, why should I care that others may use radio, as long as I can somehow get more security?) To your last paragraph, see what I wrote about AES in the original post. M. K. Shen
From: Tom St Denis on 4 Mar 2010 12:45 On Mar 4, 10:53 am, Mok-Kong Shen <mok-kong.s...(a)t-online.de> wrote: > Tom St Denis wrote: > > The problem is not all communications go over TCP. And even TCP is > > malleable it only uses a simple checksum for integrity. So you need a > > MAC at least, but ideally your cipher should be recoverable from bad > > packets [hint: think radio links]. > > > So instead of having a TCP cipher, UDP cipher, radio cipher, etc... > > why not have one cipher that is good for all of them [and good at it > > too]? > > > Also, in general key-dependant or data-dependant cipher choices are > > usually bad since they lead to the concept of weak keys/plaintext > > where the algorithm is less secure. For example, attacks on RC5 so > > far tend to be based on predicting the rotation value for certain > > types of plaintext. > > At least one could say that, if one's communication medium is error > free (on the application level), then the idea could be exploited. > (If I and my partner "always" use TCP, why should I care that others > may use radio, as long as I can somehow get more security?) To your > last paragraph, see what I wrote about AES in the original post. TCP is NOT error free though. It's just unlikely that an accidental error gets through. Even if it were TCP packets are not keyed so forging them is easy. So using a cipher that cannot recover is bad. Of course not MAC'ing data is also bad... So what we have here is a heaping pile of who cares. Tom
From: Mok-Kong Shen on 4 Mar 2010 16:28 Tom St Denis wrote: > TCP is NOT error free though. It's just unlikely that an accidental > error gets through. Even if it were TCP packets are not keyed so > forging them is easy. > > So using a cipher that cannot recover is bad. Of course not MAC'ing > data is also bad... So what we have here is a heaping pile of who > cares. What do you mean here? Anyway, in over 20 years of communications on the internet I haven't encountered any problems of error. Exactly 0 error you can't require of "any" physical system. There is "always" a chance that an airplane crashes, yet people fly. So what? In the worst case when the MAC doesn't check, then ask for retransmission. (And what do you do, if there is a man-in-the middle who manipulated the transmission such that the MAC doesn't check??) M. K. Shen
From: Maaartin on 4 Mar 2010 17:40
On Mar 4, 6:45 pm, Tom St Denis <t...(a)iahu.ca> wrote: > So using a cipher that cannot recover is bad. Of course not MAC'ing > data is also bad... So what we have here is a heaping pile of who > cares. But using a cipher which may recover after each block (e.g., CTR mode) together with MAC over 100 blocks gives you no advantage compared to a cipher recovering after 100 blocks, does it? If there was a possibility to make a cipher stronger simply by giving up the recovery, it should be used in this case, or am I plain wrong? Unfortunatelly, there's no obvious way how to do it. |