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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

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.

Arno





 
> The current implementation can is at:
> http://code.google.com/p/zulucrypt/source/browse/zuluCrypt-cli/lib/file_encryption.c



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


-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx 
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 
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt


[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux