[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150418144212.GA7237@openwall.com>
Date: Sat, 18 Apr 2015 17:42:12 +0300
From: Aleksey Cherepanov <aleksey.4erepanov@...il.com>
To: Shinnok <admin@...nnok.com>
Cc: john-dev@...ts.openwall.com
Subject: Re: [RFC] Johnny further development proposal
On Sat, Apr 18, 2015 at 05:27:25PM +0300, Aleksey Cherepanov wrote:
> On Sat, Apr 18, 2015 at 05:06:03PM +0300, Shinnok wrote:
> >
> > > On Apr 18, 2015, at 4:36 PM, Aleksey Cherepanov <aleksey.4erepanov@...il.com> wrote:
> > >
> > > Hi Shinnok,
> > >
> > > On Sun, Apr 05, 2015 at 01:19:19PM +0300, Aleksey Cherepanov wrote:
> > >> On Thu, Mar 26, 2015 at 05:09:21PM +0200, Shinnok wrote:
> > >>> http://openwall.info/wiki/john/johnny-roadmap
> > >>
> > >> I have some comments:
> > >
> > > More comments:
> > >
> > > Do you plan automated tests?
> >
> > I'm inclined to say that automated tests is too far fetched for Johnny. Not even JtR has that(?), which would be the real beneficiary of such a test suite.
>
> JtR does that. It has 1) self-tests, 2) test suit. Though tests are
> limited: they check correctness of formats for good hashes, they cover
> neither ui, nor wrong hashes. Though it may (or may not) be improved
> by Kai Zhao during this summer.
>
> > >
> > > It may be helpful to mark all points of the roadmap with complexity
> > > estimation including marks about obviousness of solution. Well, maybe
> > > it would be better to write possibilities right there with estimation
> > > of maturity.
> >
> > We think we are already working enough on process, maybe start focusing more on getting to write the actual code?
>
> Please struggle with your temptation to not think through the tasks
> before coding.
>
> On wiki, I see
>
> Version 1.7
> 3. Figure out how to implement *2john conversion support and
> implement it
>
> Version 1.8
> 1. Jumbo support (this task needs an evaluation and a further
> breakdown)
>
> In other proposals, I saw that students figure out things before the
> coding period. Of course it is not fully possible to figure out
> everything beforehand. And of course you may prepare a draft
> implementation to "think" (though just non-formal description may be
> enough). Nevertheless I think it would be useful to separate thinking
> and coding periods to not come up with only drafts in the end. These
> periods have very different expectation of resulting quality.
I think more attention and time should be invested into planning of
jumbo and *2john tasks because they're most important there. So in
tough words: the core of your roadmap is not thought well.
And I'd put these tasks earlier.
BTW
Version 1.5
1. Add the –fork option to the UI so that we can use multi core
-fork is not the only option for multi threading (openmp, mpi).
Thanks!
--
Regards,
Aleksey Cherepanov
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.
