[dm-crypt] encryption of single files using cryptsetup ala gpg -c

.. ink .. mhogomchungu at gmail.com
Wed May 9 00:05:30 CEST 2012

> first, let me say that you are horribly abusing cryptsetup here,
> with, I am sure, all kinds of repercussions that will come to haunt
> you. That said...
> can you expand on this? It seem the most logical step to take after what i
already have.
zulucrypt can create encrypted volumes in files,same as truecrypt. It first
creates a file,put a file system in it and then encrypt the file. how does
truecrypt create encrypted volumes in files?

All i seem to be doing is skipping a step,the file system creation step.

> Just use any magic string that is longer than or as long as
> two cipher blocks. For example "zulucrypt in file mode was
> used" is 256 bit and will not show up in practice with a wrong
> key for a 128 bit blocksize cipher such as AES.
> I want to avoid writing the same string to all encrypted files. This is
not an approach i want to take if alternatives exist.

> > One solution i came up with is to write the same random 100 byte data
> read
> > from "/dev/urandom" to offse 100t and offset 200 when encrypting the
> file.
> > One decryption,the these two offsets are memcmp and an assumption is made
> > that the key is the same if they match. Will this work? With plain
> volumes,
> > if two chunks of 100 bytes are known to be the same at encryption. Will
> tey
> > always be different if decryption is done with a different key?
> There is a tiny residual risk, my guess would be 1 in 2^400.
> Small enought no not matter in this universe ;-)
> So,this is an acceptable solution?

> > Another solution is to write the first 100 bytes of the key in the header
> > at a specified offset and then compare ithe offset against the key used
> in
> > decryption. If they match,then an assumption is made that the decryption
> > keys are the same since there is recognizable pattern.
> Do not do that. Encryption a key with a cipher using that key is
> a bad idea. Also you could end up with key material on disk.
> So this is a bad idea,will move away from it to the above one if a better
one doesnt exist.

> > can somebody come with a better solution?
> Your approach is too complicated. A more secure alternative to the
> static string would be something like put in some random bits
> (say 256) and the magic string afterwards. CBC or XTS mode would
> then prevent a known plaintext attack.
> Both my original ideas did not involve using a static string as having
something known in a particular position in the encrypted file is an
unnecessary risk.

> I already store plain text data load length in the header and i know the
> > encrypted file will be larger that plain text file by a number >= 512
> and <
> > 1024. I can use this knowledge to check if the decryption key is correct
> > but i am looking for a more "standardized way".
> The standardized way is to use a file-encryption program like
> GnuPG. It can CBC over the whole file, instead of limiting
> its effects to single sectors.

My approach does the same, the whole file is encrypted and decrypted as a
whole,the payload start at offset 512 bytes,the first 512 bytes is the
header. To get to the header,i just access the first 512 bytes of the whole
encrypted file.

Your approach allows comparison
> of differences between two files encrypted with the same key
> for example. Normal file-encryption prevents that.
> I didnt get this part but i suspect it came from the suggestion of using
the same string in all headers.That was not my idea and if i will get it my
way,two headers will always be different.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.saout.de/pipermail/dm-crypt/attachments/20120508/c6a28333/attachment-0001.html>

More information about the dm-crypt mailing list