Date: Fri, 28 Aug 2020 15:23:38 +0200 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: rain mode Hi Owein, Thank you for offering to contribute this mode to our project! On Fri, Aug 28, 2020 at 02:01:08AM -1000, Owein Douard wrote: > Hello, from this thread on github > <https://github.com/openwall/john/issues/4323> I was invited to join the > mailing list, which I have done. > I just understand that everything goes through email and appears here. > Let me know about which address is correct to be able to communicate. The address you sent the above to is correct. We originally created the john-dev list for our participation in Google Summer of Code, which we did a few times. The list became mostly inactive since then, but it's OK to use it again for this discussion. As you asked, I took a look at your https://github.com/e2002e/zhou repo and at your fork of john. My first question, which I couldn't find an answer to, is what the rationale for the proposed rain mode is. Can you perhaps answer this in here? When is this mode to be used, why, and what advantage it'd provide over other modes. Any examples you might have of this mode cracking real-world passwords (e.g., use RockYou) or at least real contest passwords (e.g., from KoreLogic's CMIYC contests) that other modes didn't when run for the same amount of time. I think we need to test rain vs. the current incremental mode with dummy .chr file generated from fake john.pot containing just ":charsethere" all on one line, and see which cracks more passwords e.g. of RockYou, optionally after having ran some other modes (e.g., wordlist with rules). Can you do that? If there's another use case you propose your mode for, then can you make a similar comparison for that use case? Trying to see what's good about rain mode, I arrive at these 3 points: 1. Length switching back and forth like in incremental mode, but with charset specified via the command-line like in mask mode. Maybe we need to reintroduce a revision of incremental mode similar to what we had back in JtR 1.0, where a charset can similarly be specified directly. 2. Trying to win a maybe unfair (non-random) lottery by trying randomish combinations instead of sorting by assumed probability (maybe unknown) or trying combinations in a more obvious sequence (which might not have a chance of hitting the particular unfair lottery's non-random pattern). While this might feel intuitive, I think it doesn't improve the chances. I wrote some related thoughts here: https://www.openwall.com/lists/john-users/2020/04/12/1 and earlier in that thread. 3. Like 2, but assuming you or others are also trying or have previously tried the more obvious sequences. Now this makes some sense, but then if rain mode becomes widely available the same issue of further need to randomize your attempts vs. others' will arise. If that's the use case, maybe we can come up with something that fits it even better? Regardless, you also brought up questions on adding a cracking mode to JtR in general - specifically, on getting "--restore" and fork/node/MPI support to work right. Ideally, we'd gain documentation that would be reusable by you and others wanting to add a cracking mode in the future. We may discuss that even if your specific rain mode isn't to be added. Another observation I have is that rain mode looks simple enough to have it as an external mode, at least initially. Obviously, that would be a worse fit for cracking fast hashes (like raw MD5 and SHA-1 in zhou), but it'd make the algorithm's logic apparent before we clutter it with multi-node implementation detail, etc. Thanks, Alexander
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.