# Tag Info

4

The padding scheme isn't collision resistant. For any message $m$ where $|m| \not\equiv 0 \pmod n$, there will always be a collision between $m$ and $m || 0$.

4

Word size is not a term originating in cryptography. Rather it is a term which came from the area of computer architecture. Here it specifies either how many bits are transferred over a bus at a time or the size of a register. When used in the description of cryptographic primitives (such as a compression function or a block cipher), it covers the size of ...

3

No, there is no known way. It would actually be rather surprising if there were even a theoretical way; the SHA-256 and the SHA-512 compression functions are rather different (for one, one works with 32 bit words and the other works with 64 bit words); one wouldn't expect them to share any sort of relation.

3

First to explain you, why you get 512-bit outputs from a 256-bit curve: The output is basically a point (x-coordinate is enough) and a message-dependant value, with the x-coordinate being expressed as integer. You can verify the signature by checking for a specific relationship between the point and the message-dependant value and the public key point. In ...

3

SipHash is a MAC (aka Pseudo Random Function Family) with 64-bit output and 128-bit key, rather than a hash (aka random public member of a Pseudo Random Function Family). It is explicitly designed to be used with a secret random key. Quoting Jean-Philippe Aumasson and Daniel J. Bernstein's SipHash: a fast short-input PRF (in proceedings of Indocrypt 2012): ...

3

The word size in hash functions means the size of the integral unit of operation for the internal transformations. For example: for SHA-512, you'll get some input, split it and then perform operations on 64-bit words (=unsigned integers, like modulo addition or shift) whereas for SHA-256 you'll use 32-bit operations (= operations on 32-bit-integers, like ...

3

The construction you are proposing is called the "envelope" or "sandwich" MAC, it predates HMAC, and it is in fact secure—provided the key and message are appropriately padded. That is, $$\text{SHA256}(k \parallel m \parallel 1 \parallel 0^{b - 1 - (|m| \bmod b)} \parallel k)$$ is secure, as long as $k$ is the underlying hash function's block length $b$ ...

3

We learn the first 32 bits of the SHA1 hash of the secret (well, it's actually the SHA1 hash of the secret concatenated with some known stuff, but that amounts to the same thing). We can enumerate all $2^{56}$ possibilities for the secret. We expect that about $1/2^{32}$ of them will produce a matching 32-bit value, so about $2^{24}$ candidates for the ...

2

If you got $n$ blocks, then you compute the encryption of each block, and let's look at one bit at position $j$. Let's call this $c_{i,j}= E(m_i)[j]$. Now what you will get at position $i$ in your output is $(((c_{i,1} \bar{\vee} c_{i,2}) \bar{\vee}c_{i,3}) \bar{\vee} \dots )\bar{\vee}c_{i,n}$. If we assume that all $c_{i,j}$ are evenly distributed in ...

2

If you have an $m-$bit output decent hash function (such as SHA1) and you're hashing $k-$bit values, and your list $L$ of candidates is not tiny ($2^{56}$ which is the size of possible candidates, isn't) the function will behave like a random mapping on any substring of its' output. If your prefix consists of 8 4-bit characters, then you'll be filtering ...

2

Well, if you construct what you described you basically create a function $f: \{0,1\}^{2m} \rightarrow \{0,1\}^m$. As you correctly pointed out these two strings give the same when xor'ed. So the messages $10101111$ and $00000101$ will result in the same xor and hence will get mapped to the same hash, resulting in a second preimage as you found two $x,x'$ ...

1

I'll take the (previous version of the) question as: how to implement a secure hash function $H3$ with 3 arguments, from one hash function $H$ with 1 argument, all with argument(s) in $\{0,1\}^*$. Note: For a concrete $H$ with the destination set $\mathbb Z_p^*$ thought in the question, we could use SHA3-512 followed by a suitable function; for example, ...

1

A cryptographic hash function will produce an output with pseudorandom properties, therefore when expressed in hexadecimal, a list of hash values will have an almost equal number of each character. Pseudorandom data will not compress, as compression looks for patterns. If you had duplicates, compression could reduce the data size. If you want to compress ...

1

I don't think this problem is solvable as specified. With a small message space, and deterministic hashing (or encryption), a generic attack involves exhaustively searching all likely messages to find one that corresponds to the known hash / ciphertext. If all of the digits of the ID numbers were random, an exhaustive search would require about $10^{10} ... 1 I'm not aware of any case where somebody actually searched for such a collision. However it would certainly be possible as the same workload ($2^{64}$) was already accomplished a few years ago (2002) by this project, having brute-forced RC5-64. Now assume you'd use the full power of the bitcoin blockchain (300 Peta-Hashes / s = 600 Peta-Hashes /s for ... 1 To build on tylo's answer, here's a practical internal collision attack on this construction, assuming that the block cipher$\rm Enc$has a 128-bit block size (like AES, for example) or less: Pick an arbitrary initial block$m_0$, and calculate$c_0 = {\rm Enc}_{m_0}(m_0)$. If$c_0$has less than$n/2 = 64$bits set, pick a new$m_0$and repeat. (On ... 1 You could do something fairly simple, such as$UserSecret = Random()UserID = HMAC(ServerSecret, UserSecret)$Send the user the two values. When he reconnects, he sends the two values back. If re-calculating$UserID$with the user's$UserSecret$gives the same$UserID\$ then that proves (to a high degree of certainty) that it's the same person that was ...

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