# Tag Info

1

I do not recommend inventing your own protocol for this. Instead, I recommend using TLS client certificates. They solve exactly your problem, and solve it well. The TLS folks thought a lot about the security challenges involved in designing such a protocol, so you wouldn't have to. You mention that you perceive the complexity of client certificates to be ...

0

As pointed out in an answer to an older question, SHA-224 is more or less just using the first bits of the output of SHA-256. That is just about the most official construction anyone can find. The XOR approach is however not entirely unprecedented, for example Linux uses that approach on SHA1 in order to generate random bits. There is real security to be ...

0

HMAC: The hmac version is considered slightly more secure than sha-256, assuming it's also based on SHA-256, because the HMAC formulation folds in the key material with 2 rounds of hashing, making it harder to use a chosen plaintext attack on the digest. SHA-256: SHA-256 should be relatively secure against chosen plaintext attacks, but it's better to be ...

0

Your options are: Use secp192r1 and truncate the hash. Then you have 96-bit security. Use secp256r1 and full SHA-256. Then you have 128-bit security. Both elliptic curves and hashes usually* need to be twice the "effective security" bitlength. Even 96-bit security is most likely enough at the moment, but some estimates put it within reach in e.g. a few ...

1

NIST FIPS 186-4 at the end of section 6.4 states that: When the length of the output of the hash function is greater than the bit length of $n$, then the leftmost $n$ bits of the hash function output block shall be used in any calculation using the hash function output during the generation or verification of a digital signature. In section 6.1 ...

Top 50 recent answers are included