[dm-crypt] encryption of single files using cryptsetup ala gpg -c
arno at wagner.name
Tue May 8 23:17:40 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...
On Tue, May 08, 2012 at 04:28:22PM -0400, .. ink .. wrote:
> most people( according to google search ) seem to use gpg command to
> encrypt a single file in linux with a passphrase.
> I just added the ability to encrypt a single file like gpg in zulucrypt
> using cryptsetup,currently in plain format.
> The current implementation adds a 512 byte header to the encrypted file to
> store information about the plain data length to work around padding issues
> if the data that is to be encrypted is not a multiple of 512. The header is
> also encrypted with the load so the only way to read the header is to first
> decrypt the encrypted file with the correct passphrase.
> Like somebody said in one of the previous discussions on plain volumes,the
> only way to know a correct passphrase was used when decrypting a plain
> volume is to check in the decrypted data for something that is known to be
> there from the original data.
> The question i am asking is, is it possible to write some information in
> the header in a way that will tell me the decrypting key is the same as the
> encrypting key?
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.
My guess is the residual risk of it happening is at the very
least 1 in 2^64, small enough to not matter.
With a static magic string, you have a slight risk as this
allows a known plaintext attack on the key. Should not be a
concern though for any non-broken cipher if you use
ESSIV or XTS mode.
> 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 ;-)
> 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.
> 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.
> 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. Your approach allows comparison
of differences between two files encrypted with the same key
for example. Normal file-encryption prevents that.
> The current implementation can is at:
> dm-crypt mailing list
> dm-crypt at saout.de
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno at wagner.name
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
One of the painful things about our time is that those who feel certainty
are stupid, and those with any imagination and understanding are filled
with doubt and indecision. -- Bertrand Russell
More information about the dm-crypt