New mode for AES: "Packet Mode"
Skybuck Flying
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
Joseph Ashwood
news:29491$4b3b55f9$d53371df$23...@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
Skybuck Flying
"Joseph Ashwood" <ash...@msn.com> wrote in message
news:lcJ_m.42$nN4...@newsfe02.iad...
> "Skybuck Flying" <IntoTh...@hotmail.com> wrote in message
> news:29491$4b3b55f9$d53371df$23...@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
Tom St Denis
wrote:
> 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.
Which is generally not a good idea.
> I have tried to figure out if using an IV of zero + CBC would be stronger or
> weaker then just ECB.
Depends on if your content is prefix free or not.
> ECB seems like child play in case of pictures.. so ECB seems very weak...
You'd be surprised how not true that is for photorealistic images.
I've had to create a "ECB is bad" image before and it only really
showed up once I dithered the crap out of the image [to like 16
colours].
> For now I think IV of zero + CBC is at least stronger than ECB for an
> individual packet.
And better yet is using CBC properly.
> However I am not sure what happens if more packets use IV's of zero...
Then you end up with exploitable problems if the packets have
prefixes.
<snip>
Tom
Joseph Ashwood
>> 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
Skybuck Flying
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.
Scott Fluhrer
This is true, IF the attacker had no apriori knowledge of what Px might be.
In that case, the attack is indeed infeasible. However, that is not always
the case. The attacker might have reason to believe that a particular
plaintext might be one of a handful of possible values. The example used
when this was first published was that the plaintext might be a telnet
stream containing the user typing in a password one character at a time; in
that case, each plaintext might consist of one password character (with
everything else being guessable by the attacker); this attack would allow
the attacker to recover the password (by testing each block containing a
password character against the various possible ASCII characters).
>
> Only one of those guesses would match ?!? So it's literally trying to find
> a needle in a haystack...
That's difficult only if the haystack is large...
To answer your general question (or, rather, the question you should have
been asking), in the right situation PM can be secure (private). However,
that security will hold only if the plaintext data is "well-behaved" (e.g.
that no two plaintext blocks start with the same 16 byte prefix), and on the
assumption that an attacker cannot inject a message with a chosen 16 byte
prefix. In contrast, the privacy of CBC mode with random IVs doesn't depend
on the properties of the plaintext data (apart from some information about
the length of the plaintext data leaking if you don't pad to a fixed message
length). I would contend that, for protecting protocols that were not
specifically designed to have any particular security assumtions, that we
want a mode that tries not to make any.
--
poncho
Skybuck Flying
news:12624922...@sj-nntpcache-2.cisco.com...
Also the above text does not mention that the password must be provided as
well... so that's even more guessing possibilities for just the password ?!?
> This is true, IF the attacker had no apriori knowledge of what Px might
> be. In that case, the attack is indeed infeasible. However, that is not
> always the case. The attacker might have reason to believe that a
> particular plaintext might be one of a handful of possible values. The
> example used when this was first published was that the plaintext might be
> a telnet stream containing the user typing in a password one character at
> a time; in that case, each plaintext might consist of one password
> character (with everything else being guessable by the attacker); this
> attack would allow the attacker to recover the password (by testing each
> block containing a password character against the various possible ASCII
> characters).
26 small letters, 26 capital letters, 10 decimals, some symbols like spaces,
points, comma's, question mark, etc... Quickly approaching 80 symbols which
is over 6 bit at least...
ASCII is 7 bit, so 16 * 7 = 112 bits is still a lot of characters to try out
! ;)
So the guessing space is at least: 16 * 6 = 96 bits... still a lot of
guesses !
And this does not even include the password bits ?
Was the mention attack actually succesfull and how long did it take ? ;)
Or is this just a theoretical attack ?
>> Only one of those guesses would match ?!? So it's literally trying to
>> find a needle in a haystack...
>
> That's difficult only if the haystack is large...
>
>
> To answer your general question (or, rather, the question you should have
> been asking), in the right situation PM can be secure (private). However,
> that security will hold only if the plaintext data is "well-behaved" (e.g.
> that no two plaintext blocks start with the same 16 byte prefix), and on
> the assumption that an attacker cannot inject a message with a chosen 16
> byte prefix.
Ok so the security of PM is broken only if rule A and rule B apply at the
same time:
So rule A is: plaintext blocks start with the same 16 bytes.
So rule B is: attacker must be able to inject packets/blocks.
(Possibly to screw up/corrupt the communication for denial of service
attack, or to receive an ack confirming a correct guess, to break the
encryption...(this does require password guessing as well?))
There is also a hidden rule in case the encryption is to be fully broken:
rule C: attacker must be man in the middle if messages from both victims are
to be decrypted.
Then there is another hidden rule:
rule D: attacker does not have to be man in middle, but only a sender to
attempt communication corruption at one or both of the victims.
There is possibly another hidden rule:
rule E: attacker must be an active attacker, actively trying to break the
communication while it takes place.
My question for clearification is:
What happens if the attacker is only passive, for example, the attacker is
"logging/storing" the communication for later "analysis" and possible "break
attempt".
So this means rule E does not apply.
So this means rule D does not apply.
So this means rule C does apply but only for logging purposes.
So this means rule B does not apply.
Which leaves rule A which I also have a question about for the following
case/scenerio:
What if the first 16 bytes of the plaintext blocks is always the same, which
violates rule A but rule B does not apply...
Can the communication still be broken after it has taken place ? (I think
not...)
> In contrast, the privacy of CBC mode with random IVs doesn't depend on the
> properties of the plaintext data (apart from some information about the
> length of the plaintext data leaking if you don't pad to a fixed message
> length). I would contend that, for protecting protocols that were not
> specifically designed to have any particular security assumtions, that we
> want a mode that tries not to make any.
>
> --
> poncho
Bye,
Skybuck.
Joseph Ashwood
> "Scott Fluhrer" <sflu...@ix.netcom.com> wrote in message
> news:12624922...@sj-nntpcache-2.cisco.com...
>>> which is a whole lot of guesses...
>
> Also the above text does not mention that the password must be provided as
> well... so that's even more guessing possibilities for just the password
> ?!?
You've missed everything. The form of the attack is not a key recovery
attack, it is a plaintext recovery attack, the key itself may or may not
remain secure.
>
>> This is true, IF the attacker had no apriori knowledge of what Px might
>> be. In that case, the attack is indeed infeasible. However, that is not
>> always the case. The attacker might have reason to believe that a
>> particular plaintext might be one of a handful of possible values. The
>> example used when this was first published was that the plaintext might
>> be a telnet stream containing the user typing in a password one character
>> at a time; in that case, each plaintext might consist of one password
>> character (with everything else being guessable by the attacker); this
>> attack would allow the attacker to recover the password (by testing each
>> block containing a password character against the various possible ASCII
>> characters).
>
> 26 small letters, 26 capital letters, 10 decimals, some symbols like
> spaces, points, comma's, question mark, etc... Quickly approaching 80
> symbols which is over 6 bit at least...
> ASCII is 7 bit, so 16 * 7 = 112 bits is still a lot of characters to try
> out ! ;)
> So the guessing space is at least: 16 * 6 = 96 bits... still a lot of
> guesses !
> And this does not even include the password bits ?
Again, you missed everything. You'll note where Scott specifically states
"one character" per block, this means by your math 80 possible plaintexts,
since kindergarteners can count to 80 it should be extremely obvious that a
computer can.
> Was the mention attack actually succesfull and how long did it take ? ;)
I'm not sure if it was ever implemented, you will find this a lot with real
cryptography, we find the attack, we understand the attack, we analyz the
vector, we fix the vector, no one cares about performing the attack, that's
your enemy's job, not yours.
>> To answer your general question (or, rather, the question you should have
>> been asking), in the right situation PM can be secure (private).
>> However, that security will hold only if the plaintext data is
>> "well-behaved" (e.g. that no two plaintext blocks start with the same 16
>> byte prefix), and on the assumption that an attacker cannot inject a
>> message with a chosen 16 byte prefix.
>
> Ok so the security of PM is broken only if rule A and rule B apply at the
> same time:
>
> So rule A is: plaintext blocks start with the same 16 bytes.
> So rule B is: attacker must be able to inject packets/blocks.
Wrong on both counts. The attacker only needs to know a narrow distribution
of the possible plaintexts, where the definition of narrow depends on your
attacker's capabilities. If you look at the various UTF formats for text and
assume reasonable levels of entropy you'll find that many blocks will have
as little as 4 bits of entropy (UTF-32 with English's 1 bit of entropy per
character with a 128-bit block), this is at the level where many modern
wristwatches have the compute power necessary.
You completely failed to understand Scott's statement. You have things
exactly opposite of what he said. I suggest you try actually understanding
what is being said, it would probably help to actually read what is written.
> There is also a hidden rule in case the encryption is to be fully broken:
> rule C: attacker must be man in the middle if messages from both victims
> are to be decrypted.
Wrong again. The attacker need only be an observer, maybe if you actually
understood the attack it would help.
> Then there is another hidden rule:
> rule D: attacker does not have to be man in middle, but only a sender to
> attempt communication corruption at one or both of the victims.
Now you're just making things up.
> What happens if the attacker is only passive, for example, the attacker is
> "logging/storing" the communication for later "analysis" and possible
> "break attempt".
Then the attack is easy.
> What if the first 16 bytes of the plaintext blocks is always the same,
> which violates rule A but rule B does not apply...
Then the attack is easy.
> Can the communication still be broken after it has taken place ?
Quite easily.
> (I think not...)
You think wrong.
Under any of the circumstances you gave, and far beyond any circumstances
you gave, the attack on fixed-IV CBC is easy, there is a reason for the
varying IV. I still suggest you actually read and understand even what you
have quoted from, as you clearly have not understood it.
Joe
Skybuck Flying
> "Skybuck Flying" <IntoTh...@hotmail.com> wrote in message
> news:c12e9$4b40be97$d53371df$19...@cache1.tilbu1.nb.home.nl...
>> "Scott Fluhrer" <sflu...@ix.netcom.com> wrote in message
>> news:12624922...@sj-nntpcache-2.cisco.com...
>>>> Since AES uses 128 bit blocks, it would require 2^128 guesses for Px...
>>>> which is a whole lot of guesses...
>>
>> Also the above text does not mention that the password must be provided
>> as well... so that's even more guessing possibilities for just the
>> password ?!?
>
> You've missed everything.
You missed my point in the above text.
"Also" refers to me extending the attack description since it seems
incomplete.
"the above text" refers to the website describing the attack:
http://rdist.root.org/2008/02/05/tlsssl-predictable-iv-flaw/
"does not mention that the password must be provided as well" refers to my
conclusion that the website's description of the attack is incomplete, since
Encrypt is refering to AES Encrypt which requires a password !
"so that's even more guessing possibilities for just the password ?!?"
refers to me asking you a question, which I will repeat and clearify here:
What password will you use for AES Encrypt ?
> The form of the attack is not a key recovery attack,
I understand that, however a key must be provided to be able to "guess" the
cipher text.
As indicated by the formula on the website:
"Cguess = ENCRYPT(Px XOR Cx-1)"
The website does not explain that a key is needed ?
>it is a plaintext recovery attack,
It's plaintext-block-guessing...
> the key itself may or may not remain secure.
Aha ! So a key is needed ?!?
I repeat my question:
What key will be used for the guess work ?
Needless to say, actually being able to "recover the key" is much more
usefull then trying to guess the plaintext
in the first place ?!?
Because guessing the "full plaintext" would require lot's of
"plaintext-block guesses" which to me might seem infeasible.
>>> This is true, IF the attacker had no apriori knowledge of what Px might
>>> be. In that case, the attack is indeed infeasible. However, that is not
>>> always the case. The attacker might have reason to believe that a
>>> particular plaintext might be one of a handful of possible values. The
>>> example used when this was first published was that the plaintext might
>>> be a telnet stream containing the user typing in a password one
>>> character at a time; in that case, each plaintext might consist of one
>>> password character (with everything else being guessable by the
>>> attacker); this attack would allow the attacker to recover the password
>>> (by testing each block containing a password character against the
>>> various possible ASCII characters).
>>
>> 26 small letters, 26 capital letters, 10 decimals, some symbols like
>> spaces, points, comma's, question mark, etc... Quickly approaching 80
>> symbols which is over 6 bit at least...
>> ASCII is 7 bit, so 16 * 7 = 112 bits is still a lot of characters to try
>> out ! ;)
>> So the guessing space is at least: 16 * 6 = 96 bits... still a lot of
>> guesses !
>> And this does not even include the password bits ?
>
> Again, you missed everything.
Yes because no reference implementation/link is given for the mentioned
"supposed-to-be-vunerable" telnet technology/protocol/application, which
makes it very hard to inspect it don't you think ? ;)
> You'll note where Scott specifically states "one character" per block,
No first of all he mentions a "telnet stream", apperently telnet is a
tcp/byte stream like protocol... so it can be considered a "stream" mode of
operation, which is a different mode of operation:
This discussion is about ECB mode and CBC mode which both work on "blocks".
So when scott wrote "one password character in the plaintext" I assumed he
ment "one password character per ECB/CBC block" and the rest being garbage,
zero, or telnet communication. That's what I assumed he ment with "guessable
by the attacker".
> this means by your math 80 possible plaintexts, since kindergarteners can
> count to 80 it should be extremely obvious that a computer can.
For a 16-byte-block, this means 16-bytes have to be guessed which is quite a
lot !
The number of possibilities is: 80^16
>> Was the mention attack actually succesfull and how long did it take ? ;)
>
> I'm not sure if it was ever implemented,
So you're not sure if it works are you ? ;)
> you will find this a lot with real cryptography,
You mean "hypothetical" cryptography.
"Real" cryptography means "implementing" and "testing".
> we find the attack, we understand the attack, we analyz the vector, we fix
> the vector, no one cares about performing the attack, that's your enemy's
> job, not yours.
So again you're not sure if the attack is actually a problem since you never
performed it ?
So you're trying to apply a fix to something which you never even tested if
it actually is a problem ?
And let me guess, you never actually test the fix as well ? ;)
That's a whole lot of "floating hot air".
>
>>> To answer your general question (or, rather, the question you should
>>> have been asking), in the right situation PM can be secure (private).
>>> However, that security will hold only if the plaintext data is
>>> "well-behaved" (e.g. that no two plaintext blocks start with the same 16
>>> byte prefix), and on the assumption that an attacker cannot inject a
>>> message with a chosen 16 byte prefix.
>>
>> Ok so the security of PM is broken only if rule A and rule B apply at the
>> same time:
>>
>> So rule A is: plaintext blocks start with the same 16 bytes.
>> So rule B is: attacker must be able to inject packets/blocks.
>
> Wrong on both counts.
Nope, that's how Scott and the website describe it.
Scott mentions "inject", the website mentions "inject".
Scott mentions "same block", the website mentions "same block".
Something like that at least.
Scott and the website could be wrong though, and that's apperently what
you're trying to describe below:
> The attacker only needs to know a narrow distribution of the possible
> plaintexts, where the definition of narrow depends on your attacker's
> capabilities. If you look at the various UTF formats for text and assume
> reasonable levels of entropy you'll find that many blocks will have as
> little as 4 bits of entropy (UTF-32 with English's 1 bit of entropy per
> character with a 128-bit block), this is at the level where many modern
> wristwatches have the compute power necessary.
Let's not use the "term/concept" entropy as Shannon describes it, it's way
too complex to understand it and it only applies under certain constraints
which might or might not apply when it comes to AES encryption/shuffling
(?).
http://en.wikipedia.org/wiki/Entropy_(information_theory)
There is something called UTF8 which is a compact form of UTF.
For the sake of discussion I will play along and assume the plaintext is in
utf32 which means of every 4 bytes, 3 bytes might be zero and wasted.
Which means 16 bytes / 4 = 4 utf32 characters.
Which means something like 4*8 bits = 32 bits of guess work !
The number of possibilities is roughly 2^32 which is still quite a lot of
guess work ! ;)
So when you say "4 bits of entropy" or even "1 bit of entropy" WTF are you
"talking" about ?
> You completely failed to understand Scott's statement. You have things
> exactly opposite of what he said. I suggest you try actually understanding
> what is being said, it would probably help to actually read what is
> written.
Scott seems to have described the website's attack in his own words which
again mentions "injection" capabilities into the communication stream needed
for the attack.
Scott seems to say if the injection capability into the communication stream
is not present then PM is safe ?!?
>> There is also a hidden rule in case the encryption is to be fully broken:
>> rule C: attacker must be man in the middle if messages from both victims
>> are to be decrypted.
>
> Wrong again. The attacker need only be an observer, maybe if you actually
> understood the attack it would help.
Observing what ? The communication ?
Most people call that "man in the middle".
>
>> Then there is another hidden rule:
>> rule D: attacker does not have to be man in middle, but only a sender to
>> attempt communication corruption at one or both of the victims.
>
> Now you're just making things up.
Nope this is a very simple and common attack know as "denial of service".
>> What happens if the attacker is only passive, for example, the attacker
>> is "logging/storing" the communication for later "analysis" and possible
>> "break attempt".
>
> Then the attack is easy.
How so ?
>
>> What if the first 16 bytes of the plaintext blocks is always the same,
>> which violates rule A but rule B does not apply...
>
> Then the attack is easy.
How so ?
>> Can the communication still be broken after it has taken place ?
>
> Quite easily.
How so ?
>
>> (I think not...)
>
> You think wrong.
I think good.
> Under any of the circumstances you gave, and far beyond any circumstances
> you gave, the attack on fixed-IV CBC is easy, there is a reason for the
> varying IV. I still suggest you actually read and understand even what you
> have quoted from, as you clearly have not understood it.
> Joe
I think I have proven in this message that I understand pretty well, and
it's you making all kinds of assumptions, accusations "of not
understanding", and further assumptions of "hot air", and further claims of
"easily breakable encryption systems" without providing any proof, theory,
explanation or even concepts/idea's.
Bye,
Skybuck.
Joseph Ashwood
> "Joseph Ashwood" <ash...@msn.com> wrote in message
> news:_jl0n.1687$%P5....@newsfe21.iad...
>> "Skybuck Flying" <IntoTh...@hotmail.com> wrote in message
>> news:c12e9$4b40be97$d53371df$19...@cache1.tilbu1.nb.home.nl...
>>> "Scott Fluhrer" <sflu...@ix.netcom.com> wrote in message
>>> news:12624922...@sj-nntpcache-2.cisco.com...
>>>>> Since AES uses 128 bit blocks, it would require 2^128 guesses for
>>>>> Px... which is a whole lot of guesses...
>>>
>>> Also the above text does not mention that the password must be provided
>>> as well... so that's even more guessing possibilities for just the
>>> password ?!?
>>
>> You've missed everything.
>
> You missed my point in the above text.
>
> "Also" refers to me extending the attack description since it seems
> incomplete.
That is why you missed everything. Try actually understanding the attack.
> What password will you use for AES Encrypt ?
As I stated very specifically before, this is a plaintext recovery attack,
not a key recovery attack.
>
>> The form of the attack is not a key recovery attack,
>
> I understand that, however a key must be provided to be able to "guess"
> the cipher text.
No, it does not. You are completely failing to understand anything about the
attack.
>
> As indicated by the formula on the website:
>
> "Cguess = ENCRYPT(Px XOR Cx-1)"
>
> The website does not explain that a key is needed ?
For the attack the key is not needed.
>
>>it is a plaintext recovery attack,
>
> It's plaintext-block-guessing...
>
>> the key itself may or may not remain secure.
>
> Aha ! So a key is needed ?!?
No. It is not. The plaintext is recovered, game over, the goal has been
achieved.
>
> I repeat my question:
>
> What key will be used for the guess work ?
And to repeat the answer, again, no key is necessary, this is a plaintext
recovery attack, not a key recovery attack. If you cannot understand that
very basic concept you have no hope of even understanding the concept of
encryptions.
>
> Needless to say, actually being able to "recover the key" is much more
> usefull then trying to guess the plaintext
> in the first place ?!?
No. The goal is to get the plaintext. If the plaintext can be retrieved then
the game is over, you can keep your silly little key, no one cares about it.
>
> Because guessing the "full plaintext" would require lot's of
> "plaintext-block guesses" which to me might seem infeasible.
And you'd be wrong on both counts. Guessing the full plaintext is not
necessary, just get key parts and the rest is irrelevant. Take for example
breaking SSL, the attacker really doesn't care what color panties you're
buying, but that credit card number is the entire goal. There will often be
very few blocks that need to be guessed, again the credit card example, a
credit card has only 10^16 possible numbers, this seems large, but the first
several are easily predicted, and tehre are known biases in the system,
there's probably only 31 to 32 bits worth of actual work involved in
guessing, this is nothing.
So once again, you have completely failed to understand even the simplest
aspects of the attack. I strongly suggest you actually read and understand
the attack.
>> Again, you missed everything.
>
> Yes because no reference implementation/link is given for the mentioned
> "supposed-to-be-vunerable" telnet technology/protocol/application, which
> makes it very hard to inspect it don't you think ? ;)
Not at all. the description was complete and trivial to understand.
>
>> You'll note where Scott specifically states "one character" per block,
>
> No first of all he mentions a "telnet stream", apperently telnet is a
> tcp/byte stream like protocol... so it can be considered a "stream" mode
> of operation, which is a different mode of operation:
>
> This discussion is about ECB mode and CBC mode which both work on
> "blocks".
Then you have no understanding of even what you are talking about. I didn't
even bother reading the rest.
Joe
Scott Fluhrer
> "Joseph Ashwood" <ash...@msn.com> wrote in message
> news:_jl0n.1687$%P5....@newsfe21.iad...
>> "Skybuck Flying" <IntoTh...@hotmail.com> wrote in message
>> news:c12e9$4b40be97$d53371df$19...@cache1.tilbu1.nb.home.nl...
>>> "Scott Fluhrer" <sflu...@ix.netcom.com> wrote in message
>>> news:12624922...@sj-nntpcache-2.cisco.com...
>>>>> Since AES uses 128 bit blocks, it would require 2^128 guesses for
>>>>> Px... which is a whole lot of guesses...
>>>
>>> Also the above text does not mention that the password must be provided
>>> as well... so that's even more guessing possibilities for just the
>>> password ?!?
>>
>> You've missed everything.
>
> You missed my point in the above text.
>
> "Also" refers to me extending the attack description since it seems
> incomplete.
Well, it is incomplete in the sense that to actually implement it, you need
to work out some practical details (such as how to make sure that Px is a
valid plaintext for the protocol that's being protected), but from a
cryptographical standpoint, it does list all basics.
>
> "the above text" refers to the website describing the attack:
>
> http://rdist.root.org/2008/02/05/tlsssl-predictable-iv-flaw/
>
> "does not mention that the password must be provided as well" refers to my
> conclusion that the website's description of the attack is incomplete,
> since Encrypt is refering to AES Encrypt which requires a password !
>
> "so that's even more guessing possibilities for just the password ?!?"
> refers to me asking you a question, which I will repeat and clearify here:
>
> What password will you use for AES Encrypt ?
(By password, I assume you mean AES key). The encryptor, of course, uses
whatever key that is negotiated with the decryptor. The man in the middle
doesn't use any AES key, because the attack does not require one. The only
assumption that the attack makes about the AES key is that the same key is
being used to encrypt the various messages.
>
>> The form of the attack is not a key recovery attack,
>
> I understand that, however a key must be provided to be able to "guess"
> the cipher text.
The attacker never has to guess the cipher text; he can read it from the
encrypted messages. As for guessing a plausible plaintext, the attack
assumes that the attacker can somehow limit to possibilities to a small
range.
>
> As indicated by the formula on the website:
>
> "Cguess = ENCRYPT(Px XOR Cx-1)"
>
> The website does not explain that a key is needed ?
Because, as far as the attacker is concerned, there isn't one. Instead,
ENCRYPT is modelled as an unknown (but fixed) function.
>
> Needless to say, actually being able to "recover the key" is much more
> usefull then trying to guess the plaintext
> in the first place ?!?
This is quite true; an attack that recovers the entire plaintext would be
more damaging than one that allows the attacker to recover only certain
low-entropy plaintext blocks.
However, lets look at the goal of an encryption method. In the ideal case,
an attacker would look at an encrypted system, and have no more knowledge
about what the plaintext might be than before. Now, we do have systems that
are believed to come close to this ideal case (CBC mode with a strong block
cipher and unpredictable IVs is one; it does leak some information about the
message length and the message timing, but if you stay well under the
birthday bound, that's all that a passive attacker can gain; for attackers
that can modified encrypted messages, you need further protection). Given
that we have this, why would we be interested in another mode that can be
shown to leak additional information?
>>>> This is true, IF the attacker had no apriori knowledge of what Px might
>>>> be. In that case, the attack is indeed infeasible. However, that is
>>>> not always the case. The attacker might have reason to believe that a
>>>> particular plaintext might be one of a handful of possible values. The
>>>> example used when this was first published was that the plaintext might
>>>> be a telnet stream containing the user typing in a password one
>>>> character at a time; in that case, each plaintext might consist of one
>>>> password character (with everything else being guessable by the
>>>> attacker); this attack would allow the attacker to recover the password
>>>> (by testing each block containing a password character against the
>>>> various possible ASCII characters).
>>>
>>> 26 small letters, 26 capital letters, 10 decimals, some symbols like
>>> spaces, points, comma's, question mark, etc... Quickly approaching 80
>>> symbols which is over 6 bit at least...
>>> ASCII is 7 bit, so 16 * 7 = 112 bits is still a lot of characters to try
>>> out ! ;)
>>> So the guessing space is at least: 16 * 6 = 96 bits... still a lot of
>>> guesses !
>>> And this does not even include the password bits ?
>>
>> Again, you missed everything.
>
> Yes because no reference implementation/link is given for the mentioned
> "supposed-to-be-vunerable" telnet technology/protocol/application, which
> makes it very hard to inspect it don't you think ? ;)
>
>> You'll note where Scott specifically states "one character" per block,
Actually, one character per message.
>
> No first of all he mentions a "telnet stream", apperently telnet is a
> tcp/byte stream like protocol... so it can be considered a "stream" mode
> of operation, which is a different mode of operation:
No, telnet (RFC854 if you care) is a method of converting typed information
(and the ASCII back from the computer) into packets; I thought your mode was
designed to be interesting for packet/communications protocols.
>
> This discussion is about ECB mode and CBC mode which both work on
> "blocks".
>
> So when scott wrote "one password character in the plaintext" I assumed he
> ment "one password character per ECB/CBC block" and the rest being
> garbage, zero, or telnet communication. That's what I assumed he ment with
> "guessable by the attacker".
If you user types a character (be it a password character or anything else),
telnet will generate a packet that consists of an IP header, a TCP header
and that one character. If the TCP stack doesn't randomize things (and some
don't), then that one character will be in a block that is otherwise totally
predictable by the attacker.
>>> Was the mention attack actually succesfull and how long did it take ? ;)
>>
>> I'm not sure if it was ever implemented,
It was demonstrated in a test lab. I don't know if it was actually used in
a real attack (I suspect not, however real attackers generally don't publish
what they did).
>
>>
>>>> To answer your general question (or, rather, the question you should
>>>> have been asking), in the right situation PM can be secure (private).
>>>> However, that security will hold only if the plaintext data is
>>>> "well-behaved" (e.g. that no two plaintext blocks start with the same
>>>> 16 byte prefix), and on the assumption that an attacker cannot inject a
>>>> message with a chosen 16 byte prefix.
>>>
>>> Ok so the security of PM is broken only if rule A and rule B apply at
>>> the same time:
>>>
>>> So rule A is: plaintext blocks start with the same 16 bytes.
>>> So rule B is: attacker must be able to inject packets/blocks.
>>
>> Wrong on both counts.
>
> Nope, that's how Scott and the website describe it.
Actually, PM is broken if either:
- Plaintext messages start with the same 16 bytes
or
- The attacker is able to inject plaintext messages before encryption
These are caused by two separate weaknesses.
- The problem with two separate plaintext messages starting with the same
16 bytes means that the resulting ciphertext messages will also start with
identical 16 byte prefixes. This allows the attacker to deduce the
relationship between the plaintext messages (and remember, the goal is that
the attacker gets no information).
- The problem with injected plaintext messages is the main body of the
paper you cited. Now, it also assumes that there are low entropy plaintext
blocks; however if this is to be used to protect general packet traffic,
that's an assumption that you have to make.
>
> Scott seems to have described the website's attack in his own words which
> again mentions "injection" capabilities into the communication stream
> needed for the attack.
>
> Scott seems to say if the injection capability into the communication
> stream is not present then PM is safe ?!?
Nope: see weakness #1. In any case, are you sure that is a safe assumption?
If you are protecting VPN traffic, it is quite plausible that someone might
be able to forward his own traffic over the connection.
>
>>> There is also a hidden rule in case the encryption is to be fully
>>> broken:
>>> rule C: attacker must be man in the middle if messages from both victims
>>> are to be decrypted.
>>
>> Wrong again. The attacker need only be an observer, maybe if you actually
>> understood the attack it would help.
>
> Observing what ? The communication ?
>
> Most people call that "man in the middle".
No, a "man in the middle" is someone who can modify traffic.
When designing a protocol designed to provide privacy, we always assume
someone is able to look at the encrypted traffic. After all, if no one can
look at the encrypted traffic, then anything (including just forwarding the
plaintext) is secure.
>
>>
>>> Then there is another hidden rule:
>>> rule D: attacker does not have to be man in middle, but only a sender to
>>> attempt communication corruption at one or both of the victims.
>>
>> Now you're just making things up.
>
> Nope this is a very simple and common attack know as "denial of service".
That's a "man in the middle" (which can often do things beyond a simple
denial of service). Yes, that is a valid concern. We've been focusing in
on passive attackers, to foil an active attacker, you need something else
added to the protocol (such as a MAC). Neither PM nor CBC gives much
protection there.
--
poncho
Skybuck Flying
>>
>> "Cguess = ENCRYPT(Px XOR Cx-1)"
>>
>> The website does not explain that a key is needed ?
>
> Because, as far as the attacker is concerned, there isn't one. Instead,
> ENCRYPT is modelled as an unknown (but fixed) function.
So more missing information on the website ?
The ENCRYPT function seems quite crucial since it transforms (Px xor Cx-1)
(into the ciphertext/output)
The transformation of (Px xor Cx-1) must happen the same way as it happens
on the "sender" and the "receiver".
The AES key influences the transformation... Only the correct AES key
produces a correct transformation (?!?)
If the wrong AES key is used the transformation happens differently... if a
ciphertext matches then this does not mean that the plaintext was what was
actually send... it's just plaintext garbage that happens to output the same
ciphertext with a wrong aes key.
The actual plaintext remains unknown.
It's the same as saying:
"I am going to output some random numbers based on some plaintext randseed
bullshit and if it happens to match the ciphertext and then I know what the
plaintext was..."
That is ofcourse total bullshit... if it's not total bullshit than AES is a
very weak cipher ! ;)
Bye,
Skybuck.
Scott Fluhrer
>>> As indicated by the formula on the website:
>>>
>>> "Cguess = ENCRYPT(Px XOR Cx-1)"
>>>
>>> The website does not explain that a key is needed ?
>>
>> Because, as far as the attacker is concerned, there isn't one. Instead,
>> ENCRYPT is modelled as an unknown (but fixed) function.
>
> So more missing information on the website ?
>
> The ENCRYPT function seems quite crucial since it transforms (Px xor Cx-1)
> (into the ciphertext/output)
Yes. However, the attacker can successfully obtain the value ENCRYPT(Px XOR
Cx-1), even though he has no idea what the encryption key is (!). Here is
how he does it:
- He computes the value (Px XOR Cx-1)
- He creates a plaintext message whose first 16 bytes is the value (Px XOR
Cx-1)
- He gives ("injects") the message to the encryptor for encryption
- He then captures the corresponding encrypted message, and extracts the
first 16 bytes.
If you look at what PM does, the first 16 bytes of the encrypted message is
the ECB encryption of the first 16 bytes of the plaintext message. Or, in
other words, it is ENCRYPT(Px XOR Cx-1).
One way of looking at it is that we're tricking the encryptor to do the work
for us. Since the encryptor has the keys, it has no problem computing it
for us.
There have also been ways proposed to trick the decryptor to do the work;
both Bellovin and Vaudenay have publised ways to do that with CBC. However,
they both involve the attacker modifying an encrypted message, and so can be
foiled by a MAC (indeed, when Bellovin proposed his technique, it was as a
support to his argument that IPsec should always include integrity
protection).
--
poncho
Maaartin
> > Because, as far as the attacker is concerned, there isn't one. Instead,
> > ENCRYPT is modelled as an unknown (but fixed) function.
> So more missing information on the website ?
No! Modelling something as unknown function means assuming you do not
know it. It has nothing to do with the (in)completeness of the web
page.
> That is ofcourse total bullshit... if it's not total bullshit than AES is a
> very weak cipher ! ;)
Obviously, you're missing something. The attack is not specific to
AES, it works the same way for any block cipher.
Skybuck Flying
>
> "Skybuck Flying" <IntoTh...@hotmail.com> wrote in message
> news:bb893$4b4374cb$d53371df$38...@cache1.tilbu1.nb.home.nl...
>>>> As indicated by the formula on the website:
>>>>
>>>> "Cguess = ENCRYPT(Px XOR Cx-1)"
>>>>
>>>> The website does not explain that a key is needed ?
>>>
>>> Because, as far as the attacker is concerned, there isn't one. Instead,
>>> ENCRYPT is modelled as an unknown (but fixed) function.
>>
>> So more missing information on the website ?
>>
>> The ENCRYPT function seems quite crucial since it transforms (Px xor
>> Cx-1) (into the ciphertext/output)
>
> Yes. However, the attacker can successfully obtain the value ENCRYPT(Px
> XOR Cx-1), even though he has no idea what the encryption key is (!).
> Here is how he does it:
>
> - He computes the value (Px XOR Cx-1)
> - He creates a plaintext message whose first 16 bytes is the value (Px XOR
> Cx-1)
> - He gives ("injects") the message to the encryptor for encryption
http://rdist.root.org/2008/02/05/tlsssl-predictable-iv-flaw/
The website mentions this for the TLS 1.1 protocol:
"
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.
"
What is a "Shared TLS/SLL VPN connection" ?
So the website itself more or less mentions that this attack is not
realistic except for this very specific protocol.
Ofcourse there could be other vunerable protocols and maybe other ways to
inject plaintexts into victim's communication... but let's assume for a
moment that that's not possible... what happens to PM when it's not possible
? ;) That's my question :)
> - He then captures the corresponding encrypted message, and extracts the
> first 16 bytes.
>
> If you look at what PM does, the first 16 bytes of the encrypted message
> is the ECB encryption of the first 16 bytes of the plaintext message. Or,
> in other words, it is ENCRYPT(Px XOR Cx-1).
>
> One way of looking at it is that we're tricking the encryptor to do the
> work for us. Since the encryptor has the keys, it has no problem
> computing it for us.
PM would be safe if used over/on top of TLS, since the flaw is with TLS not
with PM itself ;) unless there is something else wrong with PM ? ;)
> There have also been ways proposed to trick the decryptor to do the work;
> both Bellovin and Vaudenay have publised ways to do that with CBC.
> However, they both involve the attacker modifying an encrypted message,
> and so can be foiled by a MAC (indeed, when Bellovin proposed his
> technique, it was as a support to his argument that IPsec should always
> include integrity protection).
If you provide a link to some information, maybe we can discuss that next ;)
Bye,
Skybuck.
Skybuck Flying
"Maaartin" <graj...@seznam.cz> wrote in message
news:6e68d860-0651-4ee8...@34g2000yqp.googlegroups.com...
I doubt it... but you welcome to prove it ! ;) :)
Bye,
Skybuck =D
Scott Fluhrer
If you understood the attack, you would see that not only would it apply to
any block cipher, it would also apply even if the attacker had no clue about
what block cipher was being used (he only needs to know/guess the block
size).
--
poncho
Skybuck Flying
If it's that simple then surely you or anybody else can supply some pseudo
code or god forbid some real code ? ;)
Otherwise it shall remain in the land of the fairytales ;) :)
Bye,
Skybuck.
Tom St Denis
wrote:
> "Scott Fluhrer" <sfluh...@ix.netcom.com> wrote in message
>
> news:12634908...@sj-nntpcache-3.cisco.com...
>
>
>
>
>
> > "Skybuck Flying" <IntoTheFut...@hotmail.com> wrote in message
> >news:2f9f0$4b4bdba8$d53371df$27...@cache2.tilbu1.nb.home.nl...
>
> >> "Maaartin" <grajc...@seznam.cz> wrote in message
> >>news:6e68d860-0651-4ee8...@34g2000yqp.googlegroups.com...
> >> On Jan 5, 6:20 pm, "Skybuck Flying" <IntoTheFut...@hotmail.com> wrote:
>
> >>> That is ofcourse total bullshit... if it's not total bullshit than AES
> >>> is a
> >>> very weak cipher ! ;)
>
> >> "
> >> Obviously, you're missing something. The attack is not specific to
> >> AES, it works the same way for any block cipher.
> >> "
>
> >> I doubt it... but you welcome to prove it ! ;) :)
>
> > If you understood the attack, you would see that not only would it apply
> > to any block cipher, it would also apply even if the attacker had no clue
> > about what block cipher was being used (he only needs to know/guess the
> > block size).
>
> If it's that simple then surely you or anybody else can supply some pseudo
> code or god forbid some real code ? ;)
>
> Otherwise it shall remain in the land of the fairytales ;) :)
Work it out yourself?
Seriously, Scott doesn't work for you.
Tom
Skybuck Flying
"Tom St Denis" <t...@iahu.ca> wrote in message
news:540a3338-ed33-4c28...@22g2000yqr.googlegroups.com...
"
Work it out yourself?
Tom
"
Well I say: I doesn't work in the first place, so what am I supposed to work
out... ?
I could test out a "non working idea"... but I rather do it vice versa ! ;)
So you or anybody else prove to me that it works... and then I will happily
verify that work ! ;) (by programming and testing it myself ;))
Bye,
Skybuck.
Maaartin
wrote:
> "Tom St Denis" <t...@iahu.ca> wrote in messagenews:540a3338-ed33-4c28...@22g2000yqr.googlegroups.com...
But it is you, who wants/should learn something. When Tom St Denis and
Joseph Ashwood (I don't remember Scott Fluhrer's postings, so I can't
name him here) say it works, you can be pretty sure it does. You
should learn to tell people knowing more than you (about crypto) from
the others and learn from the former. I don't think they need to work
hard to convice you that it works, 'cause there're sure it does (and
'cause they get nothing for it).
Actually, even I can see it works. Sure, it doesn't mean you can read
TLS/SSL ciphertext like a book, but it definitely is an attack. Try to
read it again or try to find an error there.
Skybuck Flying
Denis said no such thing.
"
Joseph Ashwood (I don't remember Scott Fluhrer's postings, so I can't
"
I dealt with him, he didn't deal with my questions.
"
name him here) say it works, you can be pretty sure it does. You
should learn to tell people knowing more than you (about crypto) from
the others and learn from the former. I don't think they need to work
hard to convice you that it works, 'cause there're sure it does (and
'cause they get nothing for it).
Actually, even I can see it works. Sure, it doesn't mean you can read
TLS/SSL ciphertext like a book, but it definitely is an attack. Try to
read it again or try to find an error there.
"
Anybody can claim something works on usenet, doesn't cut you any slack.
No proof then no pudding ! ;) :)
Bye,
Skybuck =D