Re: Call for review: Hashing by hand algorithm
- From: Maaartin <grajcar1@xxxxxxxxx>
- Date: Mon, 26 Apr 2010 13:39:22 -0700 (PDT)
On Apr 26, 7:41 pm, bmearns <mearn...@xxxxxxxxx> wrote:
I think I'd better start calling this something other than a
cryptographic hash function. Maybe just a "scrambling function" would
get me in less trouble =).
AFAIK, all cryptographic hashes use some final mixing, which can be
quite time-consuming (e.g, CubeHash makes an equivalent of hashing 10
additional blocks). I see why you don't want to do it.
You're absolutely right about the vulnerabilities you pointed out. If
a smaller deck is used, then this sort of vulnerability would fade
much more quickly, right? Your point that a hash should be secure
regardless of how long the input is correct, of course, but for my
specific purposes, I don't mind if it requires some minimum
(reasonable) number of inputs before it becomes secure (which is why I
should stop calling it a cryptographic hash).
You could require that after any input shorter than 10 there must be
1000 additional rounds (so you could keep claiming it to be
cryptographic and prevent everybody from using such short inputs. :D)
Additionally, pre-image resistance (collision resistance in general)
is not my /primary/ concern, though it certainly is a concern. In the
context I'm looking at (narrow as it may be), it's not useful for an
attacker to just find some m2 such that hash(m2) = hash(m1). If they
know hash(m1) then they can already break into that specific account.
In order to learn the "core" password, they would need to find the
exact value m1. Or I suppose they could find some value m3 such that
hash(seed1+m3) = hash(seed1+password) and hash(seed2+m3) =
hash(seed2+password), but I'm going to go out on a limb and guess that
if they can do that, they can just find the password directly.
I think so. The password must come last, otherwise the attacker could
get all relevant information by simply looking at hash(password+"").
Sure, this is a CPA and quite irrelevant to what you do. I'd even
suggest to start with a secret stack arrangement. The reason is that
rearranging the stack at the beginning is quite easy and less error-
prone as compared to normal steps.
What I liked on your former scheme (and miss now) was the use of card
color - this is quite easy and could lead to good mixing. Would you
like something like this?
How is the performance of the current algorithm, I mean, how long does
it take and what is the error rate?
- Prev by Date: Re: bad client public DH value
- Next by Date: Re: Steganography Software
- Previous by thread: Re: Call for review: Hashing by hand algorithm
- Next by thread: Re: Call for review: Hashing by hand algorithm