New answers tagged

2

As others have explained, 'bits of entropy' refers to to the guess-ability of the original Password or other text that was first used to create the SHA-256 hash. In your example case the entropy is unchanged. What you've done here is provide an SHA-1 version and an MD5 version of the SHA-256. This makes the SHA-256 more guessable than other solutions you ...


18

And it is longer than the input string, with 288bit instead of 256bit. So did we actually increased the entropy? No, you did not increase the entropy. In this context, "entropy" basically refers to the probability of any particular guess about the content or value being correct. If I tell you that I have hashed a single lowercase US English letter's ...


2

You are certainly not adding entropy. You still only will have at most 256bit entropy possible outputs of this schema, no matter how many times and how you rehash this. Note that you will have at most 256 bit entropy, because you did not told us about how much entropy is in your input. SHa256 will also not give you 256bit entropy if you have less than that ...


0

did you increase the entropy... most likely not. All you did is use 2 older hashing functions to get a new hash. since this has no new data, entropy is not affected. The amount of bits here makes no differences whatsoever (since its just 'another way o writing' the original hash.) Entropy (in cryptography) has to do with the amount of uncertainty a ...


0

Linux uses TSC by default for its clock source due to its lower overhead, and only uses HPET as the fallback. The kernel gathers entropy from interrupt timing intervals, using the RDTSC instruction on x86 processors. Unless you do not have TSC support, then I do not believe disabling HPET will influence your entropy collection at all. Only on certain ...


7

Not really. Hashing algorithms and Key derivation functions (side note: bcrypt is a KDF, not hash) works on bytes, not characters. This means instead of working on Unicode, it sees instead the utf-8 encoded bytes (or whatever encoding you use). So the hash/KDF itself wouldn't have any problems processing Unicode passwords. However, Unicode had many ...


3

BCrypt won't work with a NUL byte because it is reserved for its own internal use (I think to keep track of the end of the password or something). Other than that what BCrypt really does is hash an array of bytes, not characters. From its point of view, its just blending up numbers and whether those numbers correlate to a presentable string in one character ...



Top 50 recent answers are included