New answers tagged

3

The question is how much is this schema secure? Not significantly more secure than sha256(m + k) is and may be less secure. An attacker who could arrange a collision for that would trivially also get a collision for the bcrypt hash of that, regardless of the salt value. While SHA-256 is collision resistant, there are MACs that have better bounds, like ...


4

Although your scheme is secure - especially with a random key of 32 bytes or higher - it won't offer any benefit over HMAC. It's therefore not recommended to use such a scheme. Also note that `bcrypt has been designed for key stretching which is deliberately not efficient. You have ample entropy in your key so there is no need for key stretching.


4

Your scheme is likely sound as the SHA-256 hash limits the input to the MD5 hashing function. If this was not so it could be possible (though very hard) to create a collision because of the break. Generally it is more secure to simply use the 128 leftmost bits of the output of SHA-256. SHA-3 - or rather SHAKE256 - would be even better if available. Keep in ...


5

TL;DR: Fortuna is a CSPRNG so you can replace components pretty arbitrarily, because you're not bound by compatibility requirements and the modifications should work, although there are some points that are note-worthy. In Fortuna (PDF), AES-256 is used in exactly one place: To generate the keystream based on the current counter (the function is even called ...


4

Short answer: 32 bytes of full-entropy key is enough. Assuming full-entropy key (that is, each bit of key is chosen independently of the others by an equivalent of fair coin toss), the security of HMAC-SHA-256 against brute force key search is defined by the key size up to 64 bytes (512 bits) of key, then abruptly drops to 32 bytes (256 bits) for larger ...



Top 50 recent answers are included