Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <02ac01cd4fbc$582de0a0$0889a1e0$@net>
Date: Thu, 21 Jun 2012 09:44:21 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: formats interface enhancements

>From: Solar Designer [mailto:solar@...nwall.com]
>
>Here's what I have planned (maybe for 1.8):
>
>Already in jumbo, need to have in core:
>
>FMT_NOT_EXACT
>prepare()
>self pointers passed to init(), valid(), prepare()
>
>Already in bleeding, need to have in core:
>
>source()

Actually it is get_source() in the current bleeding.   NOTE renaming would
be trivial, if we have to, but my intent behind the name was:

binary(), salt()  are convert from the outside format, into an internal
format

set_salt() set_key() are setters.
get_key() is a getter of the original set_key().

binary_hash() / get_hash() are also the setter/getter 'like' functions, but
named differently.

My feeling was that the source() was a getter, so I named it get_source().
It is meant to get the original source, the same way that get_key() gets the
key , whether it was allocated and stored in the source pointer or whether
it was regenerated by a function.  Being a getter, I named it get_source().

>Not implemented yet:
>
>done() (destructor)
>reset()
>set_mask()
>"struct salt *" passed to crypt_all(), so that it can do comparisons

I do not understand the need for this, unless it is to work on multiple
salts in parallel.  If so, then do we need set_salt() ?

>async crypt_all() (two blocks?) ability to exclude individual test

Would this better be done in set_key() ?

>vectors from benchmarks
>binary_hash*() combined into one new binary_hash() method accepting size

Makes a lot of sense, but the current methods, you 'do' see the matching
set.  The binary_hashx() and get_hashx() 'match'.  This new proposed way
certainly works fine, and once properly implemented does the trick.  This
does make it easier to later make finer granularity, or to expand the size.
Only one function to add, vs a matching pair.

>get_hash*() changed to larger sizes (6, 10, 14, 18, 22, 26, 29)


Jim.


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.