[ralferoo]

It's even easier to detect from that. From the project writeup Q&As: 'The firmware snoops for the string "password:xyz" and inhibits the write of "xyz". Otherwise, yes this would be very insecure.'

So detecting this drive is just a matter of writing "password:anything" to the drive, unmounting, remounting and checking the file you just wrote. If it's not what you wrote, then you have detected the existence of this drive.

The parent comment was correct that if this was mitigated by testing if the key is valid then you can detect it by checking for timing differences between writing a sector that starts "password:" and one that doesn't. Moving the password check async just means that you run the risk of having the real password written to the SD card before it was detected.

If you buffer that sector from being written, then you might be able to detect it because the write was faster than expected, or if you write the modified version and go back and overwrite it with the original if the check fails, then you will slow down a different subsequent access, again which would be detectable. This would also invalidate one of the design goals of never keeping the password in memory, only the derived key.

Having a customizable prefix is possible, as the project is open source. Personally, I'd be tempted to make this possible on the base build by storing the prefix in the hidden area of the SD card.

[LorenPechtel]

Simply dismounting it won't prevent the stored write. You would have to dismount and then quickly power down. The safe-to-remove indication on Windows takes at least that long.