# Tag Info

2

Your first approach $H'(m) = H(H(m)) || H(m)$ will not have any improvement collision resistance. The reason being is that a collision in the right half automatically causes a collision in the left half, since the output of $H$ is identical for the colliding messages. The left half is not a function of the message, but of the message hash, the concatenation ...

1

As I understand it, preimage resistance means that it is hard for an adversary to find two messages that produce the same digest Nope: collision resistance means that it is hard for an adversary to find two (distinct) messages that produce the same digest. Preimage resistance means that, given a hash output, it is hard for an adversary to find a ...

0

GMAC, for example, is trivially broken if used as an unkeyed hash algorithm. GMAC is effectively a series of operations on blocks where you take the previous state, XOR it with the next block, then multiply it in $GF(2^{128})$ by the derived secret subkey $H$. That is, for data block $A_i$, the next hash value is computed from the previous one as follows: ...

1

First since E is an encryption algorithm, it has a Decryption counterpart, lets name it D. From the correcntess equation we get that $E(x,D(x,c)) = c$ for every $x$. Then we can easily see that if $$y= x \oplus D(x,c)$$ then $$f_2(x,y) = E(x, y \oplus x) = E(x, x \oplus D(x,c) \oplus x) = E(x,D(x,c)) = c$$ Again this holds for every $x$. So we have just ...

2

The specific attack you describe doesn't seem possible, because, at the point where the fake client would need to commit to a nonce, the server doesn't yet know the other clients' nonces, but only their hashes. Provided that the nonces have sufficient entropy to resist brute force attacks, it should not be possible force the server to learn them just from ...

0

Just to show you how easy it is today to create collisions on MD5: One could create collisions using Marc Steven's HashClash on AWS and estimated the the cost of around $0.65 per collision. These 2 images have the same md5 hash: 253dd04e87492e4fc3471de5e776bc3d (If you want to test it yourself, take images from the link below, after uploading ... -1 Now the standard key size for RSA is recommended of 2048 bits. This is large enough to never having a collision in practice, where brute force is 2^{2048}. Even if we consider some attacks that allow to break it with half the key size or in birthday attack, this number is quite secure. However, larger the key size, more overhead and lower efficiency. 1 One possibility is the sloth and unicorn approach of this paper. The idea is essentially to use a slow (but quickly verifiable) hash. If the sever publishes a commitment to all the shares within a few seconds of the start of the hash computation (which will start at a agreed-to time), and the hash can't be done in less than an hour, then the server can't ... 1 While it is well known that hash1(hash2(x)) only serves to increase collisions, Collisions essentially do not matter at all for password hashing. You will only lose entropy to collisions if the input entropy is near the size of the hash output. And in that case you are well and truly out of the realm of what can be cracked for any popular hash function. ... 1 There are two ways of going about this: create a hash tree (or, as it is only one deep, a hash list); create a canonical representation of the strings; For the first option you simply hash each string, and then hash all the resulting hashes. As the hashes should not have collisions, you can be certain that the resulting hash doesn't collide either. In ... 0 Yeah, the usual solution for this problem is to prepend the length of each string (in bytes) then concatenate them into one large array and hash the whole shebang. E.g., [john, smith] becomes the string "4john5smith". 2 A password manager that produces 16-character passwords is sufficient for most cases. Users who go for 100-byte passwords are usually overly-paranoid, since the actual security benefit is outweighed by the inconvenience. Therefore, limiting a password to 72 characters, while in theory reducing the number of possible passwords, is still very reasonable. ... 1 I'm answering the questions I posed. While cygnusv answer was correct for the idea I presented, it was not helpful to me as I had already identified and solved that issue, but failed to present the correct algorithm in my question. I'm not saying cygnusv is wrong; the answers presented are very much correct and I gave a +1. However, there were more questions ... 0 Your reasoning is correct. Finding a collision will solve the discrete-logarithm problem. This is actually what Pollard's Rho does. If you can find$g^{x_1}h^{x_2} = g^{y_1}h^{y_2}$then you can compute the discrete logarithm of$hg^{x_1}h^{x_2} = g^{x_1 + kx_2}x_1 + kx_2 = y_1 + ky_2x_1 - y_1 = k(y_2 - x_2)(x_1 - y_1)(y_2 - x_2)^{-1} = k$... 2 Yes, this logic works. You have shown that given the discrete log$x$lets you easily find collisions. Now you need to show that any collision lets you extract the discrete log$x$and then you are done (then you have shown the equivalence). 5 You are right that if it costs Alice & Bob effort$N$to agree on a key in this way, then it costs Eve only effort$N^2\$ to find it. So the protocol is not secure in the standard sense, and probably not very useful. (Maybe in some highly constrained situation with very short-lived keys?) More generally, this purports to be a key agreement protocol whose ...

Top 50 recent answers are included