# Tag Info

20

As a general rule, you should avoid SHA1 for new applications and instead go with one of the hash functions from the SHA-2 family. As far as truncating a hash goes, that's fine. It's explicitly endorsed by the NIST, and there are hash functions in the SHA-2 family that are simple truncated variants of their full brethren: SHA-256/224, SHA-512/224, ...

8

The initial hash values for SHA-512 are the 64-bit binary expansion of the fractional part of the square root of the 9th through 16th primes (23, 29, 31, ..., 53). That is: $$I_0 = \left \lfloor \mathrm{frac} \left (\sqrt{23} \right ) · 2^{64} \right \rfloor$$ $$I_1 = \left \lfloor \mathrm{frac} \left (\sqrt{29} \right ) · 2^{64} \right \rfloor$$ $$\cdots$$ ...

6

No, because a hash behaves (simply put) like a lossy compression function. Meaning: you can use a hash like a sort of checksum, which enables you to identify and compare data. Using hashes, you can see if data has been modified (which, if re-hashed, would show a different hash as a result), or if two or more data packages are the same (every data package ...

5

No, this protocol does not provide perfect forward secrecy. Record the initial key transport message (shared via RSA-OAEP). If the attacker later gets access to the corresponding RSA private key, and decrypts the original key transport message, the entire symmetric key evolution sequence for that session will trivially unfold.

4

In general, your way to select one of the entries seems unnecessary complicated. As fgrieu pointed out, you should be fine by reducing the hash value modulo the number of participants (But with $n$ people, you calculate $h$ mod $n$, and assign the numbers from $0$ to $n-1$). An important question though, is how you determine the input to your hash function. ...

3

Leaving text encryption and padding questions aside and focusing on the header stuff, here's how I'd approach the problem: FileHeader = { BYTE Salt[16] # Random bytes, K = KDF(Salt, Password) BYTE EncHdr[] # EncHdr = AES-GCM(K, h0...h5) } Salt is a sequence of random bytes (it's there to prevent Rainbow table attacks) EncHdr is the encrypted version ...

3

The SHA-2 family is built from a block cipher in a Davies-Meyer construction, where the message is considered they key, and the current hash value the plaintext. The 2nd set of constants in the SHA-512 round function is 14, 18, and 41. Rotations are also performed in the message expansion (key schedule), and are also important. The block cipher at the ...

3

generate a random number that users can later verify was not fixed/influenced in any way by me. There's no way to do that on your own. But you can ask users to contribute to the seed, eg. Generate a seed $s$ Commit to $s$ and send commitment to the user User generates his own seed, $s'$ and sends it to you Combine (eg. XOR) the two seeds together. ...

3

The simplest and obvious solution is to just do it. JTR (or any decent password cracker) will show a realtime ETC and this is much better than speculating endlessly about hardware specifications. But if you must, read on... This is highly dependent on the number of iterations you used for the KDF. But you can calculate it easily. Suppose selecting one ...

2

Hash functions have several security criteria, one of which is called pre-image resistance. Pre-image resistance means that given an output hash value $h$ and hash function $H$, an input $m$ such that $h=H(m)$ cannot be computed efficiently. SHA-512 is currently in good security standing. There are no practical pre-image attacks, which means that, no, the ...

2

Your wording is important: "retrieve the original data just from the sha512 hash" - the answer to that (strictly speaking) is no. The best you can do is to try hashing a given number of possible byte-combinations (eg, the contents of the file) until you find an output that matches your original hash. For a short byte-string, this attack is viable ...

2

By inventing your own random number generator, you are chasing a red herring. There is no need whatsoever for you to invent your own RNG. Combining cryptographic primitives on your own is exceedingly dangerous, and worse, there's no actual need to do so. Unfortunately, if you are only choosing 10 numbers between 1-100, there are only $100^{10}$ possible ...

2

BCrypt is considered more secure The theoretical security of bcrypt has received less scrutiny than that of PBKDF2, SHA2 and HMAC. PBKDF2 is thus widely standardised (e.g. in NIST SP800-132 and PKCS #5) while bcrypt is not. In practice the security (resistance to brute force attack or dictionary attack) of bcrypt and PBKDF2-HMAC-SHA512 can be ...

1

No. An RSA signature is just a single number, encoded in a certain way. The number represents $x^d$, where $x$ is a padded hash of the document and $d$ the private exponent. If you know a public key $(m,e)$, you can calculate $x = (x^d)^e \mod m$, but without a document (or at least its hash) there is nothing to compare it with to verify anything. The only ...

1

References Related to your reference request: SHA512withRSA points to the RSA Signature Scheme with Appendix based on PKCS #1 v1.5 with SHA-512 hash function. This means you’re looking for reference documentation describing RSA PKCS1 v1.5 (see: RFC2313) signatures with SHA512 (see: RFC6234) hash and X.509 encoding format. Removing “overhead” from code As ...

1

So, here's my question: is there a point where the salt size doesn't matter anymore in terms of security and where it might even decrease it? The purpose of a salt is to prevent the attacker from targeting multiple users' passwords with the same try or caching common passwords' hashes in a table. You need enough salts that each user has a unique salt. ...

1

With your clarification edits it is clear what you are looking for. Generated Value = SHA512(A || B || C) Where A = 512 bit secret Where B = x bits server seed and can be attacker chosen Where C = x bits client seed and can be attacker chosen The thing I am curious about is if it's possible for end-user to guess secret seed if he is given ability to ...

1

For observe who has not seen the inputs to SHA-256, the output should appear uniformly random sequence. Quite a few random number generators, for example ANSI X9.31's RNG and NIST SP 800-90 Hash_DRBG use SHA family hash functions for the reason that resulting sequence is hard to distinguish from random. Is any segment of 5 characters chosen from ...

1

Say I hashed the output from a random number generator (with nonce), would the resulting SHA256 hash be as random as the inputted number? Let's suppose you flipped a perfectly fair coin. You flip it 1024 times to create a bit string of 1024-bits. Because the coin is perfectly fair, this means that each strings of 0s and 1s will appear with precisely ...

1

The answer depends on what the XY Exabytes big data contains. If it contains very small amount of information, it may be possible for attacker to find the correct input by a trial. Maybe the XY exabytes of data is just some large 8K resolution video available from specific http://xxx.xx.xxx address or just full of zero bits, or ... In case the XY Exabytes ...

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