Skip to main content
Unix & Linux

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

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