# Tag Info

10

Expanding then shrinking in SHA-1 refers to the process, performed for each round (each 512-bit block of padded message), of message expansion from 512 bits to 2560 bits; keeping only 160 bits of state for the next round. The later directly follows from the construction of SHA-1 as a Merkle-Damgård hash of 160 bit. The former occurs because SHA-1's ...

5

There are a few pitfalls: File name integrity: signing files one at a time signs the contents of the files. It (typically) does not protect the file names from tampering. This could be disastrous in some situations (e.g. an attacker could change blacklist.txt to whitelist.txt). Set membership integrity: signing individual files does not prevent adding or ...

5

It depends of course on the hash function you're dealing with. Assuming it is a cryptographically secure hash function, you're still looking at brute forcing the output: in other words, trying every possible input, computing the hash and then comparing with the output. Finding two inputs with the same output is a hash collision. Consider the MD5 hash ...

4

SHA-1 (and, in general, any modern cryptographical method) will generate an arbitrary bitstring. The bit string 0x22 (the ASCII code for double quote) is as probable as any other bitstring. You could attempt to detect (and escape) such byte values; another possibility is convert the bitstring into hex or base-64; those have a deterministic size, and may be ...

3

I know SHAKE128 and 256 are part of the SHA-3 standard but is the SHA3 standard officially released yet? i can only find a draft of the publication, does this mean it's not official and therefor not proven to be secure? No, SHA-3 has not been formally approved. On the other hand, what do you mean "not proved to be secure"? Do you really thing that ...

3

The entropy for the output of SHA-256 truncated to its first $128$ bits when fed a random $128$-bit input is about $127.173$ bit, down from very close to $128$ bit before truncation (likely $128-k\cdot2^{-127}$ bit for $k\in\{0,1,2\}$). The truncation does not halve the entropy, because the halves are not independent. The right line of thought is that ...

3

If we use $H_1(X) = H_0(X) \oplus firstnbits(X)$, this would seem to be trivial. EDIT: As Cédric Van Rompay pointed out, this is only a counterexample if $H_1$ winds up being preimage-resistant. This may not be a necessary consequence of $H_0$ being preimage-resistant, but I really only need one case where it is.

2

Cryptographically secure hashes usually work on bitstrings of arbitrary length and output a fixed length bitstring. The secure part is being collision resistant and preimage resistant, so that you have a practical oneway function, and those are the properties you want for "scrambling". As fgrieu psted in the comments, one easy way to do this is to utilize ...

2

The hash output is a random string of a length specified by the function (that is 160 bits for SHA-1). It may contain any special characters, including e.g. white space. It is more common to encode the value in hex than to use quoting of special characters are special characters are very common in hash output (minority of characters would be ASCII if no ...

2

I think what you're missing here is that a cryptographic hash by itself is not actually sufficient to verify the integrity of a message. Consider this: I want to send a message over the Internet (on an insecure connection, e.g. UDP), but have it be protected from tampering. I take the message and attach at the end a cryptographic hash of the message (e.g. ...

2

I'll consider only a non-adversarial model for the requirement of a low collision probability; that is, we are considering naturally-occurring strings only (which implies they are of bounded size; I'll limit it to $2^{64}-1$ bits, over 2305 Petabyte). However I'll consider that we need to reliably detect strings that differ only in a small consecutive ...

1

It seems to me that you don't need a cryptographic hash function, that is, a function that provides preimage resistance, collision resistance, etc. or at least to the degree that cryptographic applications require. Anyway, it seems that you could use a hash function that follows the Merkle-Damgard construction, but without doing the length padding at the ...

1

It depends. If you have full control over the whole system, all components and can use whatever algorithm you want to deploy, you can stick to the one giving you the best efficiency which fulfills your security requirements. In this case, it would be Tiger. However, Tiger has a 192 bit output. If that is not enough for you, go for SHA256. However, if the ...

1

Yes, there's an issue: you're adding needless complexity, which gives you absolutely no benefit. The whole point of a PBKDF is to be slow; passwords are low-entropy, and the only way to mitigate brute-force is to make it take time to compute hashes. It can't take too long to log in, so you have to balance "fast for a user" and "slow for an attacker." ...

1

If it is for completely random data you could still make a program that uses the random looking input to make different choices. For instance, you could sign two .jar files in Java, using the SHA-256 hash over the file in the META-INF folder. Then you can use the different files a property to make one choice or the other. Basically you're replacing one of ...

1

Signing files individually will create independent signatures for the contents (not filename) of each file. A potential downfall here is that the items could be removed or renamed without detection. Let's say, for example, the files to be signed are alice-invoice, bob-invoice, and chris-invoice. If each file is individually signed, and bob-invoice is ...

1

TL;DR, you don't. At this point, we have algorithms we believe are unbroken by current adversaries. For hashing, this includes the SHA-2 family of hashes, SHA-3, BLAKE2b and others. For authentication, we have the HMAC family of functions, the UMAC family of functions, Poly1305, and others. For symmetric encryption, we have AES, ChaCha20, and others. For ...

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