Date: Tue, 07 Jan 2014 11:45:52 +0100 From: magnum <john.magnum@...hmail.com> To: john-dev@...ts.openwall.com Subject: Re: Accepting multiple format tags as valid On 2014-01-07 11:27, Frank Dittrich wrote: > On 01/07/2014 11:14 AM, magnum wrote: >> On 2014-01-07 09:43, Frank Dittrich wrote: >>> Format dynamic_33 could also accept $NT$ hashes. >>> Currently, it only recognizes the plain hex hashes without any prefix. >>> But NT hashes and dynamic_33 hashes only differ in their prefix. >>> >>> In this case, it might even be good if dynamic_33 would use $NT$ as the >>> default prefix. >>> Also, all the implementations (dynamic_33, nt, nt2) support the same >>> max. password length of 27. >>> >>> At least accepting $NT$ as valid would be an improvement. >> >> I think it should simply be one single but *configurable* tag. If >> nothing is configured, dynamic_1000 will have $dynamic_1000$ but if it's >> configured as $foo$, that and only that tag is valid, and is written to >> pot. Constraint on configured tag is that it start and ends with $ > > 1. If we drop $dynamic_33$ as valid, then hashes stored in an older pot > file will be ignored, because these will use $dynamic_33$. Once we do this we will cease producing this situation so it will be a one-time problem. We document it and people can s/this/that/ if they want to. > 2. As long as this doesn't lead to a dynamic format grabbing hashes it > can't crack, I wouldn't use any restrictions regarding a possible prefix. Agreed for sure, but it might be more problematic to implement. >> On a related note I've had thoughts about core *) functionality for tag >> aliasing. A list of tags will be accepted, but converted to a canonical >> tag at loader stage with no particular support from the format. The >> canonical (the format's) tag will be written to pot so in that end no >> logic is needed. >> >> Speaking of that I've also considered some kind of format name aliasing. >> That way when we change the name of a format, the old name can still be >> used. It will be converted during options parsing, so format will know >> nothing about it. You would love writing bash completion for that %-) >> >> Both these will have their lists in john.conf. > > Will you post your design ideas/decisions to john-dev first, or will we > find out once the change hits bleeding-jumbo? I'm not sure it will ever be implemented. Sometimes we do too much of this kind of stuff and too little fast formats that cracks hashes. Having said that, sure I can discuss it here first. There have been long periods where I (and you) didn't get a single comment on lots of ideas and when that happens I tend to communicate less and less. magnum
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.