Hi, thanks. Having WPA2 in AES CBC mode, what attacks are possible with KRACK? IMHO just an AES plain text attack against the first block. is that correct?

@Chris2013 basically, atleast up until the first unpredictable block

Then I don't understand.

well I'm not that familiar with what goes on after a key reset (if there is any protocol stuff that is always the same)

even if IV (Nonce) is the same this will not help you

as soon as a block differs you won't be able to decode any future blocks until you reset the key again

and then only the first parts

and - you wont be able to decrypt unknown frames

right, but you could potentially still do a timing attack

if you time the reset right

as I said, its just a known plaintext attack against AES, right?

more or less, yes

it's a bit different since you have a way to get at the keystream though for one block

ok, and what web sources say, decrypting the data is not possible easily? We don't have a repeateing key stream in WPA? every block is encrypted differently?

so, say for example, I knew you were about to send your password over your wifi, I could start flooding you with key resets hoping that your password would appear in the first block after a reset

b/c I dont find any references to a key stream in WPA2 spec?

ok, still. known plaintext attack

not exactly because a pure known plaintext attack wouldn't imply knowledge of the keystream

at all

because the nonce would normally complicate that

key replay changes the equation, but with CBC it only changes it for the first block that differs

for CTR it changes it for all blocks, same for RC4 (TKIP)

ok

so, 2nd and all following blocks are "safe"...

right, but I can flood you with resets to make a high percentage of your blocks unsafe

because a lot of them will be first blocks

yes, got that. and if I transmitted completely random data in 1st block, would you be able to decrypt it with flooded nonce resets?

if I can completely control the network, I can slow it down enough to make every block a first block

no

got it

but at that point you can just alter it to prevent nonce reuse

and the problem goes away anyway

only if the first block was consistent (say if it was unchanging protocol information) as soon as a block is different from your previous examinations, the keystream changes in a chaining cipher

which is, in fact, the main point of a chaining cipher

the weakness being if you miss a piece, you have to start over

ok, now I think I got it...

so CBCs are very weak against losing data to corruption

since one bad block kills all future blocks

yes, but by design I guess

indeed

but it's a potential problem for something like radio communication

which could have a significant slowing impact on your network performance

hence why CTR is an option with the AES implementation used for WPA

cause CTR is silly dumb as far as keystream security, but it's also reliable against dropped packets (and still ok as long as the nonce stays unique)

the keystream is part of AES and RC4, not part of WPA directly

basically, almost all modern encryptions work by forming something to xor against the input

so the encryption algorithms are really a means of making a keystream

and then applying it to the plaintext stream to key the crytostream

what makes it a stream is it is something that can keep going as long as you need it to

then I dont get it: in CBC, is the encryption not independent from each block?

so AES resets for each block?

no

in CBC it is completely dependent

really??

yes, the /input/ is xor'ed

yes, the algorithm is taking the output of the previous block and combining it with the key to make the next block's keystream

but the AES encryption is not affected?

that's what makes it chaining

ok

a keystream in AES is built one block at a time

and the various modes impact how the next block of the keystream is built (and may also impact other things like authenticity checking)

ok, so after a few known plaintext attacks against the keystream (not aes session key) I know enough bits to recover significant portions of the stream and can decrypt everything

significantly small, that is.

oh, I see, part of the trick is that you are looking at the way that the image on wikipedia puts it. You can look at it as xoring the last output with the input or as part of the keystream construction. They are the same thing

because the keystream is really what gets xor'd to the plaintext and order of xors doesn't matter

yes, I understand. while the WIKI described CBC in general, this is not what's used in WPA2

so plaintext xor previous block value xor key derived value doesn't matter which order you apply them in, the xor between plaintext and cyphertext is the keystream, so it's the result of all the things being combined

+1

@Chris2013 you can decrypt only the parts of the keystream you have solved

yes, of course

and actually, thinking about it a bit more, it might be a bit more complicated on AES even in ctr, because now I'm trying to remember if the input ends up impacting the keystream within the block or not. It's been a long time since I dealt with the nitty gritty of AES (I studied it in depth in 2005, but that was a long time ago)

I can't remember if there is some transposition caused within block by the key or not

either way, the general conclusion remains the same that TKIP = worthless with reuse, CTR is not great either, but may be better, and CBC is the best you can hope for without a software fix to the nonce reuse

RC4 I know for sure breaks horribly though as I've written my own RC4 nonce reuse decryptors from scratch

got it. Big thanks, man!

yeah, but this was pusblished a long while ago :D

guess that no one uses wEP anymore

yeah, well that's the CRC issue which is something else for wep, but yeah, wep is a mess

:D

TKIP uses RC4 too though

yes, I guess that this could count as compromised now too

well again, it's really just a WPA problem

the issue is that WPA has a replayable handshake

fix that and TKIP is still okish

+1

still not super fantastic, but it's hard to beat the speed and in ideal circumstances it isn't horrible for keeping someone off a home network for example

that said, I still prefer AES whenever possible, but there are still a few legacy devices that don't have support that have kept TKIP on on my home network

yes, also, you'd need some big antennas to make a client associate with your channel

if the client selects the loudest sender

or just move somewhere down the street and get them when they drive by

since most devices associate automatically when in range

but yes, that's the biggest reason the amount of "fire" yelling is lower than you'd expect

yes, but you need to maintain connection to the original AP

it's difficult to mass use this particular attack in a meaningful way

interesingly, will relay attacks be possible :D

it's not good for sure

but you have to be local to use it

@Chris2013 not neccessarily

oh really? thinking monitor mode here.........

you just need the exchange from some time

yes, thought so

you need to get a keystream from when you are close, but could use that replay anytime anywhere

exactly

alright man, gtg, big Thanks again!

@Chris2013 np

Hey all... if I may pop in and ask a quick question: what would you recommend as a good tool for testing the strength of a password? Something more informative than those "weak/strong/very strong" password meters, and perhaps something that gives a sense of how long it would realistically take an attacker to crack the password with some reasonable assumptions on hash speed.

@DavidZ None. Password strength is all about how the password is generated. You can't tell from only seeing the result.

Maybe I shouldn't say "strength", then, but what I want to know is how long I can expect a given password to hold out against cracking attempts given reasonable/typical assumptions about the methods used to crack it

I know that there is a concept of "strength" which is associated with a password generation method, rather than a password itself, and that's not what I'm interested in

Mind you, this whole question is more for curiosity than practical use

@DavidZ that depends on how the password is stored, and that varies enormously

how long is a piece of string?

@Gilles So, not even something that will give me a result like "likely to be guessed in 2 trillion attempts on average"?

(or whatever number)

@DavidZ No. Consider those extremes: 1. password in stored clear text, database breached, the end. 2. Password stored in a hardware security module, the server gets breached but not the HSM, the HSM erases the password after 10 attempts, any password that isn't completely stupid is safe.

Ah, good point.

If I restrict the question to storage methods where the attacker has an unlimited number of guesses each of which returns "correct" or "incorrect" but no other information - as in having a salted hash and trying to determine the original password that created it, that's what I'm mostly curious about. I guess it comes down to running a password cracker though.