Re: Data Compression Before or After Encryption ?
From: Volker Hetzer (volker.hetzer_at_ieee.org)
Date: 10/28/04
- Next message: Skybuck Flying: "Re: Data Compression Before or After Encryption ?"
- Previous message: Volker Hetzer: "Re: Data Compression Before or After Encryption ?"
- In reply to: Skybuck Flying: "Re: Data Compression Before or After Encryption ?"
- Next in thread: Skybuck Flying: "Re: Data Compression Before or After Encryption ?"
- Reply: Skybuck Flying: "Re: Data Compression Before or After Encryption ?"
- Reply: Joe Peschel: "Re: Data Compression Before or After Encryption ?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 28 Oct 2004 11:51:02 +0200
"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.
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.
Lots of Greetings!
Volker
- Next message: Skybuck Flying: "Re: Data Compression Before or After Encryption ?"
- Previous message: Volker Hetzer: "Re: Data Compression Before or After Encryption ?"
- In reply to: Skybuck Flying: "Re: Data Compression Before or After Encryption ?"
- Next in thread: Skybuck Flying: "Re: Data Compression Before or After Encryption ?"
- Reply: Skybuck Flying: "Re: Data Compression Before or After Encryption ?"
- Reply: Joe Peschel: "Re: Data Compression Before or After Encryption ?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|