Re: Data Compression Before or After Encryption ?

From: Skybuck Flying (nospam_at_hotmail.com)
Date: 10/28/04 

Date: Thu, 28 Oct 2004 13:15:20 +0200

"Volker Hetzer" <volker.hetzer@ieee.org> wrote in message
news:clqfe7$clq$1@nntp.fujitsu-siemens.com...
>
> "Skybuck Flying" <nospam@hotmail.com> schrieb im Newsbeitrag
news:cloobv$bb$1@news5.zwoll1.ov.home.nl...
> >
> > "Volker Hetzer" <volker.hetzer@ieee.org> wrote in message
> > news:clojm2$ra3$1@nntp.fujitsu-siemens.com...
> > >
> > > "Skybuck Flying" <nospam@hotmail.com> schrieb im Newsbeitrag
> > news:cloch8$lh8$1@news2.zwoll1.ov.home.nl...
> > > >
> > > > "John Savard" <jsavard@excxn.aNOSPAMb.cdn.invalid> wrote in message
> > > > news:417e70a4.3129650@news.ecn.ab.ca...
> > > > > On 26 Oct 2004 13:15:12 GMT, Jean-Luc Cooke <jlcooke@engsoc.org>
> > wrote,
> > > > > in part:
> > > > >
> > > > > >Skybuck, you are clearly out of your league. CTR is what you
want.
> > > > > >Take our advice (use AES-CTR, read some books) and stop posting.
You
> > > > > >are wrong on many levels (not just crypto).
> > > > >
> > > > > It certainly is true that someone who feels the question "should I
> > > > > compress before or after encrypting" is worth asking does need to
> > > > > acquire a better grasp of the fundamentals before proceeding.
> > > > >
> > > > > However, I'm not clear why you can say definitely that CTR mode is
> > what
> > > > > he needs. I'll have to search this thread to find where he stated
his
> > > > > requirements.
> > > >
> > > > Requirements are simple:
> > > >
> > > > 1. Preferreably no overhead. (IV's are overhead)
> > > > 2. Everything must be encrypted. (That means IV's can't be supplied
:P )
> > > > 3. Out of Order encryption/decryption for packets/pieces...
> >
> > > Somehow I miss the security requirements here...
> >
> > Mhoaw, as long as sniffers can't make sense of things it's ok ;)
> >
> > > Also, why "must" IV's be encrypted?
> >
> > I am not using IV's at the moment... see other sub thread.
> >
> > > Why out of order?
> >
> > Think bit torrent... how would you encrypt bit torrent pieces ;)
> >
> > >
> > > >
> > > > Ofcourse rule 1 can be relaxed a bit... and the IV's or some crazy
> > number
> > > > supplied... but how secure would that be ! that's the big
question...
> > and
> > > > you say CTR can be pretty fricking unsafe !
> > > Every mode can be unsafe.
> > >
> > > > so I don't understand encryption well enough...
> > > That much is obvious. However, your real trouble is that you have no
clue
> > > *and* are not trusting us. Which translates in an unwilligness to take
> > advice.
> > > Which, when combined with your admitted cluelessness leads to an
unsafe
> > system.
> >
> > Nononononono, I am not stupid you know...
> I didn't say stupid, I said clueless. There's a difference.
>
> >
> > All I am saying is... I don't understand the encryption algorithms and
never
> > wrote my own AES etc...
> > But I do know what an XOR is kinda ;) and all the other stuff like IV's
> > blabla.
> Yes. And bacause of that we say, use CTR. Four or five years ago
> we would have suggested CBS, CTR is basically a more modern
> replacement.
>
> > > > so I rather not play with something I dont understand and
> > > > risk implementing a really really really bad encryption scheme ;)
ECB is
> > not
> > > > bad ;) but CTR can really bad if done wrong :D
> >
> > > ECB *is* bad. An active attacker can get you to put messages through
> > > your system and can therefore go fishing for ciphertexts of which he
> > > knows the plaintext.
> >
> > Ok say who knows parts of the plain text etc... say I change the key...
> > How will he use this knowledge to decrypt anything ?

> If you change the key it doesn't matter. In that case you'd have to change
the
> key for each encryption block.
> And before you say you don't have to for whatever reason please try to
> think of basically EVERY software company using your approach (trying
> to think of twow or three ways an attacker could attack a system) and
guarding
> against those things. And EVERY company who did this looked rather silly
> when their systems got broken.

Let's suppose the key stays the same and ECB mode is used... and some parts
of the plaintext are always the same.

Is there any known attack against ECB that will actually work in practice ?
;) :D

> If you don't want to make the same mistake, you go with CTR, maybe CBC
> and we can go on discuss key and IV management.
> You have no clue about security and we have no clue about your app. Some
> exchange might be in order. You mentioned bit torrent. Do you want to
replace
> the transport layer or do you want to set up a similar product with
security?
>
>
> > Hey man check out bit torrent... it uses TCP/IP ;)
> How large are your packages going to be?
>
> Can you encrypt the whole file (one key, one IV) and split it up later?
Then decryption
> of each packet can start as soon as the IV is received (probably with the
first packet).
> The other packets packets can then arrive out of order, you just have to
know which
> bytes you just received so you can calculate the proper counter value. Or,
you send
> the original IV with each packet and the user simply adds the offset to
arrive at the
> packet specific IV. Or the packet sender calculates the proper IV. Or the
IV is
> a separate unencrypted 16 Byte packet to be fetched first. Pick whatever
you like.
> the Key/Counter value combination needs to be unique (i.e. different for
each block)
> that's all.

If my app would use CTR then each protocol will have to be looked at etc...
some packet numbers be included... for the CTR offset etc...

That's a lot of work etc... just for some simple security ;)

With ECB mode I am done in a second... by simple encrypting anything that is
outputted :D

Before I start using any other mode I first have to be convinced that

1. Cracking ECB is easy and practically possibly.

( I haven't seen any theory or proof yet in this thread ;) )

2. CTR mode is safer.

( Still confused about this one... see other sub thread ;) )

Bye,
  Skybuck.

Relevant Pages

  • Re: Data Compression Before or After Encryption ?
    ... I don't understand the encryption algorithms and never ... And bacause of that we say, use CTR. ... You have no clue about security and we have no clue about your app. ... of each packet can start as soon as the IV is received. ...
    (sci.crypt)
  • Re: Speed Mismatch?!?
    ... This _is_ a clue. ... all gi...I _WAS_ trying to buffer somthing somwhere, ... how but wondering if packet A overran packet B to the point that the ... interface counters care what goes on between the guts that contect ...
    (comp.dcom.sys.cisco)
  • Re: Sun setting on stream ciphers?
    ... > both sides influence the CTR IV and keys. ... could just ensure that any packet they wished would be decoded. ... CTR mode is?: ... If the attacker knows P_i and want plaintext P'_i to be decoded they ...
    (sci.crypt)
  • Re: Embassy No 1
    ... >>Can anyone with a clue tell me why Embassy No 1's now have a "Jim'll ... >>Fix It" question on the side of the packet? ...
    (uk.rec.motorcycles)
  • Re: Problem with sending hex in UDP packet
    ... On Thu, 27 May 2004 16:36:49 GMT, spammersarevermin ... >clue how to accomplish this. ... Using the code below results in a packet ...
    (microsoft.public.dotnet.languages.vb)