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

Re: linux luks automatic boot with keyfile (INSECURE)

Hp — 2012-05-25T09:37:47

Hi,
You may want look into using TPM and trusted-grub.
This allows you to bind a key to the physical device, and then only that
device can mount/decrypt the disk. (I never done this myself no idea how
hard or easy this is, neither I know how secure this really is. And
well, as it is physically bound to a system, you have to have a real
system, no VM and transfer it to other Hardware is not easy too)

Additional, you have to be careful to secure your OS while it runs (eg,
make it impossible to gain root, secure everything from the
user....thats no easy task, maybe even impossible with current OSes)

Imho, you should try not go this road. As with a lot of systems, you
have to think about every possible way to compromise the system (you
most likely will forget one), but the attacker has only to find ONE way
to break it. Just not worth the effort.


Depending on your requirements, you may want think about hosting the
software at a trusted location, and have your users use it remotely.

Or drop the technical solution in favor of a legal solutions. publish
your source, so you have prove of ownership and release date (or use
another way to make sure your code will be recognized as yours by a
court afterwards).
Have your software "pone home" and get a laywer. Make it clear you WILL
go to court. Most companies fear lawyers much more than nerds. Breaking
technical things seems to be a "gentlemen offence", breaking legal
things is considered "expensive".
On 25.05.2012 04:29, Nuno Reis wrote:

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

Re: linux luks automatic boot with keyfile (INSECURE)

Arno Wagner — 2012-05-25T08:11:49

Hi,

encryption is not your solution here. Basically, you can do some 
kind of obfuscation or DRM, but they are all relatively easy to 
break. There really is no good solution for this, although
a lot of people are unable to understand that fact.

My advice is to do without protection. Software will always be
easy to copy. 

Arno


On Fri, May 25, 2012 at 03:29:14AM +0100, Nuno Reis wrote:

Re: linux luks automatic boot with keyfile (INSECURE)

David Christensen — 2012-05-25T06:20:18

If you want to protect software, perhaps you should consider a software 
protection dongle:

     http://en.wikipedia.org/wiki/Software_protection_dongle


HTH,

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

linux luks automatic boot with keyfile (INSECURE)

Nuno Reis — 2012-05-25T02:29:14

Good morning.

I would like to ask you about the best choice to have one or two luks
encrypted partitions to boot automatically between reboots without me to
enter a pass-phrase.
I've made this already, but the way i'm doing it seems to be not very
secure since the keyfile is referenced in /etc/crypttab and the keyfile and
/etc/crypttab both reside on an unencrypted partition. If someone clones my
HDD and connect it to some other system will easily be able to mount the
unencrypted partitions and find the keyfile reference on /etc/crypttab to
get the keyfile and unencrypt the protected partitions right?
So basically my problem is that i want to sell a linux server with some
software i've developed to a datacenter (as an appliance), but i don't want
them to get to my software easily and i can't have a password prompt
between reboots also.
Can you point me out what you think would be the best solution for me?
Thanks.

BR,
Nuno.
_______________________________________________
dm-crypt mailing list
dm-crypt-4q3lyFh4P1g< at >public.gmane.org
http://www.saout.de/mailman/listinfo/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 with generated test-data. (New
volume, new FS, key e.g. "abc"), and when that works then try
it on you actual data. May take a few days of programming though.

Arno

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 ?

Now, in the case I just forgot the key, it wasn't very long anyway (~ 10
characters) and I got some ideas about the characters it might contain.
Considering that most chances are that the algorithm is aes-cbc-plain, it is
probably possible. I tried writing a script for this, but there are several
issues :
- cryptsetup takes a while to create a devmapper mapping
- trying to mount the partition also takes a while
- cryptsetup then takes a while to delete the devmapper mapping

When you put that together, it is definitely too slow to bruteforce anything.

Is there anything faster I could use here ? I assume the best solution would be
to extract a couple of blocks from the hard drive, those containing the
filesystem superblock, decrypt it and then try to match the filesystem magic
number (reiser). I don't know how to do the decryption part quick enough for a
brute-force approch. Any suggestion would be appreciated.

Regards,
Kereoz

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

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 against it.
3. open the mapper against the loop device.
4. put a file system on the file through the mapper
5. mount the file system
6. copy the file over
7. unmount the file system
8. close the mapper.

Now,what i am trying to do is skipping the file system creation step and
write straight to the underlying device to remove the mounting and
unmounting stages.

lets say somebody wants to encrypt a 20 byte file. This is what will happen
with my file encryption implementation.

1. a container file large enough to hold the load padded to 512 byte block
+ 512 byte block for the header will be created.This means a 1024 byte file
will be created in this case.
2. a mapper will be opened against the container file.
3. The header will be written to the container file through the mapper.
4. the load will be written to the container file through the mapper.
5. mapper will be closed.

To decrypt the file:
1.a mapper will be opened against the container file.
2. 512 bytes will be read to see how big the load is
3. read the load from the container through the mapper and dump it to a
file.

The only thing i am doing with my file encyption is not putting a file
system in the container file allowing skipping of mounting steps giving a
more seemless experience if only a single file is meant to be protected.

Its a plain container type,you give wrong key, you get garbage
data,standard behavior,deviating from standard behavior should be what is
abusive

My cocern necessitating making sure the decryption key is the same as
encryption key is so that i dont read garbage header and have my loops go
belly up.The rest is for user convenience.

cryptsetup does not tell you if the load was tampered with,it does not give
you compression,it does not give you integrity checks.Not giving these
features is using cryptsetup as intended,

If users expects these features when encrying their stand alone files then
i will add proper warnings to inform them of to expect.
_______________________________________________
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-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 add features that were removed because it
needs to fit the usage profile of disk encryption
strikes me as fundamentally wrong. Use the original thing
instead. And GnuPG in symmetrical mode already does that,
no hassle, no hoops. In addition, you get the whole 
public-key functionality for free if you want it.

So, while I applaud your inventiveness, I stand by my
statement that this is a horrible abuse of cryptsetup 
and dm-crypt and not a good idea. 

Arno

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