# Tag Info

0

The entropy for the output of SHA-256 truncated to its first $128$ bits when fed a random $128$-bit input is about $127.173$ bit. The entropy in the full output of SHA-256 when fed a random $128$-bit input is extremely close to $128$ bit; a plausible conjecture is that it is exactly $128$ (no collision), $128-2^{-127}$ (a single collision of two inputs), or ...

3

Do you know the article If You’re Typing the Letters A-E-S Into Your Code You’re Doing It Wrong? This is basically the same, but with a focus on hashes. There is a quite important misconception in your system: you stated "One of its design goals was high security." and then you start implementing your selfmade algorithms, even stating: "same key is used ...

0

It's probably a bit late, but it's relatively easy to get an estimate of entropy. It doesn't matter if some bits are repetitive or not as it's the bits that aren't that contain entropy. You don't need any weird transformations of the data. You have what is called a bit fixing entropy source. Stick all your integers into a single file (binary or ascii - ...

0

You can use xinput --test to record mouse movement data and then "crunch" the recorded data into a random hash using a hash algorithm like MD5. E.g. xinput --list (shows your mouse device id is 15) and you want to collect 5 seconds of mouse data: $> mouse_data=$(timeout 5 xinput --test 15) If you want to play around with a script that incorporates ...

4

I ran the command under dtruss on OSX, with it pointing to a static file. Even then, it appears to use this as an additional source of randomness to /dev/urandom. It's distasteful and almost certainly pointless. But assuming it only mixes the data into an already cryptographically-secure source of randomness, it's not actively harmful. That said, I can only ...

Top 50 recent answers are included