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.
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.
There is a tiny residual risk, my guess would be 1 in 2^400.
> 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?
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 headerDo not do that. Encryption a key with a cipher using that key is
> 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.
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 theThe standardized way is to use a file-encryption program like
> 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".
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 comparisonI 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.
of differences between two files encrypted with the same key
for example. Normal file-encryption prevents that.
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
