Re: encryption of single files using cryptsetup ala gpg -c

[".. ink .." <mhogomchungu@xxxxxxxxx>]

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 to do.

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.

i can.
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 unmounting stages.

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 file.

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 abusive

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.

_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt