Re: [Ejbca-develop] debug log ejbca.sh

[Manuel D. <ma...@de...>]

*off-topic*
I cannot add any content to the original question of why this or that
command is so slow, but I'd like to comment on how the "rounds" of a
key derivation hash, see below.

On Thu, Feb 26, 2015 at 4:09 PM, Michael Ströder <mi...@st...> wrote:
> The only reasonable comment on the page above is the cause for the user's
> question:
>
> "The speed of my own system should not be leading for the number of
> iterations. It is the current speed of the brute-forcers that should dictate
> how many iterations are considered safe."
>
> Yes!!! The whole point of using a strong password hashing schemes is to
> protect against the brute force power of off-line attacks (hashcat with big
> graphic cards) and *not* the amount of time of local command invocation.

Not quite. Yes, it is the whole point of using a strong password
hashing scheme to protect against brute force attacks as much as
possible. The hashing mechanism should in itself already be safe. The
point of doing additional rounds is not to secure a single password.
The point of doing additional rounds is to push the safety margins as
far as possible before it hurts for normal operation of a single user
(logon, ...), SO THAT it does hurt (if) an attacker tries to crack a
long table/list of passwords that has been dumped somewhere or even
tries to brute force every conceivable combination of chars.

You are concerned about the security now and confidentiality in the
far future ? Then increase the number of rounds (or change the
password more often in the future, with steady higher number of
rounds) and live with the performance impact :)

of course, what I am saying here is helping neither of you, I am well
aware of that :)
cheers,
Manuel