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 5 Mar 2010 06:44
On Mar 4, 5:40 pm, 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?
>
> 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.

Well you'd MAC your data presumably because it not being tampered with
is important for higher stack level security....

Tom
From: Tom St Denis on 5 Mar 2010 06:47
On Mar 5, 4: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.  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.

Well one landing spot in the middle is for packet transmissions like
over UDP where if the MAC fails you toss out that packet but you don't
disconnect the channel (could fail for arriving out of order for
instance). Over radio links a lot of digital codecs are fairly all or
nothing, if you pass in error bits to something like a vocoder you'll
get really annoying audio output. It's almost preferable to just get
silence [missed packets] than random decoding.

Also why would you recommend CFB over CTR? CTR in almost every way is
more advantageous.

Tom
From: Kristian Gj�steen on 5 Mar 2010 09:22
Tom St Denis <tom(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.

--
Kristian Gj�steen
From: Tom St Denis on 5 Mar 2010 09:45
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.
From: Simon Johnson on 5 Mar 2010 11:10
> 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.

Message authentication codes are under-respected. Privacy often
becomes behind ensuring integrity.

For example, SSH (and a large number of other protocols) are still
useful even if you sent everything is sent in plain-text, provided the
string is probably MACed. An encrypted stream without a MAC, in
comparison, is completely useless. The fact that you still have to
cajole people to use a MAC in 2010 is alarming.

My friend's mother used to say to this to her before she went out on a
date: "Don't let them near you without a mac on." The context is
completely different but the message is exactly the same.

If you don't put on a MAC on your strings, BAD THINGS WILL HAPPEN.

Cheers,

Simon


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?