The Stack Overflow podcast is back! Listen to an interview with our new CEO.

New answers tagged

4

I seem to recall that shared secret keys should be hashed before using as encryption keys (some brief discussion here). If your key is already high-entropy, then hashing with SHA256 is fine. If you plan to generate several keys (ie, encryption and HMAC) from the original shared secret, then HKDF is a good option. This is a key-based KDF. Scrypt and ...


1

If you use the same size input, there may no be a collision at all. It is better to increase the input size like double of $n$. Note that the input is padded so that the input to $\operatorname{SHA256}$ it is multiple of 512-bit. Keep generating two random string You need to store all the hashes to see that there is a collision. If you don't store ...


2

In $W_t = \sigma_1 (W_{t-2})+W_{t-7}+\sigma_0 (W_{t-15})+W_{t-16}$ The $16$ is the number of 32-bit words in a SHA-256 block. It is here so that, when we consider $W$ as an array of $16$ rather than $64$ words (as most hardware and many software implementations do), the equation become adding to $W_{t\bmod 16}$ a feedback term $\sigma_1 (W_{t-2\bmod 16})+W_{...


1

Cyclic redundancy checks are for quickly checking data integrity, mainly for detecting accidental data corruption. CRCs are not meant to be attacked, not even by your little brother, they are easily reversible, and have one application. Think of the CRC as functioning along the lines of a hand-held calculator. Cryptographic hashes can help protect national-...


1

So what's the point then, if they both detect such small errors? What CRC* can't do and SHA* and some MD* can, is that the latter are usually strong enough to prevent any supercomputer from creating 2 different files with the hash digest, where as CRC* don't have such strength. CRC* are good at detecting "wire noise" errors, but otherwise lacking certain ...


8

CRCs are OK to detect naturally-occurring errors. But in cryptography, we face intelligent adversaries, which can use the mathematical properties of CRCs in order to make an arbitrary alteration in a file without altering its CRC. This is easy, even for large CRCs. Hashes are designed to prevent that (called a second-preimage attack), and other attacks such ...


2

SHA256(SHA256(x)) Would this be a bijective mapping? or Surjective mapping? SHA-256 is almost certainly not injective on 256-bit inputs, so it is almost certainly not a bijection or a surjection onto 256-bit outputs either. And if SHA-256 is not injective, then applying it twice can't be injective—if $x \ne x'$ are distinct preimages of $h$ under SHA-...


0

Your hash is f1534392279bddbf9d43dde8701cb5be14b82f76ec6607bf8d6ad557f60f304e because b'00' is parsed as a string. The NIST specification is correct: SHA256 with a zero length argument should always result in e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 It may also help to know that with one single byte set to zero, the hash is ...


0

It is the naming of functions and the functions are already defined - rotations (ROTR) and x-ors ($\oplus$). There are two $\Sigma$ and $\sigma$ functions for SHA-256 and SHA-512 series. And, in Greek, the $\Sigma$ is capital of $\sigma$. The upper index represents the SHA family as 256 and 512. The sub-index, selects the function. $\Sigma_{0}^{\{256\}}$ ...


2

First of all, note that, SHA-256 operates on a minimum of 512-bit messages. The message is always padded to be a multiple of 512-bit ( see padding below). For double SHA256(SHA256(m)), after the first hash, the result is padded to 512-bit. padding: The SHA-256 message format |L|1|0..0|message size in 64 bits|. L is the original message bits to be hashed, it ...


Top 50 recent answers are included