# Tag Info

8

The answer to your edited question is "yes, it is possible". As a trivial example, let $H$ be an ideal $k$-bit hash function. Due to the existence of the generic birthday attack, $H$ provides only about $k/2$ bits of collision resistance — that is, an attack can, on average, find a collision after about $2^{k/2}$ hash function evaluations. Denote ...

6

Well, how resistant to attack would depend on what security properties you would need from it. There are three standard assumptions we can make about a hash function: Given a hash value, it is difficult to find an image that hashes to that value; this is known as preimage resistance Given a image that hashes to a specific value, it is difficult to find ...

3

To add some more perspective to this: this question has been studied quite extensively in the context of hash function combiners. A combiner is simply a function that gets (black-box) access to two hash functions and implements a new hash function. The question there is: does a combiner with "short output" exist that is robust for collision resistant hash ...

3

As a simplified case, consider a sponge hash function made from an ideal 160-bit block cipher with a 256-bit key, and mixes in a 32-bit word each round. It would be better to use an LFSR to generate the sequence of keys for each round, but let's say this simplified hash function is \begin{align} H(0) &= 0 \\ H(N) &= E(0, H(N-1) \oplus ... 3 The short answer is NO: you will not obtain identical ciphertexts from the same file encrypted using two different runs of a decent public key file-encryption software; their hash will not coincide. The longer answer (in theory): If you use a deterministic public key encryption scheme like textbook RSA, i.e., without randomized padding, then yes. If you ... 2 I would advise against this. When implementing slow-hashing (such as bcrypt or scrypt), it's usually recommended to select as high a work-factor as is tolerable (in relation to how much time the user is willing to wait, and/or how much strain you're willing to put on your server). Assuming you're working within this constraint, using two distinct slow ... 2 There is no why it is identical. The input form of the data does not influence what the output of a secure hash function should look like. The output of a hash should be unrelated to the output except for the mapping performed in the hash function itself. There should be no method of calculating the output other than to execute the hash function. The best ... 2 The answer is "any sane summarization function is about as good as any other; pick whichever is convenient" To the best of our knowledge, SHA-256 acts pretty much like a random function (except for the length extension attack; that wouldn't apply here) So, the output of SHA-256 is essentially a random 256 bit number; so, if we have a 128 bit hash function: ... 2 My preference would be to use hash for this purpose. Cons of using symmetric cipher include: Symmetric cipher keys are shorter than hashes (128-256 bits), where as hashes are longer (160-512 bits). When considering the length of symmetric cipher output, it is commonly short (like 128 bits). This length is often inadequate to protect against birthday attack ... 1 First of all, "Is collision less likely for individual characters than for strings?" The answer to this is yes. In fact, experimentally verifying shows that for 8-bit ASCII characters the collision chance with FNV1a is 0. This is however not an impressive feat, seeing that the output is 4 times as large as the input. However, using this you no longer have ... 1 When using a salted, key-stretching KDF, like PBKDF2 or scrypt, you are in effect stretching both the salt and the password. That is to say, what you're calculating is\rm key = KDF(password, salt)$$where changing either of \rm password or \rm salt requires the slow \rm KDF function to be entirely recomputed. In fact, if changing the salt did ... 1 Obviously not. For example, the function h2(x) = 0 is not collision resistant, h2(h1(x)) shares that property. This remains true even in less trivial cases; if h2 is not collision resistant because its output is too short (it has an n-bit output, with 2^{n/2} being small enough to do a search over), then h2(h1(x)) will also be too short 1 Will they always be collision resistant? No For example, let h_2(x)=0. Then, h(x)=h_2(h_1(x))=0, which certainly isn't collision resistant. Can it be collision resistant? Yes For example, suppose we define h_1(x)=\mathrm{SHA256}(x) and$$ h_2(x)=\begin{cases} 0 & |x|=1 \\ \mathrm{SHA256}(x) & \mathrm{else} \end{cases}  Then, since ...

1

No, exposing such a hash does not compromise the RSA private key, unless the hash function is sufficiently and severely broken. Of course, you don't need to hash the private exponent to identify the key. You can simply use the modulus or a hash over the (public) modulus to identify the key. This has the additional advantage that that ID will also match the ...

1

Evaluating, we have that Sha_1(38607310235)=6502c8f9f5c222b9598d4e074fd3431f506948bc So, I'm guessing the question you're actually asking is: Given an 11 digit number $x$, find $y$ such that $L[H(y)]=x$, where $L(\cdot)$ takes the last 11 hexadecimal characters, and $H(\cdot)$ is the SHA-1 hash function This problem is believed to be hard to do, so ...

1

The verifier and logger start with a seed for a forward-secure pseudo-random number generator. To denote a valid ending of a log, append the string of the next $b$ bits of the PRNG's output to the end of the log. $\;\;$ To add a log entry, get the next $\:b\hspace{-0.03 in}+\hspace{-0.03 in}k\:$ bits of the PRNG's output, use the last $k$ of those bits to ...

1

I don't know if that counts, but authors of recently selected SHA3 function Keccak (http://keccak.noekeon.org/) mention its ability to perform Full Domain Hashing: Variable output length hashing is an interesting feature for natively supporting a wide range of applications including full domain hashing [...]

Only top voted, non community-wiki answers of a minimum length are eligible