Prev: Generic Crypto APIs ?
Next: in ElGamal, could you hardcode the generator for a public key and not lose security?
From: unruh on 4 Mar 2010 19:55
On 2010-03-04, Maaartin <grajcar1(a)seznam.cz> wrote:
> 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?

Sure it does.

>
> 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.

No. Error recovery is an important feature of cyphers. There exist
millions of cyphers out there. Use the ones that are a) strong, and b)
have error recovery. There is no need to try to incompetently cobble
together something to improve a bad cypher.

From: Maaartin on 4 Mar 2010 23:19
On Mar 5, 1:55 am, unruh <un...(a)wormhole.physics.ubc.ca> wrote:
> On 2010-03-04, Maaartin <grajc...(a)seznam.cz> wrote:
>
> > 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?
>
> Sure it does.

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?

> > 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.
>
> No. Error recovery is an important feature of cyphers. There exist
> millions of cyphers out there. Use the ones that are a) strong, and b)
> have error recovery. There is no need to try to incompetently cobble
> together something to improve a bad cypher.

Sure, I'm not going to use a bad cipher, nor to try to improve it. I
can just imagine somebody designing a cipher or an encryption mode
trading error recovery for speed and/or security.

A different question: I see some people writing cipher" and others
writing "cypher", is both correct or is one US and the other UK?
From: Paul Rubin on 5 Mar 2010 02:41
Maaartin <grajcar1(a)seznam.cz> writes:
> A different question: I see some people writing cipher" and others
> writing "cypher", is both correct or is one US and the other UK?

It's an archaic spelling in both the US and the UK, but was
re-popularized by the Cypherpunks movement (take-off on Cyberpunk) in
the late 20th century, so some folks here like to use it. I don't
remember ever having seen it in any contemporary academic crypto
publications.
From: Mok-Kong Shen on 5 Mar 2010 03:50
This thread has, as a positive side effect, led to some discussions on
the consequences of the (never "absolutely" eliminable, though in
practice in the major transmission media in my view at least
economically negligible) transmission errors. Allow me to stress my
humble viewpoints on this. If, contrary to common expectations, errors
occur, then ask for retransmission (which is also what the lower layer
of the trasmission protocol, despite technological advances, still
not infrequently do, I surmise, and which certainly much more oftener
occurred in the older periods of the history of crypto). Now, as far as
I am aware, the importance of employing MAC is often (certainly
correctly and reasonalbly) stressed in the crypto context. Why does one
take the trouble to do work to provide a MAC at all? Clearly a MAC
gives the receiver a possibility to detect eventual possible errors
arising from techniques (as such) or manipulations done by man-in-
the-middle. When the MAC doesn't check, then one couldn't accept the
message as valid and should ask for retransmission in my view. If one
lowers one's "standard" and is "willing" to accept corrupted messages
(after one "definitely" knows that there are errors "somewhere" in the
message), then one could economize and drop the efforts of providing
error detection in the first place.

In this opportunity I like to mention that in my humble view two points
raised by me perhaps need yet some more discussions in order to clearly
expose their weakness that may be present. The one is whether the
"mild" dynamic modifications of the kind I exemplified in the original
post are in fact tolerable from the security point of view. The second
is whether what I termed "outer" dynamics (mentioned in my post of 03.03
and which in my conviction has at least as high, if not very much
higher, potential of rendering the analysis hard) can be really
beneficial and economically justifiable.

Thanks,

M. K. Shen

From: Kristian Gj�steen on 5 Mar 2010 04:05
Maaartin <grajcar1(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. 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.

>Sure, I'm not going to use a bad cipher, nor to try to improve it. I
>can just imagine somebody designing a cipher or an encryption mode
>trading error recovery for speed and/or security.

CFB mode is an example.

--
Kristian Gj�steen
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8
Prev: Generic Crypto APIs ?
Next: in ElGamal, could you hardcode the generator for a public key and not lose security?