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: Paul Rubin on 5 Mar 2010 17:31 Maaartin <grajcar1(a)seznam.cz> writes: > The only example I can figure out are space probes, where resending > may be totally impossible because the communication fort and back > takes many minutes Eh, think of encrypted 2-way voice radios or even telephones. Occasional clobbered frames sound like static in the conversation, no big deal. Retransmission instead of letting the dropped frames fall on the floor introduces unnecessary delays and may even help a denial-of-service attack: if the attacker's transmitter is powerful enough to clobber 5% of your packets despite your forward error correction and frequency hopping, then simply dropping the clobbered packets might result in minor audio impairment, but adding an acknowledgement and retransmission layer could let that 5% error rate stop your conversation completely.
From: Maaartin on 5 Mar 2010 18:16 On Mar 5, 10:58 pm, unruh <un...(a)wormhole.physics.ubc.ca> wrote: > If you really want to design your own cypher, without recovery, go > ahead. It will almost certainly be far far inferior to anything that has > recovery in existence now. But it is your secrets. We both know that I can't design a good cipher. And we both know that the problem is my lack of experience (and knowledge and time, etc.) In the meantime, I found recovery-incapable ciphers by Ross Anderson and Eli Biham http://en.wikipedia.org/wiki/BEAR_and_LION_ciphers Moreover, there's a (sort of) mode making recovery impossible: http://en.wikipedia.org/wiki/All-or-nothing_transform > > The only example I can figure out are space probes, where resending > > may be totally impossible because the communication fort and back > > takes many minutes and because there's no memory for keeping the data > > available for retransmission. But I suppose there's no need for using > > cryptography there (and the processors and power supply are too weak > > for it, anyway). > > What? The processors are fine. And yes, you may not want the world to > know what you are sending back. The processors are chosen for their reliability, power comsumption, radiation resistance, etc., their speed is only secondary. I've found only limited info about it, e.g., http://en.wikipedia.org/wiki/Comparison_of_embedded_computer_systems_on_board_the_Mars_rovers#Performance_comparisons According to this they used 20 MHz RAD6000 in 2004 which is very slow compared to what I used those days. OTOH, because of the limited communication bandwidth it might be sufficient, I can't say.
From: Ilmari Karonen on 5 Mar 2010 20:26 On 2010-03-05, unruh <unruh(a)wormhole.physics.ubc.ca> wrote: > On 2010-03-05, Ilmari Karonen <usenet2(a)vyznev.invalid> wrote: >> >> In any case, I would say there's very little point in designing crypto >> protocols to accommodate random data loss. Rather, you design the >> underlying transmission layer to take care of such things (using error >> correcting codes, retransmission, etc.) and let the crypto layer only >> worry about deliberate attacks. > > That assumes that you have a choice in your transmission layer. Often > users of crypto do not have that choice. It is not hard to make a > crypto system resistant to limited data loss, so why in the world would > you do otherwise? There is no particular reason not to. You can always add your own error correction if the transmission layer you're given doesn't provide enough, and if you have a bidirectional channel, you can also roll your own retransmission if you need and want to. But I wouldn't mix that stuff with the crypto (and certainly not with low-level crypto stuff like cipher operating modes) any more than I had to. The requirements for efficiently dealing with lossy transmission channels and for securely dealing with deliberate attacks are both complex and quite different from each other. It seems to me a bad idea to needlessly complicate a system designed for the latter by trying to make it also do the former. I do agree with you that one shouldn't make the crypto layer more brittle than it needs to be, either. For example, if the data is naturally transmitted in discrete packets, it makes sense to MAC each packet separately so that, if it's corrupted, only that packet needs to be retransmitted (or skipped, if retransmission is not practical or desirable). One just needs to make sure this won't compromise any security requirements. (For example, keep in mind that "only allow certain packets to get through" could be a practical attack strategy. One would certainly not want the message "DO NOT ATTACK THE CONVOY" to be received as "DO ATTACK THE CONVOY" just because a middleman refused to transmit the "NOT" packet. I'm sure you can think of more realistic examples.) Also, I should note that I'm certainly not advocating complete and unconditional separation between crypto and transmission layers, even though such does often occur when crypto is deployed on top of an existing transmission layer. When possible, some interaction between the layers can indeed be useful: for example, if the transmission layer sends back acknowledgements for received packets, it could be a good idea to let the crypto layer check that the packet is valid before acknowledging it. But all those are rather high level issues compared to, say, the choice of which block cipher mode to use, which I believe was what this (sub)thread was originally about. I still hold that resistance to accidental transmission errors is not a useful criterion in choosing a cipher mode, even in applications where such errors do occur, and I'll continue to hold that opinion until someone shows me a cipher mode that does that better and more securely than the simple layered combination of an error correcting code, a MAC and a standard block cipher mode like, say, CTR. -- Ilmari Karonen To reply by e-mail, please replace ".invalid" with ".net" in address.
From: Phoenix on 5 Mar 2010 20:52 Mok-Kong Shen Do you mean some think like this: SCREEN 0 CLS CLEAR OPEN TEST.TXT FOR BINARY AS #1 DEFLNG n, t DEFEXT x, b, c tf = 2^24 IF (LOF(1)-tf) <> 0 THEN CLOSE #1 KILL FL$ OPEN TEST.TXT FOR BINARY AS #1 END IF s=TIMER-INT(TIMER) b0=s*16384 b=b0 c=s p%=256*64 tf2=INT(tf/p%)*p% f%=tf-tf2 c$=SPACE$(p%) FOR n=1 TO tf2-1 STEP p% FOR m%=1 TO p% STEP 6 x =.999*FRAC(x*(x+m%+b)+c) MID$(c$, m%, 6) = MKE$(x*(m%+b+t)+c) NEXT PUT$ #1, c$ IF x<>0 THEN b=b0*x:c=x NEXT IF f% > 0 THEN c$="" FOR m%=1 TO f% x=.999*FRAC(x*(x+m%+b)+c) c$=c$+CHR$(INT(x*256)) NEXT PUT$ #1, c$ END IF CLOSE #1 END
From: Phoenix on 5 Mar 2010 21:07
Mok-Kong Shen Do you mean some think like this: ------------------------------------------------------------------- SCREEN 0 CLS CLEAR OPEN TEST.TXT FOR BINARY AS #1 DEFLNG n, t DEFEXT x, b, c tf = 2^24 IF (LOF(1)-tf) <> 0 THEN CLOSE #1 KILL TEST.TXT OPEN TEST.TXT FOR BINARY AS #1 END IF s=TIMER-INT(TIMER) b0=s*16384 b=b0 c=s p%=256*64 tf2=INT(tf/p%)*p% f%=tf-tf2 c$=SPACE$(p%) FOR n=1 TO tf2-1 STEP p% FOR m%=1 TO p% STEP 6 x =.999*FRAC(x*(x+m%+b)+c) MID$(c$, m%, 6) = MKE$(x*(m%+b+t)+c) NEXT PUT$ #1, c$ IF x<>0 THEN b=b0*x:c=x NEXT IF f% > 0 THEN c$="" FOR m%=1 TO f% x=.999*FRAC(x*(x+m%+b)+c) c$=c$+CHR$(INT(x*256)) NEXT PUT$ #1, c$ END IF CLOSE #1 PRINT Done END --------------------------------------------------------- |