(More) Specifics:

  • Undoing the protection should include filling in a password.
  • The password should be different from the one used with sudo or any other passwords that are used for acquiring elevated privileges.

All (possible) solutions and suggestions are welcome! Thanks in advance!

Edit: Perhaps additional specifications:

  • With 'displace‘, I mean anything involving that resembles the result of mv, cp (move, cut, copy) or whatsoever. The files should remain in their previously assigned locations/places and should not be able to 'pop up' anywhere.
  • I require for the files to be unreadable.
  • I don't care if it's modifiable or not.
  • I don't require this for my whole system! Only for a specific set of files.
  • poki@discuss.online
    ·
    5 months ago

    Someone without the password but with permission to modify the file will be capable of corrupting it (which would prevent you from accessing every protected file), but unless they somehow got access to the password they wouldn’t be able to view or modify the protected files.

    Is it possible to force a corruption if a disk clone is attempted?

    • hedgehog@ttrpg.network
      ·
      5 months ago

      Is it possible to force a corruption if a disk clone is attempted?

      Anything that corrupts a single file would work. You could certainly change your own disk cloning binaries to include such functionality, but if someone were accessing your data directly via their own OS, that wouldn’t be effective. I don’t know of a way to circumvent that last part other than ensuring that the data isn’t left on disk when you’re done. For example, you could use a ramdisk instead of non-volatile storage. You could delete or intentionally corrupt the volume when you unmount it. You could split the file, storing half on your USB flash drive and keeping the other half on your PC. You could XOR the file with contents of another file (e.g., one on your USB flash drive instead of on your PC) and then XOR it again when you need to access it.

      What sort of attack are you trying to protect from here?

      If the goal is plausible deniability, then it’s worth noting that VeraCrypt volumes aren’t identifiable as distinct from random data. So if you have a valid reason for having a big block of random data on disk, you could say that’s what the file was. Random files are useful because they are not compressible. For example, you could be using those files to test: network/storage media performance or compression/hash/backup&restore/encrypt&decrypt functions. You could be using them to have a repeatable set of random values to use in a program (like using a seed, but without necessarily being limited to using a PRNG to generate the sequence).

      If that’s not sufficient, you should look into hidden volumes. The idea is that you take a regular encrypted volume, whose free space, on disk, looks just like random data, you store your hidden volume within the free space. The hidden volume gets its own password. Then, you can mount the volume using the first password and get visibility into a “decoy” set of files or use the second password to view your “hidden” files. Note that when mounting it to view the decoy files, any write operations will have a chance of corrupting the hidden files. However, you can supply both passwords to mount it in a protected mode, allowing you to change the decoy files and avoid corrupting the hidden ones.