Prev: SK_ASCII - Scalar Key Cryptography - Cipher
Next: GSM Encryption
From: Skybuck Flying on 30 Dec 2009 08:30
Hello,

For packet/communication protocols a new mode for block ciphers (like AES)
might be interesting.

The new mode/idea is a slight alteration of the CBC mode (Cipher-block
chaining).

The problem with CBC mode is that it requires an initialization vector IV.

This is unwanted in communication/packet protocols because it adds unwanted
overhead and complexities.

Since the IV is only required for the first part of the packet it's
desirable to leave it out and use something else.

So the new idea is as follows:

1. The first part of the packet is encrypted with ECB.
2. The remaining parts of the packet are encrypted with CBC.

Thus the new mode is a combination of ECB and CBC.

Let's simply call this mode "PM" :)

Or if you want my name in it in case somebody else wants a different packet
mode:

"SFPM" Skybuck's Flying Packet Mode =D

The whole idea behind this new mode is to add additional encryption
strengths to the packet since CBC is stronger than just ECB (which shows
patterns in the output of the packet).

Also if there is an application-specific counter inside the first part of
the packet then maybe this will also make the first part of the packet
stronger and therefore maybe even the whole packet pretty strong !)

(I haven't explored this idea yet in source code to see if there would be
any problems... I don't know if ECB and CBC produce the same output
lengths... I think so... but I need to make sure... ;))

So one more time the difference is:

Old/weak packet mode, completely in ECB:

Packet 1 parts:
ECB
ECB
ECB
ECB
ECB
ECB

Packet 2 parts:
ECB
ECB
ECB
ECB
etc

New/stronger packet mode, first part in ECB, remaining parts in CBC:

Packet 1 parts:
ECB
CBC
CBC
CBC
CBC
CBC

Packet 2 parts:
ECB
CBC
CBC
CBC
etc

What you guys think of this new mode ?

Is it truely stronger ? I think so... ;)

Bye,
Skybuck =D


From: Joseph Ashwood on 30 Dec 2009 08:37
"Skybuck Flying" <IntoTheFuture(a)hotmail.com> wrote in message
news:29491$4b3b55f9$d53371df$23772(a)cache6.tilbu1.nb.home.nl...
> So the new idea is as follows:
>
> 1. The first part of the packet is encrypted with ECB.
> 2. The remaining parts of the packet are encrypted with CBC.
>
> Thus the new mode is a combination of ECB and CBC.
>
> Let's simply call this mode "PM" :)
>
> Or if you want my name in it in case somebody else wants a different
> packet mode:
>
> "SFPM" Skybuck's Flying Packet Mode =D

Or we can call it what it has been called for decades, CBC with an all-zero
IV.

It has well known advantages and disadvantages. For protocols that carry
significant data in the first block, the ECB-like first block, over long
periods this can lead to statistical analysis. In protocols that carry
little information in the first block the analysis is quickly possible. For
protocols that carry no information in the first block, all prior analysis
can be applied to the second block.
Joe

From: Skybuck Flying on 30 Dec 2009 11:11

"Joseph Ashwood" <ashwood(a)msn.com> wrote in message
news:lcJ_m.42$nN4.12(a)newsfe02.iad...
> "Skybuck Flying" <IntoTheFuture(a)hotmail.com> wrote in message
> news:29491$4b3b55f9$d53371df$23772(a)cache6.tilbu1.nb.home.nl...
>> So the new idea is as follows:
>>
>> 1. The first part of the packet is encrypted with ECB.
>> 2. The remaining parts of the packet are encrypted with CBC.
>>
>> Thus the new mode is a combination of ECB and CBC.
>>
>> Let's simply call this mode "PM" :)
>>
>> Or if you want my name in it in case somebody else wants a different
>> packet mode:
>>
>> "SFPM" Skybuck's Flying Packet Mode =D
>
> Or we can call it what it has been called for decades, CBC with an
> all-zero IV.

Ok, that's nice to know, this means very little code changes needed, just on
user side..

The library can remain as it is, and user/application can switch to CBC mode
with an IV of zero.

> It has well known advantages and disadvantages. For protocols that carry
> significant data in the first block, the ECB-like first block, over long
> periods this can lead to statistical analysis. In protocols that carry
> little information in the first block the analysis is quickly possible.
> For protocols that carry no information in the first block, all prior
> analysis can be applied to the second block.
> Joe

I have tried to figure out if using an IV of zero + CBC would be stronger or
weaker then just ECB.

ECB seems like child play in case of pictures.. so ECB seems very weak...

For now I think IV of zero + CBC is at least stronger than ECB for an
individual packet.

However I am not sure what happens if more packets use IV's of zero...

The only thing I found so far is this:

http://rdist.root.org/2008/02/05/tlsssl-predictable-iv-flaw/

I do not agree with this little sentence:

"Uniqueness is necessary because CBC devolves to ECB without it"

In particular the "devolves to ECB" statement.

I think CBC with IV zero is not the same as ECB.

Since ECB does not do any chaining and CBC will do chaining... so the CBC
output will look more like random noise...

That's why I currently think CBC + IV of zero is better than ECB.

Also let's assume the first block of a packet is always different... because
of an application counter then it's pretty safe to say the all packets will
look different from each other as well ?! ;)

The link also mentions an attack possibility... by trying to guess the
plaintext and then submitting it ?!?

For protocol I think the value of this is if an ack is received then
apperently the packet got accepted... doesn't necessarily mean the plaintext
is actually guessed correctly... it might just happen to match crc's,
checksums etc... but indeed it is likely that it might have succeeded.

However trying to guess like that would require a lot of bandwidth... and
might be noticed by those doing the transfer... by the slow speed... (unless
unattended ofcourse) and possibly many duplicates the same time... they
might think something is wrong with the connection and they might not
suspect an attack.

However this also requires "interception" of the packets themselfes to get
to the ciphertext... which might indeed be the case with the internet...
isp's maybe tunnels or p2p or whatever...

However lot's of guesses needed I think to construct a real packet of say
512 bytes, maybe even 64000 bytes...

Also what would be the difference with guessing AES's ECB mode... I see
little difference there...

Therefore I think this attack is not really feasible in practice... and
therefore I think CBC+IV zero is pretty safe for practical situations ?!? ;)

What you guys think ? :)

Bye,
Skybuck =D


From: Joseph Ashwood on 1 Jan 2010 08:55
"Skybuck Flying" <IntoTheFuture(a)hotmail.com> wrote in message
news:8e690$4b3b7b88$d53371df$6240(a)cache6.tilbu1.nb.home.nl...
>
> "Joseph Ashwood" <ashwood(a)msn.com> wrote in message
> news:lcJ_m.42$nN4.12(a)newsfe02.iad...
>> It has well known advantages and disadvantages. For protocols that carry
>> significant data in the first block, the ECB-like first block, over long
>> periods this can lead to statistical analysis. In protocols that carry
>> little information in the first block the analysis is quickly possible.
>> For protocols that carry no information in the first block, all prior
>> analysis can be applied to the second block.
>> Joe
>
> I have tried to figure out if using an IV of zero + CBC would be stronger
> or weaker then just ECB.

It is obviously no weaker than ECB, but not lacks the proof of security of
CBC used correctly.

> ECB seems like child play in case of pictures.. so ECB seems very weak...

As Tom pointed out, this is generally not the case, and is particularly not
the case in compressed files (e.g. jpeg). The reason is fairly simple, there
are simply too many colors and the block is too big.


> Since ECB does not do any chaining and CBC will do chaining... so the CBC
> output will look more like random noise...

And without sufficient knowledge Vigenere encryptions look like random noise
too, that doesn't mean it is secure. With a fixed IV, you are relying on
untested, unverified aspects of the cipher. In fact you are relying on
aspects of the cipher's security that we don't even know how to check yet,
and any cipher that could be proven CBC-equivalent with a fixed IV variation
of CBC would be a significant result.

>
> That's why I currently think CBC + IV of zero is better than ECB.
>
> Also let's assume the first block of a packet is always different...
> because of an application counter then it's pretty safe to say the all
> packets will look different from each other as well ?! ;)

What amount of variation is there in the first block? If the entire first
block is a counter is random bits, then the protocol has implemented an IV.
If the first block has 1 bit of entropy then the devolvement to ECB levels
of security will happen surprisingly fast on that first block, and the
unicity distance will come into play very quickly, this is bad.

> What you guys think ? :)

I think you really should re-read and actually understand what has been
written, including the webpage you cited.
Joe

From: Skybuck Flying on 1 Jan 2010 15:38

"Joseph Ashwood" <ashwood(a)msn.com> wrote in message
news:1en%m.701$rL7.539(a)newsfe23.iad...
> "Skybuck Flying" <IntoTheFuture(a)hotmail.com> wrote in message
> news:8e690$4b3b7b88$d53371df$6240(a)cache6.tilbu1.nb.home.nl...
>>
>> "Joseph Ashwood" <ashwood(a)msn.com> wrote in message
>> news:lcJ_m.42$nN4.12(a)newsfe02.iad...
>>> It has well known advantages and disadvantages. For protocols that carry
>>> significant data in the first block, the ECB-like first block, over long
>>> periods this can lead to statistical analysis. In protocols that carry
>>> little information in the first block the analysis is quickly possible.
>>> For protocols that carry no information in the first block, all prior
>>> analysis can be applied to the second block.
>>> Joe
>>
>> I have tried to figure out if using an IV of zero + CBC would be stronger
>> or weaker then just ECB.
>
> It is obviously no weaker than ECB, but not lacks the proof of security of
> CBC used correctly.
>
>> ECB seems like child play in case of pictures.. so ECB seems very weak...
>
> As Tom pointed out, this is generally not the case, and is particularly
> not the case in compressed files (e.g. jpeg). The reason is fairly simple,
> there are simply too many colors and the block is too big.
>
>
>> Since ECB does not do any chaining and CBC will do chaining... so the CBC
>> output will look more like random noise...
>
> And without sufficient knowledge Vigenere encryptions look like random
> noise too, that doesn't mean it is secure. With a fixed IV, you are
> relying on untested, unverified aspects of the cipher. In fact you are
> relying on aspects of the cipher's security that we don't even know how to
> check yet, and any cipher that could be proven CBC-equivalent with a fixed
> IV variation of CBC would be a significant result.
>
>>
>> That's why I currently think CBC + IV of zero is better than ECB.
>>
>> Also let's assume the first block of a packet is always different...
>> because of an application counter then it's pretty safe to say the all
>> packets will look different from each other as well ?! ;)
>
> What amount of variation is there in the first block? If the entire first
> block is a counter is random bits, then the protocol has implemented an
> IV. If the first block has 1 bit of entropy then the devolvement to ECB
> levels of security will happen surprisingly fast on that first block, and
> the unicity distance will come into play very quickly, this is bad.
>
>> What you guys think ? :)
>
> I think you really should re-read and actually understand what has been
> written, including the webpage you cited.

I think I understand this text just fine:

"
The attack is simple. After observing a message, the attacker knows the IV
for the next message will be ciphertext block Cn-1. Using this knowledge,
the attacker can try to guess any previous plaintext block Px. He does this
by constructing a plaintext block with the following format:
Pguess = Cn-1 XOR Px XOR Cx-1
Let's break this down. The first item, Cn-1, is the known IV for the next
message. Px is the guess for some previous block of plaintext, any will do.
Finally, Cx-1 is the original block of ciphertext before our guessed block
of plaintext. We know based on the operation of CBC that Px was chained with
this value.
When Pguess is encrypted, the IV will cancel out (A XOR A = 0), leaving:
Cguess = ENCRYPT(Px XOR Cx-1)
As you can see, if the guess for was correct, the ciphertext Cguess will be
identical to Cx. If the guess is wrong, the ciphertext will be different.
This attack may be unrealistic in scenarios where the attacker cannot submit
plaintext to the same TLS session as the target. However, this is feasible
in shared connections such as a TLS/SSL VPN.
The important lesson here is that both uniqueness and unpredictability are
vital when using IVs.
"

Since AES uses 128 bit blocks, it would require 2^128 guesses for Px...
which is a whole lot of guesses...

Only one of those guesses would match ?!? So it's literally trying to find a
needle in a haystack...

Like I wrote before it would be like trying to break ECB mode... once that's
broken the whole AES is broken ;)

Bye,
Skybuck.


 |  Next  |  Last
Pages: 1 2 3 4 5
Prev: SK_ASCII - Scalar Key Cryptography - Cipher
Next: GSM Encryption