Timeline for John the ripper - creating specific rules
Current License: CC BY-SA 3.0
5 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Jan 12, 2018 at 23:24 | comment | added | Royce Williams | Then I don't think that the 100s limit should impact you very much, as long as each node has a large enough chunk of work to come up to speed. You might consider posting the question to the john-users list as a cross-check. | |
Jan 12, 2018 at 21:14 | comment | added | Ryan | The keyspace is actually in hundreds of trillions, (its larger than 7 alphanum) the hash rate is fast enough, but it will still take many weeks with 1000s of cores...hence needing to break it into jobs | |
Jan 12, 2018 at 17:08 | comment | added | Royce Williams | Ah, good to know. Might want to update the original question with that information. The "too little work" objection is related to fast hashes, and it sounds like you're dealing with a slow hash, so I suspect this would actually still work. Since it's easy to implement, you might give it a try and report back how it performs. | |
Jan 12, 2018 at 6:32 | comment | added | Ryan | This is a large job that needs to scale across 1000s of cores/many machines. That method states its not good for > 100. | |
Jan 12, 2018 at 4:55 | history | answered | Royce Williams | CC BY-SA 3.0 |