Reputation
44,594
Next tag badge:
391/400 score
82/80 answers
Badges
1 50 106
Newest
 dsa
Impact
~740k people reached

May
23
comment Hash length extension attack - SHA256 to 512 - impossible, correct?
@MaartenBodewes: yes; different initial values would. In fact, that's precisely the reason why (for example) SHA-256 and SHA-224 use different initial values.
May
22
answered Break El-Gamal Algorithm by knowing the value of the random k
May
22
reviewed No Action Needed What is an active S-Box?
May
22
reviewed Reviewed Break El-Gamal Algorithm by knowing the value of the random k
May
22
revised Break El-Gamal Algorithm by knowing the value of the random k
edited body
May
22
answered Hash length extension attack - SHA256 to 512 - impossible, correct?
May
21
reviewed No Action Needed Finding Patterns in Encrypted Data
May
21
reviewed No Action Needed The difference in size between ECDSA output and hash size
May
21
reviewed Close how does an initialization vector work?
May
20
awarded  Popular Question
May
20
comment Would this method deliver a perfectly non-malleable encryption for at least two blocks?
@StevePeltz: how would you decrypt? In any case, I suspect Anon2000 is looking for a mode that doesn't do any ciphertext expansion
May
20
revised Would this method deliver a perfectly non-malleable encryption for at least two blocks?
added 330 characters in body
May
20
comment Would this method deliver a perfectly non-malleable encryption for at least two blocks?
@Anon2000: how in the world would you be able to decrypt with your suggestion? If the decryptor got a ciphertext $(A,B)$, how does he guess whether to use the normal method, or whether he should use the derived key? As for figuring out the answer, well, that's straightforward; start with a ciphertext with two identical blocks, and step through the decrypt process
May
20
answered Would this method deliver a perfectly non-malleable encryption for at least two blocks?
May
20
reviewed No Action Needed P10 to P8 in S-DES
May
19
comment Has a collision ever been found for SHA-1/2/3 when truncated to 128 bits?
@Anon2000: nope; remember, the cycle is unlikely to include the beginning value; instead, there'll be a series of unique values, and then you'll hit the cycle. Now, you could arbitrarily zero out the XOR after it's likely you've entered the cycle; that'll allow to do detect the size of the cycle; it's not as clear how you'd find out how you entered the cycle (which is what you're really interested in)
May
19
comment Has a collision ever been found for SHA-1/2/3 when truncated to 128 bits?
@Anon2000: I don't see how you would make it work. When you hit a cycle, the XOR wouldn't zero out (as the values prior to when you hit the loop wouldn't zero out); instead the XOR's would return to values you've previously seen. And, looking for values previously seen is the problem we're trying to solve...
May
19
comment Has a collision ever been found for SHA-1/2/3 when truncated to 128 bits?
@Anon2000: yes, the method that SOJPM suggested is known as rho cycle finding. The approach that I suggested (which is rather different) is more related to the Hellman time-memory tradeoff. I suspect the method I suggested is more practical (for one, it's more parallelizable; rather important if you're contemplating $2^{64}$ computations...)
May
19
comment Has a collision ever been found for SHA-1/2/3 when truncated to 128 bits?
@Anon2000: one obvious way is to do iterated hashing (where we compute $x_i = Hash_{128}(x_{i-1})$, and stop at distinguished points (say, the first 32 bits are all zero), and store the initial/final values in a table. Build up a long list of such table entries (circa $2^{32}$ should do), and look for collisions in the final value -- if we find one, then the two chains merge (and finding where the chains merge is straight-forward). That's not a zero-memory solution, however it gets the memory requirements small enough...
May
19
comment Has a collision ever been found for SHA-1/2/3 when truncated to 128 bits?
Also note that there are ways to search for such a collision that radically reduce the amount of memory required (at not that huge of a computational cost).