Timeline for Is the following way of encrypting hard drive using file encryption safe?
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 30 at 8:21 | comment | added | ilkkachu | Anyway, instead of moving the data around as presented here, it might be smarter to just create an encrypted volume on the drive before putting any sensitive data there, and just access that normally. Or wrap the files in a tarball, encrypt that and copy it to the drive onto a normal filesystem. | |
| Jun 30 at 8:19 | comment | added | ilkkachu | @grawity, while it's true that the plain block ciphers don't change the data length, just encrypting the data one block at a time (ECB mode) would reveal which blocks or messages are identical, so proper encryption methods add some random data (an initialization vector, IV) to cover for that. Proper proper encryption methods also add an authentication tag. Both increase the amount of data. But yes, full-disk encryption usually doesn't bother with that for each block, so apart from the possibly detached header, the data size shouldn't change. | |
| Jun 29 at 14:16 | comment | added | Chris Davies | "Is the following way of encrypting hard drive using file encryption safe?" - safe in what context? Safe in that the instructions are accurate and reliable? Safe in that the data is suitably protected? Safe in that you won't get injured trying them? Safe in some other way? | |
| Jun 29 at 2:57 | answer | added | David G. | timeline score: 2 | |
| Jun 28 at 19:36 | comment | added | waltinator | 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? | |
| Jun 28 at 15:52 | comment | added | grawity | @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. | |
| Jun 28 at 15:51 | comment | added | sbh | @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 | |
| Jun 28 at 15:29 | comment | added | Tom Yan | @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.) | |
| Jun 28 at 15:23 | comment | added | Kusalananda♦ | 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. | |
| Jun 28 at 15:00 | history | asked | sbh | CC BY-SA 4.0 |