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: Thomas Pornin on 5 Mar 2010 11:35 According to Kristian Gj�steen <kristiag+news(a)math.ntnu.no>: > If one bit is lost from the ciphertext stream, you've lost the entire > message with CTR (no error recovery). It seems quite unusual to loose one bit in such a way. Most of the time, sender and receiver agree upon a transmission rate, so that some bits may be mangled but the _existence_ of those bits is not lost. More often, an entire frame is "lost", but there again frames are numbered, so that the receiver has a "hole", without shifting subsequent data. > I've been told that there are applications where this is useful, but I > believe they are rare. It would take a particularly inefficient network, in which synchronization cannot be maintained for even a few thousand bits. At the same time, it would also require that sender and receiver have quite a lot of CPU reserve with regards to data bandwidth, because CFB with one bit of feedback is quite expensive (AES-CFB is 128 times more expensive than AES-CTR). --Thomas Pornin
From: Ilmari Karonen on 5 Mar 2010 14:41 On 2010-03-05, Tom St Denis <tom(a)iahu.ca> wrote: > On Mar 5, 9:22 am, Kristian Gj�steen <kristiag+n...(a)math.ntnu.no> > wrote: >> Tom St Denis <t...(a)iahu.ca> wrote: >> >> >Also why would you recommend CFB over CTR? CTR in almost every way is >> >more advantageous. >> >> If one bit is lost from the ciphertext stream, you've lost the entire >> message with CTR (no error recovery). With CFB (and 1-bit feedback!), >> a block's worth of stream is lost, then nothing. >> >> I've been told that there are applications where this is useful, but I >> believe they are rare. > > Fair enough. But most packet radio links I've seen are just that, > packet based. So at most you might lose a frame if your sync is way > off, other than that though just the bits as they lay. 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. Of course, some optimization is possible here: for example, a MAC will catch transmission errors just as easily as it'll catch deliberate forgeries, so if your crypto layer includes a MAC (and why shouldn't it?), your transmission layer won't really need a separate checksum to verify message integrity. Whether you'll want to include one anyway or not will depend on a lot of things -- a simple non-crypto checksum is pretty cheap, and makes the transmission layer less dependent on other layers. -- Ilmari Karonen To reply by e-mail, please replace ".invalid" with ".net" in address.
From: Maaartin on 5 Mar 2010 16:44 On Mar 5, 10:05 am, Kristian Gjøsteen <kristiag+n...(a)math.ntnu.no> wrote: > Maaartin <grajc...(a)seznam.cz> wrote: > >I don't see how. In case of a single failed block I can decrypt the > >remaining 99 blocks correctly but I throw it all away because of the > >wrong MAC, don't I? > > I don't see why anyone would use a MAC if their underlying channel could > introduce random errors. 1. There're people claiming you should always use a MAC. 2. Each channel may introduce random errors, the only thing you can hope for is that it nearly never happens. According to this, I'd say that error recovery is not useful cipher property most of the time. I think about sending a file over TCP/IP, this could be a typical case. I'd use compression, encryption, and MAC. Because if the compression and because of the MAC, no error recovery is possible, so it doesn't matter if the underlying cipher is capable of it or not. Bit errors are possible but unprobable, the probability of connection loss (or hardware failure or power outage) is probably much higher. In either case you need to retransmit the file. > I've heard reliable people say that for some > channels retransmission is impractical and errors happen. Then you skip > the MAC and instead use a cipher with reliable error recovery properties, > such as CFB mode. 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). On Mar 5, 8:41 pm, Ilmari Karonen <usen...(a)vyznev.invalid> wrote: > Of course, some optimization is possible here: for example, a MAC will > catch transmission errors just as easily as it'll catch deliberate > forgeries, so if your crypto layer includes a MAC (and why shouldn't > it?), your transmission layer won't really need a separate checksum to > verify message integrity. Whether you'll want to include one anyway > or not will depend on a lot of things -- a simple non-crypto checksum > is pretty cheap, and makes the transmission layer less dependent on > other layers. Moreover, it allows for resending of lost or erroneous packets. Computing cryptographic MAC for every packet could be time comsuming and adding 16 to 32 bytes to small packets could be a problem. Especially in cases of unreliable connections (WIFI may easily lose 20% of packets as I saw before I bought a better antena).
From: unruh on 5 Mar 2010 16:45 On 2010-03-05, Ilmari Karonen <usenet2(a)vyznev.invalid> wrote: > On 2010-03-05, Tom St Denis <tom(a)iahu.ca> wrote: >> On Mar 5, 9:22 am, Kristian Gj?steen <kristiag+n...(a)math.ntnu.no> >> wrote: >>> Tom St Denis <t...(a)iahu.ca> wrote: >>> >>> >Also why would you recommend CFB over CTR? CTR in almost every way is >>> >more advantageous. >>> >>> If one bit is lost from the ciphertext stream, you've lost the entire >>> message with CTR (no error recovery). With CFB (and 1-bit feedback!), >>> a block's worth of stream is lost, then nothing. >>> >>> I've been told that there are applications where this is useful, but I >>> believe they are rare. >> >> Fair enough. But most packet radio links I've seen are just that, >> packet based. So at most you might lose a frame if your sync is way >> off, other than that though just the bits as they lay. > > 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. > > Of course, some optimization is possible here: for example, a MAC will > catch transmission errors just as easily as it'll catch deliberate > forgeries, so if your crypto layer includes a MAC (and why shouldn't > it?), your transmission layer won't really need a separate checksum to > verify message integrity. Whether you'll want to include one anyway > or not will depend on a lot of things -- a simple non-crypto checksum > is pretty cheap, and makes the transmission layer less dependent on > other layers. That assumes that you can design the transmission layer. >
From: unruh on 5 Mar 2010 16:58
On 2010-03-05, Maaartin <grajcar1(a)seznam.cz> wrote: > On Mar 5, 10:05?am, Kristian Gj?steen <kristiag+n...(a)math.ntnu.no> > wrote: >> Maaartin ?<grajc...(a)seznam.cz> wrote: >> >I don't see how. In case of a single failed block I can decrypt the >> >remaining 99 blocks correctly but I throw it all away because of the >> >wrong MAC, don't I? >> >> I don't see why anyone would use a MAC if their underlying channel could >> introduce random errors. > > 1. There're people claiming you should always use a MAC. > 2. Each channel may introduce random errors, the only thing you can > hope for is that it nearly never happens. > > According to this, I'd say that error recovery is not useful cipher > property most of the time. I think about sending a file over TCP/IP, > this could be a typical case. I'd use compression, encryption, and > MAC. Because if the compression and because of the MAC, no error > recovery is possible, so it doesn't matter if the underlying cipher is > capable of it or not. Bit errors are possible but unprobable, the > probability of connection loss (or hardware failure or power outage) > is probably much higher. In either case you need to retransmit the > file. You are assuming that the transmission is free -- if it does not work now, I can always redo it. But there are many situations where crypto is important where it is far from free, where the transmission is the most expense part of the whole operation (eg a spy transmitting over radio-- you make the message too long and you get shot). Error recovery is crucial. Just because you happen not to need it is a silly reason not to have it. And especially because it is almost free. Most decent cyphers have it. And getting part of the message is often worth far more than getting none of it. There is usually enough redundancy in messages that losing a single packet is not a disaster. 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. > >> I've heard reliable people say that for some >> channels retransmission is impractical and errors happen. Then you skip >> the MAC and instead use a cipher with reliable error recovery properties, >> such as CFB mode. > > 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. > > > On Mar 5, 8:41?pm, Ilmari Karonen <usen...(a)vyznev.invalid> wrote: >> Of course, some optimization is possible here: for example, a MAC will >> catch transmission errors just as easily as it'll catch deliberate >> forgeries, so if your crypto layer includes a MAC (and why shouldn't >> it?), your transmission layer won't really need a separate checksum to >> verify message integrity. ?Whether you'll want to include one anyway >> or not will depend on a lot of things -- a simple non-crypto checksum >> is pretty cheap, and makes the transmission layer less dependent on >> other layers. > > Moreover, it allows for resending of lost or erroneous packets. > Computing cryptographic MAC for every packet could be time comsuming > and adding 16 to 32 bytes to small packets could be a problem. > Especially in cases of unreliable connections (WIFI may easily lose > 20% of packets as I saw before I bought a better antena). |