[dm-crypt] encryption of single files using cryptsetup ala gpg -c
.. ink ..
mhogomchungu at gmail.com
Wed May 9 06:04:05 CEST 2012
> I do not quite see why you could not change any 512 byte block
> in-place. Of course you would either need the key or a block from
> a previous version with the same key. But that is one of the
> problems of filesystem encryption, it does not ensure overall
> integrity and it cannot.
> Its possible to do that,I just dont because it does not make sense in my
use case. The tool is about making a copy of a plain text file in cipher
text. Editing cipher text "in place" is against what the tool is supposed
strikes me as fundamentally wrong. Use the original thing
> And GnuPG in symmetrical mode already does that,
> no hassle, no hoops. In addition, you get the whole
> public-key functionality for free if you want it.
> You dont seem to have that much faith in block device encryption :-)
You will also not have all those goodies in file encryption(as they are
presented in gnupg) if a file that is to be kept private is in a luks based
encrypted hard drive. So,the kind of protection i will be giving should be
comparable to file system encryption.
If what i am doing is not secure enough, then block device encryption is
also not secure enough in general.
> So, while I applaud your inventiveness, I stand by my
> statement that this is a horrible abuse of cryptsetup
> and dm-crypt and not a good idea.
> Maybe i should reexplain what i am doing, maybe i did not explain myself
properly the first time or finer distinctions were not pointed out the
first time around.
Problem, i have a file i was to protect using cryptsetup.
1. get a hard drive
2. open a mapper against it
3. put a file system on the drive though the mapper
4. mount the file system
5. copy the file over
6. unmount the file system
7. close the mapper.
In files, what is in below happens.
1. create a file
2. create a loop device against it.
3. open the mapper against the loop device.
4. put a file system on the file through the mapper
5. mount the file system
6. copy the file over
7. unmount the file system
8. close the mapper.
Now,what i am trying to do is skipping the file system creation step and
write straight to the underlying device to remove the mounting and
lets say somebody wants to encrypt a 20 byte file. This is what will happen
with my file encryption implementation.
1. a container file large enough to hold the load padded to 512 byte block
+ 512 byte block for the header will be created.This means a 1024 byte file
will be created in this case.
2. a mapper will be opened against the container file.
3. The header will be written to the container file through the mapper.
4. the load will be written to the container file through the mapper.
5. mapper will be closed.
To decrypt the file:
1.a mapper will be opened against the container file.
2. 512 bytes will be read to see how big the load is
3. read the load from the container through the mapper and dump it to a
The only thing i am doing with my file encyption is not putting a file
system in the container file allowing skipping of mounting steps giving a
more seemless experience if only a single file is meant to be protected.
Its a plain container type,you give wrong key, you get garbage
data,standard behavior,deviating from standard behavior should be what is
My cocern necessitating making sure the decryption key is the same as
encryption key is so that i dont read garbage header and have my loops go
belly up.The rest is for user convenience.
cryptsetup does not tell you if the load was tampered with,it does not give
you compression,it does not give you integrity checks.Not giving these
features is using cryptsetup as intended,
If users expects these features when encrying their stand alone files then
i will add proper warnings to inform them of to expect.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dm-crypt