New mode for AES: "Packet Mode" [Cryptography]

Prev: SK_ASCII - Scalar Key Cryptography - Cipher
Next: GSM Encryption

From: Scott Fluhrer on 2 Jan 2010 23:17

"Skybuck Flying" <IntoTheFuture(a)hotmail.com> wrote in message
news:72c23$4b3e5d56$d53371df$4009(a)cache2.tilbu1.nb.home.nl...
>
> "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...

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

From: Skybuck Flying on 3 Jan 2010 10:58

"Scott Fluhrer" <sfluhrer(a)ix.netcom.com> wrote in message
news:1262492262.441110(a)sj-nntpcache-2.cisco.com...
>
> "Skybuck Flying" <IntoTheFuture(a)hotmail.com> wrote in message
> news:72c23$4b3e5d56$d53371df$4009(a)cache2.tilbu1.nb.home.nl...
>>
>> "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...

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.

From: Joseph Ashwood on 4 Jan 2010 06:22

"Skybuck Flying" <IntoTheFuture(a)hotmail.com> wrote in message
news:c12e9$4b40be97$d53371df$19099(a)cache1.tilbu1.nb.home.nl...
> "Scott Fluhrer" <sfluhrer(a)ix.netcom.com> wrote in message
> news:1262492262.441110(a)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. 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

From: Joseph Ashwood on 4 Jan 2010 21:41

From: Scott Fluhrer on 5 Jan 2010 11:35

"Skybuck Flying" <IntoTheFuture(a)hotmail.com> wrote in message
news:689b5$4b423de6$d53371df$596(a)cache4.tilbu1.nb.home.nl...
> "Joseph Ashwood" <ashwood(a)msn.com> wrote in message
> news:_jl0n.1687$%P5.1446(a)newsfe21.iad...
>> "Skybuck Flying" <IntoTheFuture(a)hotmail.com> wrote in message
>> news:c12e9$4b40be97$d53371df$19099(a)cache1.tilbu1.nb.home.nl...
>>> "Scott Fluhrer" <sfluhrer(a)ix.netcom.com> wrote in message
>>> news:1262492262.441110(a)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

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