Re: Best Way To Randomize/Salt A Text String Before SHA256?



Hi Ilmari, thanks for the feedback...

Coming back to this earlier part of your description, it occurs to me
that, as long as you trust the server enough, there could be a simple
way to avoid brute force attacks: keep the salt (or part of it) on the
server and don't reveal it to anyone.

Sadly, this won't work for my case. Something I didn't mention was
that I want parties to be able to privately exchange the secret texts
with each other, independently of the server. They would merely use
the server as a place to read the "commitments", then reveal to each
other. Revealing to the server is merely going to be a common option.


In principle, as long as your hash function is secure, all you need to
do is _somehow_ incorporate the salt into the string to be hashed.
For example, instead of hashing simply "banana", hash the string "My
password is kumquat and my favorite fruit is banana."  Even if the
attacker can predict the form of the string, they'll still have to
guess both the secret ("banana") and the salt ("kumquat").

I thought about the degree to which users might throw in their own
salt, or add some kind of gibberish, just to make attacks harder. Of
course then one has a semantics problem. e.g. above they could claim
that anyone with a clue would realize that their real favorite fruit
was kumquat from the above message. So I'd prefer something that
didn't need this.


As long as the space of possible salts is fairly small (which is
likely, if the users are expected to memorize them), there's not much
more you can do -- as long as a brute force attack is feasible, any
cryptanalytic attacks are pretty irrelevant.

I'm generating "certificates" that people keep on their system and
have to save for later in order to do the "reveal"...so the size isn't
really an issue. It looks like what I've described is a "commitment
scheme", as Kristian has pointed out:

http://en.wikipedia.org/wiki/Commitment_scheme

But due to the equations being a little weird, I haven't yet grasped
how to apply this to making my case cheat-proof...


One thing you _can_ do, however, is to make the hash slow to compute,
e.g. by iterating it: this slows down brute force attacks, but
hopefully has little impact on legitimate use.

Yes, I was reading about key strengthening... I'm not sure what the
best way to apply it is in my case, but I'll keep it in mind:

http://en.wikipedia.org/wiki/Key_strengthening


I'd recommend that you decide upon some acceptable real time latency
(like, say, 0.1 to 10 seconds) and set the iteration count to take
that amount of time on whatever hardware you have available.  Also
note that this still doesn't eliminate the need for strong passwords
entirely, since an attacker can be presumed to have more time and
hardware available than you do.

I was hoping that maybe this could be something the user decided, as
it is their secret... so if they want to let it crunch longer then
that's their issue. So perhaps the key strength can just be a
parameter to the process that varies among individuals based on their
available resources and/or paranoia.

Thanks again!
.



Relevant Pages

  • Rant: Customers who know best then decide you were right
    ... web-hosting/email/whatever the customer wants a server for. ... brute force attacks coming from one of our IPs. ... traffic did indeed exist and opened an abuse ticket with a customer. ... for the spam and update the existing ticket. ...
    (alt.sysadmin.recovery)
  • Re: Security Issue
    ... I run a home server, using Ubuntu 8.10. ... those pesky SSH brute force attacks, and Snort to keep an eye out for other ...
    (Ubuntu)
  • Re: Best Way To Randomize/Salt A Text String Before SHA256?
    ... In principle, as long as your hash function is secure, all you need to ... If the user can store a fairly long secret salt, the ... since brute force attacks become infeasible. ...
    (sci.crypt)