# Tag Info

12

Does having a hash of a password jeopardize the security of plaintext that was encrypted with that password? As usual in password-based cryptography, we'll consider that the password was chosen from a relatively small set, small enough that password enumeration by an adversary can generate passwords including the one of a target user with fair probability, ...

5

Solving a 256-bit discrete log is absolutely doable, and quite quickly, these days; there are public tools that can do it, though they may require some expertise to use. On that note, even a 1024-bit modulus is not particularly conservative: it is generally agreed that well-funded organizations today could break logs of that size as well, but at a very ...

4

If you add a truly random character into a truly random position of a word (uniformly chosen), you get "entropy of position" + "entropy of character" as addition to the entropy of the word. (Not exactly, it's a bit less). The entropy of character is the size of the possible characters. 64 possible characters would be $log2(64) = 6$ bits of entropy. Entropy ...

4

If the public modulus was generated properly, option 2 (brute force dictionary search of candidate plaintext) will be faster. Option 1 (factoring a ≈512-bit RSA integer) is feasible, but can be quite compute-intensive even with the best known algorithm (GNFS). On the other hand, if random padding was used (as it should, and would be in any good practice), ...

4

Rainbow tables are not complete. But some have good coverage. We estimate how many distinct hashes are covered by a rainbow tables using statistical tools. We can build perfect rainbow tables where we throw out colliding chains. This reduces redundancy in the final table. But even in a "perfect" rainbow a certain hash can appear twice(but not in the same ...

3

As far as I understood the problem, the difference between IKEv1 Aggressive and Main Mode is how the hashed PSK is sent. Of course, the PSK itself is never sent to the other side as both sides need to prove to each other that they know the PSK and if one side was sending it to the other one, of course, the other one will now know it. Instead, each side ...

3

You're using bytewise xor, and three plaintexts $x,y,z$ with a small alphabet (A-Z, which I assume means ASCII values 0x41-0x5a). Then knowing $a \oplus x$, at a certain index, we know all possible values of $a$, at that same index, namely $\{0x41 \oplus (a \oplus x),\ldots, 0x5a \oplus (a \oplus x)\}$. But we have 2 more constraints from $a \oplus y$ and $a ... 2 Being able to solve the discrete logarithm in SRP-6 allows an eavesdropping attacker to dictionary attack the password. It will not directly reveal a strong password or its hash. It requires the attacker to observe a successful authentication,$B$alone does not suffice. The attacker eavesdrops$s$,$A = g^a$,$B$and$M_1$. The attacker solves$a$from$A$.... 2 The question is well answered by ninefingers, but the question exposes fundamental confusion on the part of Mitchell. The NT Hash is not salted, and it IS PASSWORD EQUIVALENT. There is no need to use the hash to get the password, just use the hash to access the resource! Second, the password must be greater than 14 characters to avoid the LM hash, see MS ... 2 Suppose the server did not include$v$in the computation of$B$. In such case the following events have happened: The server has sent a salt value$s$to the client. We might assume it is authentic (because it is easy for the fake server to get it from the real server). The client re-calculates its long term private key$x$such that$v = g^x$. The client ... 2 If you ask a computer to pick a sequence of four words out of 10 000 (with replacement) uniformly at random, there are about$2^{53}$possibilities; an attacker can expect to guess$2^{52}$of them before getting the right one. (For scale comparison, the Bitcoin network guesses and tries thousands of times more possible inputs than that to a hash every ... 2 The property of SRP is that: If the attacker is a passive listener to an exchange between a client and a server, he learns nothing about the shared password If the attacker is a participant in the exchange with either a client or a server with the password (or modifies the exchange between the client and the server), the attacker learns nothing except for ... 2 And I checked some related works, and most of them only considered the dictionary attack and forward security. Actually, a PAKE has two security goals: That someone cannot recover the password from a number of exchanges (with any greater advantage than being able to test$N$potential passwords using$N\$ active attacks). That someone will not be ...

1

If you have a secret key (256-bits) shared between the two systems that see the entity identifiers, you can use HMAC-SHA256 to map entity identifiers to a random string. Under the assumption that HMAC-SHA256 security is good (which is widely believed to be a reasonable one), this is just as secure as having generated a truly random mapping, but requires ...

1

But this proof value must be something both the client and the (legitimate) server can compute, and thus it must be entirely determined by: values chosen by the client and sent to the server during the authentication process, values chosen by the server and sent to the client during the authentication process, and the password and/or the verifier (which ...

Only top voted, non community-wiki answers of a minimum length are eligible