# Tag Info

23

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, ...

20

This isn't necessarily unexpected. 32-bit platforms vs 64-bit platforms can make a significant difference, as well as the amount of data you're hashing. $uname -m x86_64$ openssl speed sha256 sha512 The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes sha256 ...

16

SHA-512 has 25% more rounds than SHA-256. On a 64-bit processor each round takes the same amount of operations, yet can process double the data per round, because the instructions process 64-bit words instead of 32-bit words. Therefore, 2 / 1.25 = 1.6, which is how much faster SHA-512 can be under optimal conditions. Of course there is memory overhead, ...

9

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$$ ...

7

Introduction BCrypt is a password-based KDF (far from state-of-the-art, but better than PBKDF2, because BCrypt requires sizable RAM, which greatly increases the cost of hardware-accelerated password search). Bcrypt is based on the blockcipher Blowfish, with the initial processing of the password reminiscent of Blowfish's key preprocessing. Bruce Schneier's ...

7

SHA-512 (and SHA-384) is usually faster on 64-bit platforms, and SHA-256 is usually faster on 32-bit platforms.

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

As far as we know, SHA512 acts like a random function. So, the only way we know to find a preimage whose hash starts with 0x12345678, is to go through distinct preimages, and hash each one until we find one that starts with 0x12345678. If the output of SHA512 is equidistributed (and we have no reason to believe it isn't), then the probability of any hash ...

3

No, there is no known way. It would actually be rather surprising if there were even a theoretical way; the SHA-256 and the SHA-512 compression functions are rather different (for one, one works with 32 bit words and the other works with 64 bit words); one wouldn't expect them to share any sort of relation.

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 ...

2

Actually, it's there on the list, just with a different name -- the approved algorithm you want is listed as "SHS" (Secure Hashing Standard). Now, the term "SHS" doesn't distinguish between the various flavors of SHA-2 (and SHA-1, which is still approved for some uses); however if you look at this more detailed list, that gives details on what vendors have ...

1

I don't think this problem is solvable as specified. With a small message space, and deterministic hashing (or encryption), a generic attack involves exhaustively searching all likely messages to find one that corresponds to the known hash / ciphertext. If all of the digits of the ID numbers were random, an exhaustive search would require about $10^{10} ... 1 Hashing a password does not necessarily weakens the password. What is more important in this case is the collision resistance of the hash algorithm. As long as the collision resistance is given a hash values used is enough to get a high security. 1 I would feel perfectly safe with a 72 byte password. Computing a shorter hash of a longer password is not necessarily weakening your scheme. Passwords are typically not truly random and contain only human readable characters, so that for instance a password of 60 bytes may have an entropy of only 32 bytes. See https://en.wikipedia.org/wiki/Password_strength ... 1 While OAEP uses a one-way function on the plaintext, it's not quite a hash: it's called a mask generation function (MGF), and unlike a hash it can produce as much or as little output as you want (the output length is an argument to the function, and input length is decoupled from output length). This output should be pseudorandom. You use this in a ... 1 There exist many standards which describe a lot of padding modes and security protocols. If you're new in that field, I strongly recommend you to study the family of PKCS standards which are the reference in the domain. There also exist other distinct standards depending of very specific application fields (Banking, mobile, Cloud, Embedding ... or Global ... 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 ...

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