Brett K

I can now confirm through testing that AES + RIPEMD160 works and Twofish + SHA256 does not work anymore for the boot track.

Stuck at "Booting..." after correct password entered

So far -tlmin 27 seems to have solved the inconsitencies. But it is after midnight so I cannot test further, I will look at it Monday if I have some free time.

I just performed yet another test, this time I ran just 1 instance of it (not CPU loaded like before) and it's "passes" the file. I re-ran the same test and the next time it found 1 unusual. So it looks like this is not even a problem with my CPU cores being loaded, it looks like -multithreaded is not performing the same tests as singlethreaded.

I just performed yet another test, this time I ran just 1 instance of it (not CPU loaded like before) and it's "passes" the file. I re-ran the same test and the next time it found 1 unusual. So it looks like this is not even a problem with my CPU cores being loaded, it looks like -multithreaded is not performing the same tests and singlethreaded.

.

There is defintiely a bug, I used a file protected as Read Only and it still has the bugged output. This post has the REGULAR output when single threaded is used. Note that every time I run this test the same output occurs: [Low1/32]Gap-16:B R= -4.7 p =1-5.8e-4 unusual So I should get this SAME output every single time. The next post (I am limited to 1 attachment per post) will be the SAME input file going into the process, but with the -multithreaded command line.

.bss segment memory (Globals, Statics) are initialized to 0 at process creation as per the C standard, so the memory is initialized. I have added initialization but it made no difference in the bug occuring (see attached). Blake2b is not seeded, it is hashing the number 0, then the number 1, this is the while loop commented for you: static uint64_t input; // This is the input (you could call it a seed, it starts at 0) uint8_t output[64]; // This buffer takes the 512-bit hash blake2b(output, 64, 0,...