nwipe does not write proper prng data on drive with "--prng=isaac" option

[alphanis]

Bug report.
I wrote the same article on shredos.
PartialVolume/shredos.x86_64#33

nwipe writes some kind of log data instead of actual prng data on drive, with "--prng=isaac".

To reproduce this bug, try one of these:
sudo ./nwipe -v --prng=isaac --verify=all /dev/loop29
or
sudo ./nwipe -v --prng=isaac --noblank /dev/loop29

In the first example you will see verify errors.
In the second example, you can use hex editors to see strange log data (instead of prng stream) is written on drive.

My test results below show there are 4 KiB blocks in written drive. Each blocks begin with log text followed by bunch of 0x00. 0x41F00100 and 0xF1EF0100 are wrtten in footer.

[PartialVolume]

Confirmed, working on a fix. Thanks for reporting.

[PartialVolume]

There seems to be a couple of related bugs in the code. I've found that if you don't put any prng option on the command line and just use the GUI to select isaac, the wipe appears to work. While it does indeed wipe using a prng stream it actually works because the mersenne prng is being used and not the Isaac prng. Whichever random number generator you select via the GUI, mersenne will always be used, hence why it's not failing when isaac is selected via the GUI. So it would seem the first bug is probably in the GUI code for RNG selection.

The second bug being a non functional isaac RNG. When putting isaac on the command line, I have confirmed it attempts to use the isaac code which we see fail. If you put prng=mersenne on the command line, the mersenne code will be used so then works without any error.

I'm surprised this error hasn't been picked up by anybody before, but then maybe most just use the default mersenne RNG. This may take more than a few days to fix as I've not worked on the prng code before, so I've got to familiarize myself with the code so I'm sure I understand how it's actually working before I make changes. I'm assuming the core RNG code is fine but the problem is nwipe's implementation.

[PartialVolume]

Looks like the Isaac read function doesn't work because of a function that is supposed to read a 32 bit random number from the Isaac prng, doesn't actually contain any code to do that. Basically, it seems it was never completed. Looking back at the history it certainly goes all the way back to the initial commit in 2013, and looking at dwipe's code this function may also never have been finished. I need to dig deeper and confirm that the bug also exists in the dwipe/DBAN code though as there are some differences in the code in prng.c so that's definitely not confirmed yet. On the plus side it looks relatively easy to fix in nwipe.

[PartialVolume]

I've fixed the Isaac read function and the data written to the drive has been checked with a hex editor. All appears correct. I ran some tests using method=prng, validation=off, blanking=off using both mersenne and isaac on a 1Gbyte loop drive. Mersenne took 15 seconds to fill the drive, while isaac took 31 seconds. In comparison, a zero fill, validation=off, blanking=off takes 13 seconds on the same 1GB loop drive. Comments in various forums suggests isaac is slightly slower, I just wasn't expecting twice as slow. Maybe there is a further bug I need to track down or maybe isaac is just more CPU intensive than mersenne.

Isaac is supposed to be more secure and maybe that comes at the price of heavier CPU usage. The code for isaac does look more complex than mersenne so maybe not a surprise. I guess profiling may confirm that. I may commit as is and come back to see if there is a way I can optimise it's speed. This issac implementation can generate 64 bit output so maybe using that rather than 32bit may speed things up.

[PartialVolume]

Fixed by #320
Fixed by #321
Fixed by #322
Fixed by #323

[alphanis]

Thank you for fixing this fast.

For reference, there are 32 bit and 64 bit version of C implementation of ISAAC, according to very author's website: https://burtleburtle.net/bob/rand/isaacafa.html
I guess 64 bit one will be more efficient because 32 bit can produce a 32 bit value per 18.75 cycles, and 64 bit can produce a 64 bit value per 19 instructions.

[alphanis]

Just in case, Bob's implementation uses rand() and this name is same to rand() from stdlib.h, according to this: https://stackoverflow.com/questions/34571718/c-rand-function-and-isaac-random-number-generator

[Firminator]

Does that mean that the commercial programs using DBAN on their backend (Blancco?) were actually not using ISAAC either since they is no evidence that they found this bug since their source is not open-source and not verifyable. That's a pretty big deal. Big up to alphanis for making the extra effort using hexedit on the drive. Good catch. Thanks PartialVolume for deep-diving into the code.

[PartialVolume]

I don't know anything about the blancco product but I would have been surprised if they were using DBAN as their backend, if they had been doing anything like that I would have thought they would be in breach of the GPL license, by not submitting any changes to the code, so I doubt that's the case.

I always thought their purchase of the DBAN brand ( I assume it was a purchase and the original author got paid) was a shrewd marketing/sales decision by blancco to not so much use the DBAN product itself or alternatively 'take out' or 'bury' the DBAN product but simply provide a steady stream of potential customers to the blancco website, while providing little support in terms of upgrades to the DBAN product while simultaneously differentiating the Blancco vs DBAN in favour of Blancco. After all a quick search on Google will still show up lots of websites that rate DBAN number #1, those sites annoy the hell out of me as they are all so superficial and out of date. But of course somebody that wants to wipe a disc sees #1 and takes a look at DBAN to only to be taken to blancco where they tell you that you really want to buy the blanco product.

It could be worse, Blancco could start deleting sourceforge forum posts, including the one where I reported the PRNG issue. At least if people take the time to read the forums they will come across Shredos and realise DBAN hasn't been updated in 6/7 years. If Blancco deleted all the forum posts nobody would get to learn about nwipe Shredos and all the other linux distros that include it, without digging a lot deeper. (Hope I've not given them any ideas).

One thing I would like to see is websites that push DBAN such as https://www.lifewire.com/dban-dariks-boot-and-nuke-review-2619130 and https://www.lifewire.com/free-data-destruction-software-programs-2626174 replace DBAN with ShredOS and nwipe. Even their link doesn't take you directly to either nwipe or Shredos.

[Firminator]

True. Just look at Intel.... yes Intel! They seriously need to update their KB @ https://www.intel.com/content/www/us/en/support/articles/000006198/memory-and-storage.html recommending DBAN when there are more recent (up to 2018 using NHellfire's DBAN fork) and currently maintained (ShredOS) alternatives available. Then they also mention KillDisk and russian HDAT2 both of which I used like 15 years ago before there was any DBAN :shudder: