# Tag Info

9

In the Damgard-Merkle construction for hash function the compression function takes as input a message block and a chaining value. For the first block a particular value, called a initialisation vector (IV) is given. A freestart collision is a collision where the attacker can choose the IV. Even if a freestart collision does not immediately give a standard ...

7

Grover's algorithm treats the function it is evaluating as a black box and finds, with high probability, an input to the black box such that it outputs a specified value in $O(N^{1/2})$ evaluations of the function. Since Grover's algorithm works on the function as a black box, your modification does not hinder Grover's algorithm at all in finding the ...

5

You don't need to change the key at all in terms of it being "overused". The only reason to change a key is when you use it beyond the bounds given in proofs of security. You have to look this up, but if you are using HMAC-SHA256 with a 256-bit key then you can go on for about $2^{128}$ computations, which you will never every do. Having said that, the ...

4

There is a simpler way: implement a stream cipher using the hash function, and use that to encrypt the plaintext. Probably the most used stream mode is counter (CTR) mode, which is normally defined for block ciphers. CTR mode works equally well with a PRF (MAC) as with a PRP (block cipher). It only uses the function as a one-way function; with a block ...

4

Provably secure cryptographic hash functions are often built using the same sort of operations as what are used in asymmetric crypto. The major problem with these constructions are that they are very inefficient. Also, a lot of these sorts of constructions have finite input domains. Thus, you have to figure out how to extend it to arbitrary length inputs. ...

3

The rotation countsr (together with the order of access of the 4 words of the state) are engineered for fast diffusion, as documented in RFC1321: The shift amounts in each round have been approximately optimized, to yield a faster "avalanche effect". The shifts in different rounds are distinct. The general idea is to move bits to a 32-bit position on ...

3

Generically, this certainly does not work. For example, with RSA, if you take the domain to be ${\mathbb Z}_N^*$ then it's a permutation so is clearly collision resistant but also completely useless. Then, if you take a larger domain, it's trivial to find a collision. For example, take any $x\in{\mathbb Z}_N^*$ and then take $x'=x + N$. It is clear that an ...

3

For a good hash function, like Skein, diversity of inputs has no impact on diversity of outputs. So, if you have no information about the space of possible pre-images (e.g., it is not a human generated password, it is a completely random input from your prospective), then the expected number of attempts before retrieving the pre-image is the same in either ...

3

My intuition suggests that there would be no security impact if this output were truncated to 128 bits. Is this correct? My reasoning here is that salting prevents multi-target attacks, and that collisions are unimportant in the context of password verification. Correct, there is no practical security impact. The preimage security of the hash function ...

3

I'm trying to get my head around how the crypto solves this problem. It doesn't. You need to trust the platform you use to do the signing. For instance, my bank has replaced the "signature" generation device that I previously used with one that displays the actual transaction, so I don't have to trust the information on the computer screen that much.

3

A perfect hash function computes unique indexes for a predefined finite set of possible inputs. Typically such a function is used to implement a hash table. It is then not necessary to worry about collisions. Normally the set of possible inputs is small and known, such that it is also possible to invert the function (i.e., given the index one can find the ...

3

Any transformation of the identifier, including those in the question, is bound to have at least one drawback: after a transformation of cryptographic quality, it will be next to impossible to re-agregate identifiers that refer to the same person but have been slightly garbled (perhaps because there are two common spelling of the mother's name). Even ...

3

A random 128 bit value has a tiny ($2^{-85}$) probability of being a perfect cube, and so that doesn't look like a viable approach. And, you can't control the output of MD5, and so it'll give you effectively random values. A better way may be to collect a large number of signatures (with their messages); that is, $S_i = M_i^3 \bmod N$ values (where $M_i$ ...

2

In this case there is no need for a rainbow table, since at most the identifier has about 15 bits of information. You can cycle through all possible values (there are $26^2 \cdot 31 \cdot 2 = 41912$) and even if they were hashed with a salt you will find the preimage in a fraction of a second. So the only way to protect the information is with a secret key, ...

2

A hash's security in the Random Oracle Model implies its collision-resistance, first-preimage resistance, and second-preimage resistance. In addition, security in the ROM implies that the hash's output is indistinguishable from random for an adversary without knowledge of the input, and that the hash is resistant to length-extension attack, neither of which ...

2

Using a perfect hash in this case is essentially the same as using an index. For a perfect hash to work, both the compressor and decompressor have to know the $N$ possible things that might be "compressed" in the data. You are better off giving them each a number in $[0,N)$, and using $log_2N$ bits as your "compressed data". This is better than a perfect ...

2

I see 2 options that fit the requirement (small, verifiable within some limit). Because the sizes are small, the probability of the collision of a random value showing linked is high, larger values will obviously help. Option 1 is to have a random value, and encrypt or hash it, then truncate the result and concatenate to the original value. The size of the ...

2

Mathematically speaking, there is no such thing as a collision-free hash. Practically speaking, there is. Cryptographic hash functions in good standing have no known collisions. That's one of their defining properties. They do have collisions, but there isn't enough computing power on Earth (if not in the whole universe) to find one, given current ...

2

The reason Lamport's scheme is secure against a passive attacker is that even if they see $H^{n-1}(p)$ for a given $n$, the server would require the preimage of that hash, $H^{n-2}(p)$ on the next login. The active attack, in comparison, allows Trudy to find an earlier iteration than the server is expecting. That allows calculating several login hashes by ...

2

Well, first of all you forgot one requirement: hashing should be a deterministic procedure (everyone should compute the same hash for the same input) and that one you do not meet with a secure public key encryption scheme. Now you could fix the used randomness to a fixed value. Then I assume you get an inefficient hash function that in theory fulfils all ...

2

How does a perfect hash function have collision-resistant in this case? Well, when we select a perfect hash function, we take as inputs a set of messages $M_1, M_2, M_3, ..., M_n$, and use them to select a hash function for which $H(M_i) \ne H(M_j)$ (if $i \ne j$) Now, according to the pigeon hole principle, the output of $H$ must be at least $\log_2 ... 2 That's correct. Here are the padding instructions from RFC1321, the MD5 spec: 3.1 Step 1. Append Padding Bits The message is "padded" (extended) so that its length (in bits) is congruent to 448, modulo 512. That is, the message is extended so that it is just 64 bits shy of being a multiple of 512 bits long. Padding is always performed, even if ... 2 There's actually an algorithm designed exactly for this purpose: generating a sequence of keys from one master key. It's called HKDF (HMAC-based Key Derivation Function, paper here). The algorithm essentially boils down to two steps: Extract and Expand. The Extract step accepts any type of "key material" as input, and outputs a pseudorandom key that will ... 1 Theoretically, since the domain of SHA-256 contains$2^{2^{64}-1}$different messages and the value set only contains$2^{256}$different message digests, there must exist at least one possible output that has more than one possible pre-image. Another important point is that SHA-256 is a deterministic function. This means that if you hash the same message ... 1 Your idea violates rule 1. With asymmetric key encryption, it is not difficult to find a message given the encrypted message, if you have the private key. Also, if you randomly generate a number and call it the public key for a hash function, this is diverging significantly from public private keypair generation, which generally relies on finding two ... 1 Elements of finite fields don't really have a sign. But depending on context you can define a property that's different for$x$and$-x$(when$x$is not$0\$) and call that property sign. Some possible choices: A number is called a square (or Quadratic residue) if there is another number which produces it when squared. Since positive real numbers are ...

1

No. And it's probably a good thing that that's not the case. All cryptographic hashes (inc. SHA-1) are designed to have no obvious correlation between their input and output. If there is too much of a correlation, then they are considered broken. If each string of 160 bits produced a different output, that would be a correlation. That would also mean that ...

1

First, there is no way that crypto can keep an attacker from manipulating the data that is shown to the user. to prevent this, you have to trust some part of your hardware, at least the screen that views the data and some chip inside that can do some crypto. Moreover, digital signatures alone will not solve this problem as the merely capture signing a ...

1

Create a public/private key pair. Generate a random value and sign it with the private key. Call that the random token.

1

It is not the only requirement the behavior of the hash functions, which is assumed as a random function, in order to model a proof in the RO model. Also imprortantly it is the assumption that under the RO in order someone to learn the output of the random oracle which is a hash function, has to make queries in the oracle. Otherwise with no random oracle ...

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