-1

Assuming that I want to encrypt/decrypt a hard drive corresponding to /dev/sdX, the following is the procedure I have for doing so:

Encryption:

  1. Write the hard drive's data into a file (e.g. ./tmp), using the command dd if=/dev/sdX of=./tmp

  2. Encrypt the tmp file using any secure file encryption algorithm

  3. Write the encrypted tmp.enc into the hard drive (dd if=./tmp.enc of=/dev/sdX)

Decryption:

  1. Write the hard drive's data into a file (e.g. ./tmp), using the command dd if=/dev/sdX of=./tmp.enc

  2. Decrypt the tmp.enc file

  3. Write the decrypted tmp into the hard drive (dd if=./tmp of=/dev/sdX)

Does the following method necessarily work?

Improve this question
8
  • 1
    Encrypting the data likely makes the data larger (?), which means it wouldn’t fit on the original drive. This isn’t a real answer as I haven’t tested it to make sure it’s correct. Commented Jun 28 at 15:23
  • @Kusalananda Not that likely. You can open the /dev/sdX with plain dm-crypt and write ./tmp to the crypt. I think the bigger concern here is what "backs" ./. (And what the question is really about. Sounds like some sort of XYproblem or homework question tbh.) Commented Jun 28 at 15:29
  • @Kusalananda Since the data isn't too random, compression algorithms can significantly reduce the size of the tmp file. To encrypt, we can compress and then use the algorithm that only encrypts (and to decrypt, we use the algorithm that only decrypts and then decompress it), so we're dealing with something like tmp.gz.enc Commented Jun 28 at 15:51
  • 3
    @Kusalananda: Depends on whether the header (algorithm parameters) counts into the total size. The data itself doesn't grow by any amount, e.g. AES encrypts exactly one block to one block, it's only things like LUKS metadata or PGP metadata that cause the total to be larger. So if OP uses file-oriented tools like PGP then yes, it'll grow, whereas if they use e.g. "raw AES" or if they use LUKS with a detached header then no. Commented Jun 28 at 15:52
  • 1
    What is this "safe" of which you speak? Have you performed a Threat/Risk Assessment? What are you trying to protect? From whom? How much money/effort is practical? Commented Jun 28 at 19:36

1 Answer 1

Reset to default
2

No, for at least three reasons:

  1. Your compressed data is very unlikely to be the same size as your uncompressed data. If it adds headers, you will lose data at the end. If it compresses well, you will leave unencrypted data on the disk.
  2. You will require a work area that is at least twice the size of your hard disk.
  3. You will leave unencrypted data on your work area.
  4. If you want the media to go past hostiles, you should also securely erase the unencrypted data from media. shred from coreutils might do the job.
  5. Modern disks mean you probably can't securely delete the data.
Improve this answer
2
  • Many/most sensible drives support the ATA Secure Erase command(s), which might be more aware of the drive internals and might (or might not) be able to securely erase data that can't be overwritten by normal writes. Especially on SSDs, write balancing means running shred on a single files might not be too useful. Commented Jun 30 at 8:23
  • @ilkkachu bad block replacement also limits the usefulness of shred. These two issues are why I added item 5. Commented Jul 1 at 14:42

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.