Tag Info

New answers tagged

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 ...


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 ...


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 ...


0

Yes you can. This is because hash can be made using block ciphers and we know that block ciphers can be made from stream ciphers. Thus, by the transitive property we can observe that hash can be made from stream ciphers. I hope this helps!


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 ...


0

It depends on the time you want to spend. But most likely, there is nothing with reasonable efficiency. For arithmetic operations, humans are really bad compared to computers, and the difference is at least a factor of $10.000.000$ (very very rough guess, probably even 1+ additional zeros there). So, since you have to assume that the attacker has access to ...


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$.


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 ...


0

Your design is that the server has a key (which you call the salt, but would have to be secret here) and generates the client's public and secret values using e.g.: $$p = ID\\ s = H(k|p),$$ where $H$ is some hash function. This seems secure: if an attacker only has access to $p$ they have no chance of generating $s$ without knowing $k$. However, if $H$ is ...


0

Let's start with an article in a wiki about group theory. That one states, that it is automatically cyclic and it is isomorphic to $(\mathbb{Z}_p,+)$. Formally speaking, it is abelian, cyclic, nilpotent, and of course finite. That means actually you know a lot about the group structure ahead of time. Because it is already fully determined with a variable ...


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 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 ...


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): ...


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 ...


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

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 ...


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

If the passwords are uniformly randomly generated among all possible byte sequences of the chosen length, then there is no point in having a password that's longer than min(hash length, brute force resistance) where brute force resistance is the number of brute force attempts that you want to resist. Picking a 32-byte password gives you a huge safety margin ...


3

The entropy of passwords is not universally distributed. So hashing can be used to concentrate the input of a hash. The concentration of entropy from another source is called extraction by HKDF, which is a key based key derivation function (which should not be used for passwords). This is from the introduction of RFC 5869, which defined HKDF: Thus, the ...


-2

I did not quite understand the question. Specially the part that says under the context. The answer is no. because, The output of a hash is a fixed value, for any given input of any length (If the length of the input is shorter than the block size, depending on the HASH algorithm being used, an appropriate padding scheme is present). So whether the ...


2

No, since passwords are usually far from uniformly distributed.


7

I believe Thomas Pornin's answer is by far superior to mine, but perhaps this answer can provide a simplification to his answer. When you initially hash some data, the possible input is infinite/limitless. You could input "abcdefghi...", "123456...", etcetera. However, the resulting hash possibilities are finite/limited. One of the beautiful things about ...


29

If you repeatedly apply a generic function on its result, in a finite domain, you tend to obtain a "rho" structure: at some point, you enter a cycle whose length is (roughly) $\sqrt{N}$, where $N$ is the size of the output space for your function. In the case of MD5, $N = 2^{128}$ (MD5 outputs 128-bit values), so the cycle will have length about $2^{64}$ ...


1

Using AES as a Davies Meyer compression function is a bad idea: It has a block size of 128 bits, which limits its collision resistance to 64 bits, which is rather weak. This limitation could be overcome by using Rijndael with a 256 bit block size, but then you'd need to use a higher number of rounds. AES has been designed to work with randomly chosen ...


0

I looked more into it and saw that the state input is the data input of the block cipher and the data (that is being hashed) is the key input to the underlying block cipher (SHACAL). Thanks anyway.


3

Yes, the output should have an entropy of 512 bit (or slightly less). Using it as a key is a good idea. If you want to generate more than 512 bits of key material out of the 512 bit you need to use a Key Derivation Function (KDF). You do not need to stretch the key, because it is no password and has a high amount of entropy - enough to make any brute force ...



Top 50 recent answers are included