Date: Thu, 3 Sep 2015 03:34:54 +0300 From: Aleksey Cherepanov <lyosha@...nwall.com> To: john-dev@...ts.openwall.com Subject: reverse of full sha1 and sha256 limb when hash and block are known tl;dr: if W and hash are known, initial state can be computed. ... PROFIT! Looking at sha1 round, it is obvious that each round can be computed backwards (i.e. starting from hash and going to initial state): consider a, b, c, d, e after round known, then there are only 2 unknown variables: w[i] and e at the beginning of round. So knowing w[i], it is trivial to right a formula to compute e. This way we go reverse. sha256 is a bit more complex, but it has only 1 unknown variable too. So it is possible to write reverse algo straight-forward. PoC is attached. So sha1 and sha256 behave like block ciphers: you "encrypt" initial state ("block of data") with W, that is expanded block of message ("key"). And it is possible to "decrypt" hash to get initial state. There are several applications. The following 2 were pointed out to me by Alexander Cherepanov, there are my ideas then. 1) To check 1 password against 1 hash, it is possible to meet in the middle computing halves in parallel. First of all, it is interleaving, but it is possible to vectorize shared part of regular and reverse algorithms. It is possible to speed up defensive usage this way. 2) To check 1 checksum against 1 big file, it is possible to compute checksum using 2 threads. (But usually(really?) checksums are checked for multiple files at the same time, thus multithreading is already there.) 3) Passwords longer than 1 block with repeating tails and same length have trade off: 1 computation for each hash for each tail or 1 full computation for each passwords. Lengths 56-64 (inclusive) need 2 limbs but second block does not change at all (1 value for each length). 4) It is possible to hash beginning and tail independently if memory permits: compute initial states for each tail for each hash, put all of them into bitmask (lookup table), compute beginnings and check against the bitmask. (Is not it called "meet in the middle" attack?) Easy practical application Consider a hash sha256(sha256(...).sha256(...)), for instance sha256(sha256($p).sha256($s)) sha256($p).sha256($s) produces exactly 1 block of message, so the second block is 0x80, padding and constant length always. So we can reverse the second block and check intermediate state computing only 1 limb instead of 2. That's up to 50% higher speed (considering that we already have other optimizations including caching for sha256($p) and sha256($s)). With all optimizations and many salts, it should have same c/s as single block raw-sha256. I only checked sha1 and sha256. But (many?) other hash functions can have this behaviour. Also other crypto schemes can give constant blocks. It is needed to investigate it more. Thanks! -- Regards, Aleksey Cherepanov View attachment "backward.c" of type "text/x-csrc" (5223 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.