# Tag Info

16

As Richie Frame noted in the comments, you basically listed them in order of ascending collision resistance. The latter hashes have greater collision resistance due to their increased output size. With the exception of SHA-1 and MD5, this is denoted by the number in the name of the algorithm. For example, SHA-512 produces 512 bits of output. The size of ...

10

So in general, isn't this equivalent to what Bcrypt and PBKDF2 do in terms of password storage security? PBKDF2, yes, pretty much. The only real difference is that salt/password are used the other way around, with the password mixed in at every step. Bcrypt, however, is different. In your case an attacker only needs a small amount of memory compared ...

8

You are correct: The 'workhorses' or primitives of cryptography, hash functions and block ciphers, can be used in such a way that they accomplish each others tasks: A hash function can be used to generate a key stream just as a stream cipher or block cipher in CTR mode (see e.g. Salsa20). And a block cipher can be transformed into a hash function (e.g. a ...

7

Hexadecimal is traditional -- by this, I mean that there first were command-line tools that used hexadecimal for output, then other people using the hash functions found it fit to stick to hexadecimal, if only to be able to compare their values with the output of the aforementioned tools. That's how traditions get established: a more-or-less random choice at ...

4

Should be comparable in strength to $H(m||k)$. The weakness is that a collision in the inner hash breaks the MAC. Using strong hashes the strength in bits is $\min(2^{n_O},2^{{n_I}/2})$ where $n_O$ is the output size of the outer hash and $n_I$ the output size of the inner hash. But since cryptoanalysis usually breaks collision resistance long before it ...

4

Your first sentence is entirely wrong. A OTP is a theoretical construct that requires a fully random key (at least) the size of the plaintext. Limiting the amount of random bits to 256 will by definition not be an OTP - at least not for constructions that accept a plaintext larger than 256 bits. The same idea is that if you use a key called $i$ which is ...

4

We can easily find collisions for this system. Let $x=(x_1,...,x_n)$ be a sequence such that $h(x)=k$. For finding collision we can do this: Select $x'=(x_1',...,x_{n-1}')$ and then compute: $$x_n'=({a_n}^{-1}\cdot(k-\sum_{i=1}^{n-1}a_ix_i')) \bmod N$$ Now we have $h(x)=h(x')=k$.

4

Your scheme is likely sound as the SHA-256 hash limits the input to the MD5 hashing function. If this was not so it could be possible (though very hard) to create a collision because of the break. Generally it is more secure to simply use the 128 leftmost bits of the output of SHA-256. SHA-3 - or rather SHAKE256 - would be even better if available. Keep in ...

4

Although your scheme is secure - especially with a random key of 32 bytes or higher - it won't offer any benefit over HMAC. It's therefore not recommended to use such a scheme. Also note that `bcrypt has been designed for key stretching which is deliberately not efficient. You have ample entropy in your key so there is no need for key stretching.

3

The question is how much is this schema secure? Not significantly more secure than sha256(m + k) is and may be less secure. An attacker who could arrange a collision for that would trivially also get a collision for the bcrypt hash of that, regardless of the salt value. While SHA-256 is collision resistant, there are MACs that have better bounds, like ...

3

Well, let's start from the beginning then. The string "Hi" is actually encoded as {0x48,0x69} (as per the ASCII table), so a string-number array conversion is as simple as a bunch of table look-ups. Now converting between hexadecimal and binary and back is easy. Just note that each hexadecimal character corresponds to exactly four bits in binary (because ...

3

TL;DR: The zlib output is at least as unique as the SHA-256 output. Compression libraries like zlib have to encode the data in such a way that it is recoverably, which implies that they can not reduce the uncertainity (entropy) of the data. Because of this logic, the entropy of the encoded hash has to be the same as the one of the hash. Now as hashes tend ...

3

J.D.'s answer explains why you might want a block cipher in addition to a hash function. TL;DR: versatility. Stream ciphers, however, are not very versatile – at least synchronous stream ciphers are not. Yet they have not been replaced by hash functions. Why? Partly because they have been replaced by block ciphers instead (AES CTR, specifically), but also ...

3

It is not collision-resistant because the tag is only 64 bits, so on average only $2^{32}$ inputs are needed to find a collision. This is the classic birthday bound. This is completely insecure, so SipHash is not collision resistant. This is not a problem for hash tables because hash tables have collision-resolution mechanisms and because the odds of a ...

3

If $f:\{0,1\}^m\rightarrow \{0,1\}^n$ with $n\geq m,$ then of course there are, the set of one-to-one functions, but such a function is not a cryptographic hash function, since it lacks the compression property. If $n<m,$ (or more generally if $|X|>|Y|$ for $f:X\rightarrow Y$), collisions will happen.

3

Suppose we try C(password) = A(password) + B(password) where + is just concatenation of the hashes. The result of this is obviously a weaker hash: we can preimage C by finding the original password by cracking A or B. This is incorrect with the standard notion of preimage resistance. Because there are many more possible inputs to a hash function ...

3

The strength here depends on the collision resistance of $H$. If $H$ is not collision resistant, like MD5, then the attacker can find $H(m) = H(m')$, ask for the MAC of one message and forge it for the other. So for many secure hashes you lose half the security bits. E.g. SHA-256 should give you a 256-bit secure HMAC, but would be at most 128-bit secure in ...

2

Is there any possibility to make a successful verification with just modifying message and signature, and without modifying public-key ? One would certainly hope not. If you can, then you've just shown that the signature algorithm used is broken, and not to be trusted. For a signature method to be considered secure, then it is required that someone ...

2

I'm not a Java programmer, and I didn't compile this, but I modified answer to this question to achieve a hash chain of length equal to four. byte[] bytesOfMessage = yourString.getBytes("UTF-8"); MessageDigest md = MessageDigest.getInstance("MD5"); byte[] thedigest = md.digest(md.digest(md.digest(md.digest(bytesOfMessage)))); PS. Don't use MD5 for ...

2

Select $x=(x_1,...,x_{n-1})$ at random and then compute: $$x_n=({a_n}^{-1}\cdot(0-\sum_{i=1}^{n-1}a_i\cdot x_i)) \bmod N$$ Now, select $x'=(x_1',...,x_{n-2}',x_n')$ at random and then compute: $$x_{n-1}'=({a_{n-1}}^{-1}\cdot(0-a_n\cdot x_n'-\sum_{i=1}^{n-2}a_i\cdot x_i')) \bmod N$$ Now we have $h(x)=h(x')=0$. Note that this question was a ...

1

You can do either and the method works. Depending on which value is stored you check for existence in the table at different points in the computation. If the chains are long enough, the addition of a half step does not matter much for time, especially as the reduction function is typically very fast. However, when you are trying to break a key with a size ...

1

No, having multiple hashes will not make determining the secret which was hashed any easier.

1

In general, you never want to use CRC/weak checksum for any computations on secret material (like keys). CRC is a linear function and by showing CRC of a key, you reveal a lot of equations that hold among the key bits. This is equivalent to showing the same number of bits of the key as the length of the checksum. The proper way of doing it has been ...

1

I believe the only way you can do this is to assume you have fixed length inputs to the hash function $f$. Otherwise, it is problematic what probability distribution you'd want to impose on the input set $\{0,1\}^{\ast}$ which is the collection of all finite input strings. In practice, hash functions do have an upper limit on the input string, but that's ...

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