#36 Please make (Blanking) optional.

[Chubbypants]

.

Hi Darik

Would it be possible to make the “blanking” optional please ?

My reason for this is that some Truecrypt users wish to employ Truecrypts “plausible deniability” feature. This requires the user to have a “plausible” excuse as to why they have a slave hard drive full of random data and no file system. At first I thought it would be simple enough to be able to say that I had used DBAN with PRNG mode on the drive in question but after using a Hex editor I noticed that drives wiped with DBAN even in random mode were actually full of zeros !

I think I am right in guessing that DBAN must write first with random and then with zeros. So as you will probably have already worked out I would be grateful if the blanking could be an optional “opt in” option rather than an automatic on or “opt out” option.

In fact I think it might be better for DBAN and erasing if this was the case anyway regardless of the benefit to Truecrypt users as if someone is in a hurry to erase a disk one overwrite with random should confound most adversaries anyway so I am supposing “blanking” is just a cosmetic finish ?

Please consider this feature request as I don’t know of any other deletion software I would trust as much as DBAN to use but I still would like the ability to leave random data on the wiped drive instead of the “just out of the factory” look. Also it may look better for people who are simply wiping drives as a 4 year old drive full of zeros may look a little suspicious to adversaries in oppressive countries whereas at least the random look could be explained as file corruption.

Thank you.

[Darik Horn]

Logged In: YES
user_id=560878

Okay, I will think about adding this enhancement to the
dban-1.1.0 release.

Early DBAN releases did not blank the disk after running the
PRNG method, but this behavior confused people that did not
understand their forensics tools, which increased my support
load. this behavior will, therefore, never be the default.

[Chubbypants]

Logged In: YES
user_id=1535795

Hi Darik

Wow, you must have the fastest response time on Sourceforge !

“Okay, I will think about adding this enhancement to the
dban-1.1.0 release.”

Oh thank you so much ! That would be really cool.

“Early DBAN releases did not blank the disk after running the
PRNG method, but this behavior confused people”

That’s funny I would have thought it would have been more confusing this way round ! :o)

“which increased my support load. this behavior will, therefore, never be the default.”

I am sorry it increased your support load but I suppose it would make the “plausible deniability” more “plausible” if it was the default mode for DBAN as users could simply say they just ran the program. If you are absolutely sure you don’t want to make it an opt in then I would still be very grateful for an opt out !

How about a dialog box popping up after users have selected their deletion method and rounds selection to say “Would you like the drive blanking after deletion ?” This way users would know that their method of deletion would be carried out and then the drive would or would not be blanked depending on their selection at this prompt ?

Thank you.

[Trismegistos]

Logged In: YES
user_id=1575658

One thing should be mentioned: if you want to use DBAN as a
excuse you MUST use ISAAC PRNG, because if Mersenne Twister
is used, its output can be easy distinguished. Output from
ISAAC is better suitable for such purpose, because it is
cryptographically secure PRNG. And of course blanking should
be disabled...

[Chubbypants]

Logged In: YES
user_id=1535795

Hi trismegistos

I have tried some tests with the ISAAC PRNG and I was surprised to discover that it didn’t seem as random as the Mersenne Twister !

I used Die Hard and as I said for some reason Mersenne Twister seemed to get a more random result. I am not sure why perhaps you know of something ?

I understand your point that the ISAAC PRNG should be better in theory but it just doesn’t seem to work out like that for me. I think there is a better CSPRNG called Blum Blum Shubb or something like that ! It’s a funny name but I believe it is thought to be considerably more random. Perhaps this should be a future feature request.

I understand that Darik will probably be more interested in the deletion qualities of a given PRNG but I wish he would get interested in cryptography and Truecrypt. He is in a fantastic position to give Truecrypt users a great plausible excuse and I do hope he will take advantage of it and help us out a little.

Darik

If you ever re-read these threads Darik I hope you won’t forget this feature request (making blanking optional). I remember you said that it may be a feature in DBAN 1.1.0 but for Truecrypt users and myself in particular, the wait is agonising ! :o)

Thank you again Darik for at least thinking about this request and I do wish you would get interested in Truecrypt and make DBAN 1.1.0 a real boost to our plausible deniability. Actually, just thinking about it you may already be a secret Truecrypt user ! :o)

Thanks.

[Trismegistos]

Logged In: YES
user_id=1575658

Hello, chubbypants

I also did all tests from DieHard suite on ISAAC, and it
passed them all. Remember, DieHard author himself states,
that "p happens", so maybe results of test are not bad.

The bad thing with Mersenne Twister is that its pseudorandom
stream can be identified, so using DBAN with MT as PRNG
gives NO plausible deniability for TrueCrypt or any other
OTFE system. So when you use TrueCrypt on some partition,
you can't use DBAN with MT as excuse, because it can be
easily proven that Mersenne Twister was NOT used on this
partition. Even if ISAAC fails some DieHard tests, it has no
distinguisher. Being cryptogaphically secure it can be used
to aid plasuible deniability feature of OTFE systems.

In my opinion Mersenne Twister should be completely removed,
and only cryptgraphically secure PRNGs should be used, to
avoid unnecessary theoretical hair-splitting.

According to Wikipedia article at
http://en.wikipedia.org/wiki/Blum_Blum_Shub

"The generator is not appropriate for use in simulations,
only for cryptography, because it is not very fast"

Disk wiping requires fast PRNG, so BBS seems to be not well
designed for this task.

trismegistos

[Chubbypants]

Logged In: YES
user_id=1535795

Hi trismegistos

“The bad thing with Mersenne Twister is that its pseudorandom
stream can be identified”

Yikes I didn’t know that ! As far as I could tell from Die Hard MT was pretty random ! I would have thought that Die Hard would have shown some sort of pattern.

Can you please recommend a program to demonstrate how MT’s stream can be identified ? I always thought Die Hard was THE test ! :o)

“because it can be easily proven that Mersenne Twister was NOT used on this partition.”

I am relatively new to all this and I would love to know how you do this. Are you able to tell them apart ? What is the giveaway pattern in MT ?

“In my opinion Mersenne Twister should be completely removed,
and only cryptgraphically secure PRNGs should be used, to
avoid unnecessary theoretical hair-splitting.”

Yes this would be great but I don’t think Darik is interested in crypto related things especially with DBAN. I guess he is more interested in the deleting properties rather than anything else.

“Disk wiping requires fast PRNG, so BBS seems to be not well
designed for this task”

Well there could be an option to choose. The user could choose security or speed ?

Do you have any suggestions for algorithms trismegistos ? You seem to know a bit about this subject.

Perhaps if we come up with a small selection of suitable algorithms and make a good case for our request then Darik might implement it into DBAN 1.1 !!

Are you a programmer ? If so perhaps you could help Darik to use these new algorithms ? I am sure it isn’t as easy as we think to make these modifications so I assume Darik would be grateful for your help.

Thanks for adding some useful information to this feature request.

Chubbypants

[Darik Horn]

Logged In: YES
user_id=560878

I've been giving this ticket some thought, and the RCMP
TSSIT OPS-II method could already give you the plausible
deniability that you want.

Run the OPS-II wipe on your computer and then do the
TrueCrypt check.

[Chubbypants]

Logged In: YES
user_id=1535795

Hi Darik

I am very pleased to learn that you are interested in this feature request.

I apologise for my late reply as I had wrongly assumed this thread was dead and so I have not been checking it much recently.

I have tested as you requested to a point. My reason for not fully testing is that at the moment I only have a large 250GB drive available to wipe. I am sorry to say that I simply didn’t have the time to do an 8 pass wipe.

I wiped using the RCMP TSSIT OPS-II method but as I mentioned before I was using a 250GB drive which was taking an awfully long time. So I terminated the process to save time.

Unfortunately on inspection of the drive with a Hex editor I was disappointed to see that the drive had been filled with predictable patterns not random data.

I understand I did not allow the entire process to complete but I don’t believe this method will help with our plausible deniability assuming the last pass is similar to the previous 7.

Could I just mention my main concern with this feature request. I believe in order for plausible deniability for Truecrypt users to work or to be plausible enough I think that the use of either default settings or a common setting of DBAN should achieve the desired result. I have read many people suggesting using the random wipe and stopping the process before the zero pass wipe. Although this will leave the desired randomly filled drive it still requires user intervention to stop the normal completion of the DBAN process which is instantly less plausible.

In order for Truecrypt users to blend into the masses there needs to be non Truecrypt users with cryptographically randomly filled spare or wiped hard drives. In order for this to happen I believe that the option to leave the drive in this, our desired state, has to be attractive in some way for non Truecrypt users to choose it anyway. This is why I originally requested that you made the zero pass wipe an opt in rather than an opt out. This way a single random pass is attractive for non Truecrypt users as it is a secure fast single pass wipe without the time taken for the second zero pass currently carried out. 50% faster than at the moment. As demonstrated by my own tests I was too inpatient to wait for an 8 pass wipe of a 250GB drive and I am interested in this subject !

I fully understand that DBAN is mainly a drive wiper and is not there to help Truecrypt users. However I believe that many people ( Truecrypt users or not ) will appreciate the ability to halve the time taken to do a single pass random wipe by making the zero pass an option if not off by default.

As I have said before I am very grateful to you for providing DBAN it is the only disk wiper I trust and I am also very grateful for your interest in this feature request. Please still consider the zero pass on or off option in future releases of DBAN.

Thank you.

[Darik Horn]

Logged In: YES
user_id=560878

If somebody finds time to follow the suggestion, then post
the results here.

[Chubbypants]

Logged In: YES
user_id=1535795

Hi Darik.

I managed to borrow a 40 GB Seagate hard drive from a friend this weekend and I ran the full RCMP TSSIT wipe.

The first 7 passes do nothing for plausible deniability as they are all patterns.

The final 8th pass described as OPSII Final by DBAN does leave the drive filled with random data. I tested this data with DieHard and although it came close to failing a couple of times it actually passed and looked similar to a Truecrypt volume.

So you are right using the RCMP TSSIT wipe method could give plausible deniability to Truecrypt users. However should the user wish to make dummy or decoy drives they will have to wait for the full 8 passes before they can put the drive to one side.

I am wondering why you allow the RCMP TSSIT method to leave the users hard drive as expected (full of random data) and yet you have decided not to allow this with the normal random pass ? I remember you said it was because many people complained to you that their drive had not been wiped as they, for some reason, expected to see zeros after a random pass ! Has anyone complained about the RCMP method leaving random data ?

So, although your idea to use the RCMP method works I still hope you will consider adding the option to use the extra zero pass wipe after a random pass. This will allow the user to decide how many passes they wish to use to achieve the desired effect. I don’t know how difficult it would be for you to add the allow/deny zero wipe at end option but I hope you still will.

Just as a side note I used a Seagate Barracuda 7200.7 Model ST340014A for this last test. I noticed that DBAN didn’t wipe the boot sector. Not really a security problem I suppose but I always thought DBAN wiped the entire drive. I over wrote this area with WinHex and then did a wipe with DBAN. DBAN then worked and wrote data to this area. Could Seagate have protected this area from DBAN somehow ? As I said not really a problem I am just curious.

Thanks. :o)

[Anonymous]

I thought this behavior was pretty counter-intuitive. Shouldn't there at least be an explanation in the interface?