gmane.linux.kernel.device-mapper.dm-crypt

Re: typo in section 6.7 of faq

Arno Wagner — 2012-05-22T22:07:12

Thanks, fixed.

Arno

On Tue, May 22, 2012 at 09:57:34AM -0400, .. ink .. wrote:

Re: typo in section 6.1 of faq

Arno Wagner — 2012-05-22T22:04:52

Thanks, fixed.
 

You can take as much as you like!

You need to include a license statement like below with what you take:

"This is/contains an excerpt from the "Cryptsetup FAQ", which is under
 the "Attribution-Share Alike 3.0 Unported" license, which means 
 distribution is unlimited, you may create derived works, but 
 attributions to original authors and this license statement must 
 be retained and the derived work must be under the same license. 
 See http://creativecommons.org/licenses/by-sa/3.0/ for more details 
 of the license.

 Original Authors: Arno Wagner <arno-JoEyUyqlpX17tPAFqOLdPg< at >public.gmane.org>
                   Milan Broz
"

You can put this (admittedly unwieldly) license satement at the
end of your text. You can also copy the full FAQ and reference 
it in your own text.

Arno

typo in section 6.1 of faq

.. ink .. — 2012-05-22T16:25:21

second sentence of second paragraph has a misspelled word "occuurence"

also, will be ok if i could copy a paragraph or two from the faq for my project?
_______________________________________________
dm-crypt mailing list
dm-crypt-4q3lyFh4P1g< at >public.gmane.org
http://www.saout.de/mailman/listinfo/dm-crypt

typo in section 6.7 of faq

.. ink .. — 2012-05-22T13:57:34

last sentence of 4th paragraph reads "To prevent this, use a
filesystem level backup methid that encrypts the whole backup in one
go, e.g. as described above with tar and GnuPG",

"method" is misspelled "methid"
_______________________________________________
dm-crypt mailing list
dm-crypt-4q3lyFh4P1g< at >public.gmane.org
http://www.saout.de/mailman/listinfo/dm-crypt

Re: Brute force aes-plain

Kereoz — 2012-05-18T11:23:13

Hi,


I'll give it a go just in case (probably using the Debian snapshots to make sure
I reproduce the same behavior may it be different).
 

Good to know, I'll check this out. Reiser is fairly easy to recognize though (as
you can just grep the "reiser" string).
 

Perfect, this is exactly what I needed to know.
 

I'll have a look when I have some time and will let the list know if I get it to
work.

Thank you for your answer.

Re: Brute force aes-plain

Arno Wagner — 2012-05-17T07:27:28

Hi,

On Wed, May 16, 2012 at 07:03:40PM +0200, Kereoz wrote:

Not to my knowledge, no. The change is documented in FAQ item 8.1
(http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions(


Someone tried to brute-force an encoding issue a while back,
but that is not what you need.


You could just intsall that old release to be sure. Or maybe just
get the binary or source package and check that way. But AFAIK
Debian never changed anything from the package defaults, so these
two should be it.


That is actually relativly long. 


Well, yes.


Yes. There is a filesystem recognition linrary somewhere
(used by mount -t auto), that may also be helpful. 


Hmm. Use the password hashing from the c-sources of cryptsetup (it is a
bit more complicated than just direct hashing) and instead of doing
a mapping, use an external AES implementation (gcrypt, openssl, etc.)
to decrypt your test-data. Make sure to get the IV right. It should
be the sector number for "-plain".

I would suggest to make this work first wi

Brute force aes-plain

Kereoz — 2012-05-16T17:03:40

Hi all,

Quick story:
- are there any knows issues with plain dm-crypt volumes in Debian ? (Other than the
  default changing from aes-cbc-plain to aes-cbc-essiv ?)
- anyone here tried bruteforcing aes-cbc-plain (I got a rather short key) ? 

(Could you please CC me in the replies to this thread as I am not (yet ?) a
subscriber of this mailing list).

Long story:
I recently came back from a one year trip abroad, and got my hands back on an
encrypted hard drive I left there. I was pretty sure I knew the key for this
drive but after trying everything I could think about it is now sitting on my
desk until I find a solution. 

I don't know for sure whether I forgot the key or I am using the wrong
algorithm, as the version of cryptsetup I was using at the time was different
(different Debian release) and I read the defaults have changed. I am fairly
sure I used the '-c aes-plain' option initially but I had no luck with it. I
also tried aes-cbc-essiv and had no luck either. Is there anything else I could
try ?

No

Re: Writing Asynchronous Block Ciphers

Rodel Miguel — 2012-05-11T15:21:52

Thanks Milan!  I will ask around that mailing list.

On Fri, May 11, 2012 at 3:05 AM, Milan Broz <mbroz-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org> wrote:

_______________________________________________
dm-crypt mailing list
dm-crypt-4q3lyFh4P1g< at >public.gmane.org
http://www.saout.de/mailman/listinfo/dm-crypt

Re: Writing Asynchronous Block Ciphers

Milan Broz — 2012-05-11T07:05:15

This is question for linux-crypt mailing list,
http://vger.kernel.org/vger-lists.html#linux-crypto
actually, problems with mv_cesa are just dicsussed there...

Milan
_______________________________________________
dm-crypt mailing list
dm-crypt-4q3lyFh4P1g< at >public.gmane.org
http://www.saout.de/mailman/listinfo/dm-crypt

Writing Asynchronous Block Ciphers

Rodel Miguel — 2012-05-11T04:30:46

Hello,

I would like to know if anyone has a tutorial/document link in writing a
CRYPTO_ALG_TYPE_ABLKCIPHER crypto device driver?  I am looking at
drivers/cipher/mv_cesa.c but there are lots of things going on which are
hardware context related.  I would like to know what the minimum
requirements for an asynchronous block cipher drivers are before I hand
over (DMA) the collected data to my encryption hardware.

Thanks in advance for your help!

Kind Regards,
Rodel


 <http://lxr.free-electrons.com/ident?i=CRYPTO_ALG_TYPE_BLKCIPHER>
_______________________________________________
dm-crypt mailing list
dm-crypt-4q3lyFh4P1g< at >public.gmane.org
http://www.saout.de/mailman/listinfo/dm-crypt

Re: Encrypting swap

Milan Broz — 2012-05-10T20:30:47

Yes, you cannot use this for hibernation.

But default encrypted Fedora installation uses LUKS, which is suitable
for hibernation. (In fact it encrypts LVM PV, where both root and swap resides.)


Completely different problem. Fedora init ramdisk will ask for password,
then resumes from hibernation. No passphrase is stored on disk...

Take F16 install DVD, check "encrypt system" in the first screen for
new installation.
That's all you need to make it work.

Milan
_______________________________________________
dm-crypt mailing list
dm-crypt-4q3lyFh4P1g< at >public.gmane.org
http://www.saout.de/mailman/listinfo/dm-crypt

Encrypting swap

Konstantin Svist — 2012-05-10T19:50:30

Hi,

I'm setting up Fedora 16 i686 with [luks] encrypted root on a laptop.

Problem is, I can't seem to find a way to encrypt the swap so that it 
would be usable for hibernation.

* Simple setup for encrypting swap uses a random key generated on each 
boot, so resuming doesn't work.
* Using the same key for swap & root is not recommended because some 
tool caches the password, making the whole thing meaningless [1]
* Using a swap file doesn't work because btrfs is Copy-On-Write, so the 
filesystem may get messed up by hibernate/resume process.

I'm not sure if the "same key" problem exists in Fedora 16, I've tried 
setting it up this way and I'm able to boot but not resume.

Any help appreciated!



[1] 
https://wiki.archlinux.org/index.php/Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure 





_______________________________________________
dm-crypt mailing list
dm-crypt-4q3lyFh4P1g< at >public.gmane.org
http://www.saout.de/mailman/listinfo/dm-crypt

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

.. ink .. — 2012-05-09T04:04:05

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

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.


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 aga

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

Arno Wagner — 2012-05-09T00:19:10

Ok, clear now.


So, but dm-crypt encrypts in 512 Byte blocks, and reinitializes
the mode for each such block, while file encryption initializes
the mode at the start and then runs it over the whole file.

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. 

File encryption does ensure integrity. Or rather it dramatically 
amplifies any changes introduced by an attacker. In filesystem
encryption, any amplification is limited to one block.

Hmm. Come to think of it, intrgrity could probably 
be ensured with a crypto-hash being added to the file in
your scenario. In fact that is what is usually done in
file encryption, even with the error amplification. 

But the point is that file encryption is already solved and
actually easier than disk encryption. Retrofitting disk
encryption to ad

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

.. ink .. — 2012-05-08T23:41:34

talking about encrypted volumes. When creating encrypted volumes in files,I
first create a container file,open a mapper against it and then put a file
system through the mapper and hence it is file system encryption,not file
encyption.

What are the problems of using cryptsetup specifically or aes-cbc in
general to do file encryption?

The encrypted file(in my case atleast) is not meant to be changed,it is
effectively "read only" cipher text file. If change need to be made,the
file will first have to be decrypted by creating a copy of the file in
plain text,then edit the file, then create another read only copy of the
file in cipher text.
_______________________________________________
dm-crypt mailing list
dm-crypt-4q3lyFh4P1g< at >public.gmane.org
http://www.saout.de/mailman/listinfo/dm-crypt

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

Arno Wagner — 2012-05-08T22:26:05

Ah. But that is competely different from encrypting a file with
GnuPG. If you encrypt a file with GnuPG, you cannot change any
part without all later blocks becomming unreadable. That is what 
the CFB mode used does. This is a massive gain in security, 
but of course completely unusable to encrypt anything that 
has a filesystem in it that is written to.

If you just put an encrypted filesystem in a file, that is 
basically described in FAQ item 2.3. Is that what you are 
doing? But that is not file encryption. That is still 
filesystem encryption with all its limitations compared to
file encryption, but the advantage that you can change sectors
without influencing others.

As to "static encrypted strings" in the second case, do not worry.
The filesystem already puts plenty of them in there. In fact,
trying a "mount" is a pretty reliable way of determining whether
the right key was used in decryption.

Arno

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

.. ink .. — 2012-05-08T22:05:30

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.


not an approach i want to take if alternatives exist.



one doesnt exist.


something known in a particular position in the encrypted file is an
unnecessary risk.



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
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.
_______________________________________________
dm-crypt mailing list
dm-crypt-4q3lyFh4P1g< at >public.gmane.org
http://www.saout.de/mailman/listinfo/dm-crypt

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

.. ink .. — 2012-05-08T21:24:06

you seem to have understood my problem and your suggestions will work.

With the current implementation, only the header gets decrypted and then
the key is checked, if it is seen to be correct, then payload get decrypted.

With storing hash of the original file and compare them, i will first have
to decrypt the load,get the hash of the decrypted load,decrypt the header,
get the has from the header and then compare them, its doable.

Hashing the passphrase is a modification of my of original idea, its also
doable
.
Thanks for the suggestion
_______________________________________________
dm-crypt mailing list
dm-crypt-4q3lyFh4P1g< at >public.gmane.org
http://www.saout.de/mailman/listinfo/dm-crypt

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

Timothy Rice — 2012-05-08T20:56:47

I apologise in advance if I've misunderstood your question in any way. It
occurs to me that using hashes could be a good idea? You could either use a
hash of (at least part of) the file itself, or you could use a hash of the
passphrase?

_______________________________________________
dm-crypt mailing list
dm-crypt-4q3lyFh4P1g< at >public.gmane.org
http://www.saout.de/mailman/listinfo/dm-crypt

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

Arno Wagner — 2012-05-08T21:17:40

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:

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. 
 


There is a tiny residual risk, my guess would be 1 in 2^400.
Small enought no not matter in this universe ;-)
 

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.
 

Your approach is too comp

encryption of single files using cryptsetup ala gpg -c

.. ink .. — 2012-05-08T20:28:22

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?

One sol