From: Skybuck Flying on
>> 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)

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.


From: Scott Fluhrer on

"Skybuck Flying" <IntoTheFuture(a)hotmail.com> wrote in message
news:bb893$4b4374cb$d53371df$3886(a)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
- 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


From: Maaartin on
On Jan 5, 6:20 pm, "Skybuck Flying" <IntoTheFut...(a)hotmail.com> wrote:
> > 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.
From: Skybuck Flying on

"Scott Fluhrer" <sfluhrer(a)ix.netcom.com> wrote in message
news:1262820820.179477(a)sj-nntpcache-2.cisco.com...
>
> "Skybuck Flying" <IntoTheFuture(a)hotmail.com> wrote in message
> news:bb893$4b4374cb$d53371df$3886(a)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.


From: Skybuck Flying on

"Maaartin" <grajcar1(a)seznam.cz> wrote in message
news:6e68d860-0651-4ee8-b2d0-54800de62eca(a)34g2000yqp.googlegroups.com...
On Jan 5, 6:20 pm, "Skybuck Flying" <IntoTheFut...(a)hotmail.com> wrote:
> > 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.
"

I doubt it... but you welcome to prove it ! ;) :)

Bye,
Skybuck =D