# Tag Info

0

Depends on what you mean by Keccak. There is actually a slight issue here that not all 256-bit Keccak variants have 256-bit preimage resistance. SHA3-256 (in the current SHA-3 draft) does have 256-bit preimage, but if you are using Keccak with 256-bit capacity it only has 128-bit preimage resistance. At least some of the earlier documents had 256-bit output ...

1

Yes, this is secure, it is largely compatible with KDF1 and KDF2 which basically use a 4 byte big endian encoding of the counter instead of a direct ASCII conversion to a byte. However, if you want to use the latest and greatest, you could use HKDF, possibly even augmented with a salt for session keys.

1

As the other answers point out, output bits of a good hash function are uniformly distributed, so your substring has equal chance to appear in any part of the hash digest. However, in the case of Bitcoin, the address is not a random string. Not only it starts with a predefined number (1 or 3), but the string is the result of the Base58-conversion, which may ...

3

I think you have some misunderstanding here. Finding collisions when knowing the trapdoor is a required feature, but leaking the trapoor when knowing collisions is an undesirable "feature" (which some constructions suffer from). A chameleon hash function (aka trapdoor commitment) allows you given the trapdoor to find pairs $(m,r)$ and $(m',r')$ with $m\neq ... 1 With an ideal hash function each bit of the output is 1 independently with 50% probability. So to find a hash with$n$bits chosen you have a$2^{-n}$chance per guess. That's regardless of which bits you chose, so whether they are in the beginning or the end doesn't matter. If you accept either, you can have about twice the chance, though, and more if you ... 4 No, if you use a good secure hash algorithm such as one of the SHA-2 candidates (e.g. SHA-512/256) then you don't need to use multiple hash algorithms. The hash generated is already unique in the sense that you won't be able to find another file with the same hash (this is called a collision). MD5, as mentioned, is not secure - you can deliberately create ... 3 MD5 is vulnerable to a lot of collision attacks, so if you don't trust the users it is possible for them to make files which hash to the same value as other files but which are not in fact the same. I think you are misunderstanding how a hash works though. It does not read bits and pieces of the file, it processes the whole thing into a small output which ... 4 Where did SHAKE128 and SHAKE256 originate from? They follow from the general properties of the sponge construction. A sponge function can generate an arbitrary length of output. The submission of Keccak to the SHA-3 competition proposed a single "XOF" (extendable-output function) with a user defined length, which would have been essentially SHAKE-288. ... -2 Use something more collision resistant like SHA... I can't find any hashes that are completely collision proof, but sha at least decreases the collisions... 2 As far as I understand, the scheme is: $$MD5(x) = a_1||a_2||a_3||a_4 \, \, \Longrightarrow \, \, H(x) = a_1 \oplus a_2 \oplus a_3 \oplus a_4,$$ with$a_i$4-byte/32-bit words. Obviously you can't guarantee a unique 32-bit hash from an unbounded domain, due to the pidgeonhole principle. Neither can you make finding collisions infeasible, since$2^{16}$MD5 ... 0 You cannot escape the birthday bound - it will eat your lunch lunch every time. MD5 has a good uniform distribution, so should your algorithm. Since it outputs 32-bit values, you should expect collisions after around$\sqrt{\frac{\pi}{2}2^{32}} = 82137$hashes. 0 In chaos theory the defining attribute of a chaotic system is that small changes in the starting state tend to compound. If you look at the internal round structure of many hash functions, you will see a similar phenomenon: a single bit's change in the input will spread more and more evenly to all the state bits as you go through the rounds, until it is ... 11 I restrict to hash functions$H$with an output of some fixed size$n\ge1$bit(s), accepting as input some strings, including all$n$-bit strings; MD5 (resp. SHA-1, SHA-256) is an example of such function for$n=128$(resp.$n=160$,$n=256$). Whether there exists a solution to$H(x)=x$depends on the particular hash function. If$H$is a random function (as ... 0 You could, but generating such a table may get prohibitively expensive. It may also prevent other optimizations, like merged chain removal. If you had a data structure keeping track of the whole dictionary, you could tick off each entry when you add it to a chain at any point, then start each chain from an entry not already used. However, in the cases where ... 0 Let's assume 7 bits per character (ascii). So for each character, there are$2^7$different choices. So, if you are looking at 5 character passwords, that's$2^{7^5}=2^{35}$different passwords. If the hash function output is 256 bits, we have to store (at the absolute minimum)$2^{35} * 256$bits. That works out to be$1024$gigabytes of data (1TB). So in ... 3 In French, cryptographic hash function translates to fonction de hachage cryptographique. 3 The answer you are looking for is that a pre-image/2nd pre-image attack on two combined hash functions is at least as difficult as an attack on the stronger of the two hash functions. Take a look at Joux's paper on multi-collisions. There is a section on pre-image attacks for concatenated outputs. (I suggest reading the entire thing. It's one of those rare ... 1 The concept of indistinguishability from random is one of the most important in cryptography. Not only for hash functions, but for most cryptographic primitives, if not all. Generally speaking, its importance relies on the fact that something which is not indistinguishable from random might be leaking some private information. Thus an attack might be ... 3 The sponge construction does not have a compression function in the sense of traditional hash constructions like Merkle–Damgård. Instead, it operates using a permutation function$f$which "mixes" or "absorbs" the input into the state of the algorithm. Strictly speaking, it does take an input larger than the output it produces, but this function is ... 4 Assuming the output is uniformly random, the probability of any given bit being 0 is$\frac{1}{2}$. So the probability that$b_0,b_1,b_2...b_{14} = 0$is${(\frac{1}{2}})^{15}$. On average, it will require$2^{15}\$ calls to find a hash where the first 15 bits are 0.

1

The right way to approach this problem is to think of the inverse problem. I.e., given N outputs from the hash function, what is the probability that none of them have the desired number of 0's? One minus this probability is the probability that at least one will have the desired number of 0's. Once you know this, you can figure out how many outputs are ...

Top 50 recent answers are included