# Tag Info

1

but if there are N buckets and N is not super large, simply generating random data will still produce a hit approximately once every N tries. Changing the hash function won't change this fact. There should be other mitigations to a user adding a bunch of random data, such as rate limiting or changing your data structure. How do you plan on obtaining the ...

1

Sure. The probability of collisions depends on: How your symbols in the messages are distributed: Do messages have particular structure? Do some elements occur more often than the others? How long the hash code is. The structure of the hash code algorithm itself: Does it produce some hash codes more often than the others? If all symbols are equally ...

0

How to prove a chop(H) is collision resistant with n-bit? Is this statement true? Is it true that all collision resistant hash functions remain collision resistant after chopping? As a hint, you might want to consider this question.

3

My thought: assume there a black box, that given a cryptographic hash function $h$, finds some $x$ and $r$ in polynomial time, such that applying $h()$, $r$ times gives $x$: $$h(h(h\ldots(h(x))) = x$$ I thought about this, and I found that the answer is yes. The oracle can be used to find preimages and collisions in an arbitrary function h : \{0,1\}^n ...

1

The base conversion proposed by Maarten Bodewes's answer is fine to convert some of the hash into words. But it leaves aside a stated goal: collision resistance as high as possible considering the reduced keyspace of the passphrase There is a well-established way to increase collision resistance and premimage resistance: re-hash the hash fingerprint with ...

1

Name and exact definition of security properties of hashes vary, depending on level of formalism. Refer to your reference material. However the general idea always is: preimage resistant (or first preimage resistant): given $h$, it's infeasible to come up with $m$ having hash $h$. second preimage resistant (or weakly collision free): given $m$, it's ...

2

If you insist on random nonces, 128 bit random nonces are safer than 96 bit random nonces (but not as good as 96 bit counter-based nonces - I presume that is infeasible in your scenario). The 128 bit random nonce is transformed (via GHash) into what is effectively a 96 bit nonce and a 32 bit counter; in the 96 bit case, the 96 bit nonce is used directly, ...

Top 50 recent answers are included