[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130730144002.GA17344@openwall.com>
Date: Tue, 30 Jul 2013 18:40:02 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Parallella: bcrypt
Katja,
On Tue, Jul 30, 2013 at 06:33:11PM +0400, Solar Designer wrote:
> So it may be more optimal to have exactly two structs: one for the salt
> and one for the candidate passwords - and transfer only those of them
> that have changed since the previous transfer. You set the
> keys_changed flag in set_key() and the salt_changed flag in set_salt(),
> and you reset both in crypt_all().
Savings may also be possible on Epiphany side by only reading keys
or/and salt from external memory if the corresponding component has
changed from the previous call. To achieve this, maybe you need to use
a struct like this:
struct {
char keys_changed;
char salt_changed;
... salt;
... keys;
}
and always transfer the portion of it containing the *_changed flags,
plus as much more data as you need to cover the actually changed
components. When running on many salts, you'd usually transfer the
portion ending with "salt" (but excluding "keys"). When running on one
salt, you'd need to transfer the *_changed flags and "keys", but not
"salt", so you may either transfer the whole thing or you may do two
transfers (to skip "salt" if this is beneficial - probably not worth the
bother since the salt is smaller than the 72-char key buffers, if you
transfer them in their entirety).
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.
