dm-crypt Digest, Vol 66, Issue 20

dm-crypt Stephen 1 participant 1 message Dec 31, 2014 1 message not in the archive

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Stephen

author

2014-12-31 20:18 UTC #1 lore raw

Quoted 436 lines · On Dec 31, 2014, at 4:00 AM, [email protected] wrote:

Send dm-crypt mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.saout.de/mailman/listinfo/dm-crypt
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific than "Re: Contents of dm-crypt digest..."
Today's Topics:
1. unsafe??? use of memset (.. ink ..)
2. Re: unsafe??? use of memset (Milan Broz)
3. Re: unsafe??? use of memset (Arno Wagner)
4. Re: unsafe??? use of memset (Arno Wagner)
5. Re: Asustor NAS and cryptsetup 1.6.1 ([email protected])
6. Re: Asustor NAS and cryptsetup 1.6.1 (Sven Eschenberg)
7. Re: Asustor NAS and cryptsetup 1.6.1 (Arno Wagner)
----------------------------------------------------------------------
Message: 1
Date: Tue, 30 Dec 2014 16:57:56 +0300
From: ".. ink .." <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [dm-crypt] unsafe??? use of memset
Message-ID:
<CAFnMBaQZp63DCZB9f9K1tPia237OGWjVQ6c2oYM7VNSDWqk_Vw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
a lot of people like this one[2] advises against the use of memset to clear memory but crypsetup seems to
ignore this advice and use memset a lot like in[1].
Any reason why cryptseup is ignoring this advice?
[1]
https://code.google.com/p/cryptsetup/source/browse/lib/tcrypt/tcrypt.c#272
[2]
http://edc.tversu.ru/elib/inf/0088/0596003943_secureprgckbk-chp-13-sect-2.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.saout.de/pipermail/dm-crypt/attachments/20141230/bac6fac1/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 30 Dec 2014 15:26:02 +0100
From: Milan Broz <[email protected]>
To: ".. ink .." <[email protected]>, "[email protected]"
	<[email protected]>
Subject: Re: [dm-crypt] unsafe??? use of memset
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Quoted 5 lines · .. ink ..
a lot of people like this one[2] advises against the use of memset to clear memory but crypsetup seems to ignore this advice and use memset a lot like in[1].
Any reason why cryptseup is ignoring this advice?
Why ignore? It worked with old compilers (and VC is not the issue here).
This is opensource, so I usually respond with "send a patch" to these messages...
But actually I have patch for that for weeks. I have just another issues which have unfortunately much higher priority in my life and I am not going commit half-baked patch.
FYI:
I fixed it is kernel dmcrypt, there we can use memzero_explicit()
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/md/dm-crypt.c?id=1a71d6ffe18c0d0f03fc8531949cc8ed41d702ee
Cryptsetup will follow (hopefully soon with other fixes).
And it is nothing critical.
There is a nice description of problem
https://cryptocoding.net/index.php/Coding_rules#Prevent_compiler_interference_with_security-critical_operations
Actually I want to replace zero memset with zero it with code used in BLAKE2. It is simple and should work.
static inline void secure_zero_memory(void *v, size_t n) {
volatile uint8_t *p = (volatile uint8_t *)v; while(n--) *p++ = 0;
}
Milan
Quoted 3 lines
[1] https://code.google.com/p/cryptsetup/source/browse/lib/tcrypt/tcrypt.c#272
[2] http://edc.tversu.ru/elib/inf/0088/0596003943_secureprgckbk-chp-13-sect-2.html
------------------------------
Message: 3
Date: Tue, 30 Dec 2014 17:38:14 +0100
From: Arno Wagner <[email protected]>
To: [email protected]
Subject: Re: [dm-crypt] unsafe??? use of memset
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Interesting question. I think it is not relevant for most Linux scenarios, as memset() comes precompiled as part of a binary library, and the compiler has no clue what it does and hence cannot optimize it away.
If memset is compiled together with the code using it, this would be a problem, but also one anybody writing secure code should be aware of. I am not aware of any normal Linux scenarios where that could happen.
Still, soemthing low-priority to fix eventually, as it cannot be ruled out that it may some day be compiled in a dangerous fashion or memset() may be made a macro or some other bizarre circumstances.
BTW, with GCC, there is also the possibility to locally prohibit optimization with something like:
#pragma GCC push_options
#pragma GCC optimize ("O0")
code
#pragma GCC pop_options
I needed that some time ago, but do not remember for what.
Anyways, this is an area where recipes do not cut it. For secure code you have to understand how it gets compiled on the specific target platform and what the issues there are.
Arno
Quoted 15 lines · .. ink ..
a lot of people like this one[2] advises against the use of memset to clear memory but crypsetup seems to
ignore this advice and use memset a lot like in[1].
Any reason why cryptseup is ignoring this advice?
[1]
https://code.google.com/p/cryptsetup/source/browse/lib/tcrypt/tcrypt.c#272
[2]
http://edc.tversu.ru/elib/inf/0088/0596003943_secureprgckbk-chp-13-sect-2.html
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Signature · 18 lines
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: [email protected]
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier


------------------------------

Message: 4
Date: Tue, 30 Dec 2014 17:47:21 +0100
From: Arno Wagner <[email protected]>
To: [email protected]
Subject: Re: [dm-crypt] unsafe??? use of memset
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Quoted 18 lines · Milan Broz
Quoted 5 lines · .. ink ..
a lot of people like this one[2] advises against the use of memset to clear memory but crypsetup seems to ignore this advice and use memset a lot like in[1].
Any reason why cryptseup is ignoring this advice?
Why ignore? It worked with old compilers (and VC is not the issue here).
This is opensource, so I usually respond with "send a patch" to these messages...
But actually I have patch for that for weeks. I have just another issues which have unfortunately much higher priority in my life and I am not going commit half-baked patch.
FYI:
I fixed it is kernel dmcrypt, there we can use memzero_explicit()
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/md/dm-crypt.c?id=1a71d6ffe18c0d0f03fc8531949cc8ed41d702ee
Quoted 6 lines
Cryptsetup will follow (hopefully soon with other fixes).
And it is nothing critical.
There is a nice description of problem
https://cryptocoding.net/index.php/Coding_rules#Prevent_compiler_interference_with_security-critical_operations
Interessting! So the problem is that memset() may not even be called. That would be bad. In that case the compiler would need to know that there are no volatile variables used inside memset(), which again, I think it should not be able to on Linux as gcc does not look at the libraries before linking. Apparently MS Visual C++ 2010 knows more about the libraries than is good for it.
My take would be that this is a legal optimization (with regard to the C standard), but one that needs some hidden special treatment of memset(). Of course I could be wrong.
Arno
Quoted 18 lines
Actually I want to replace zero memset with zero it with code used in BLAKE2. It is simple and should work.
static inline void secure_zero_memory(void *v, size_t n) {
volatile uint8_t *p = (volatile uint8_t *)v; while(n--) *p++ = 0;
}
Milan
Quoted 3 lines
[1] https://code.google.com/p/cryptsetup/source/browse/lib/tcrypt/tcrypt.c#272
[2] http://edc.tversu.ru/elib/inf/0088/0596003943_secureprgckbk-chp-13-sect-2.html
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Signature · 25 lines
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: [email protected]
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier


------------------------------

Message: 5
Date: Tue, 30 Dec 2014 10:18:38 -0800
From: "[email protected]" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [dm-crypt] Asustor NAS and cryptsetup 1.6.1
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed

They are reluctant to give out any details, but are saying that they 
will be releasing a new version of their software in the coming weeks 
that uses ecryptfs instead.
Is this a step forward or backward (or rather just "sideways")?

Mark
Quoted 12 lines · Arno Wagner
Quoted 11 lines · On Tue, Dec 30, 2014 at 03:32:58 CET, [email protected] wrote:
Quoted 10 lines · Quentin Lefebvre
Quoted 5 lines · On 29/12/2014 20:06, [email protected] wrote :
Assuming I did create the container with aes-cbc-essiv:sha256; would cryptsetup automatically figure out the correct parameters when it is subsequently called without those parameters to mount the container? Or do non-default parameters at creation time require the same non-default parameters again for subsequent mounts?
As you may have understood, in plain mode, there is no header, so no way for cryptsetup to guess the algorithm used. Thus, if it is a non-default one, it must be specified also at mount time.
Quoted 8 lines
Quoted 4 lines
Hm, makes sense. Is there some kind of a config file that I could specify the parameters in, and that would be read prior to using the defaults - similar to how some parameters for mount can be specified in /etc/fstab ?
Only if the NAS-makers added one. cryptsetup does not have a mechanism for this.
Arno
------------------------------
Message: 6
Date: Tue, 30 Dec 2014 20:16:48 +0100
From: "Sven Eschenberg" <[email protected]>
To: [email protected]
Subject: Re: [dm-crypt] Asustor NAS and cryptsetup 1.6.1 Message-ID:
	<[email protected]>
Content-Type: text/plain;charset=utf-8
Hummm, good question.
I think backwards. ecryptfs basicly does a per file encryption. So you'll have a normal filesystem which holds encrypted files. The downside is bad performance as it uses FUSE, it potentiolly discloses the structure of the filesystem (while filenames are scrambled the tree structure is visible). It is easier to backup as you can easily backup the encrypted files and do not need to dump the whole block device. (The price for this is disclosing the fs structure)
Regards
-Sven
Quoted 27 lines · On Tue, December 30, 2014 19:18, [email protected] wrote:
They are reluctant to give out any details, but are saying that they will be releasing a new version of their software in the coming weeks that uses ecryptfs instead.
Is this a step forward or backward (or rather just "sideways")?
Mark
Quoted 19 lines · Arno Wagner
Quoted 7 lines · On Tue, Dec 30, 2014 at 03:32:58 CET, [email protected] wrote:
Quoted 6 lines · Quentin Lefebvre
Quoted 5 lines · On 29/12/2014 20:06, [email protected] wrote :
Assuming I did create the container with aes-cbc-essiv:sha256; would cryptsetup automatically figure out the correct parameters when it is subsequently called without those parameters to mount the container? Or do non-default parameters at creation time require the same non-default parameters again for subsequent mounts?
Quoted 8 lines
Quoted 4 lines
As you may have understood, in plain mode, there is no header, so no way for cryptsetup to guess the algorithm used. Thus, if it is a non-default one, it must be specified also at mount time.
Hm, makes sense. Is there some kind of a config file that I could specify the parameters in, and that would be read prior to using the defaults - similar to how some parameters for mount can be specified in /etc/fstab ?
Only if the NAS-makers added one. cryptsetup does not have a mechanism for this.
Quoted 7 lines
Quoted 1 line
Arno
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
------------------------------
Message: 7
Date: Wed, 31 Dec 2014 08:26:39 +0100
From: Arno Wagner <[email protected]>
To: [email protected]
Subject: Re: [dm-crypt] Asustor NAS and cryptsetup 1.6.1
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
ecryptfs leaks a lot of data like filenames, sizes, modifiaction times, etc. These can be critical. For example, sometimes file-sizes are misused as "fingerprints".
I would say definitely backwards security-wise, for possibly some better usability.
Arno
Quoted 33 lines · On Tue, Dec 30, 2014 at 19:18:38 CET, [email protected] wrote:
They are reluctant to give out any details, but are saying that they will be releasing a new version of their software in the coming weeks that uses ecryptfs instead.
Is this a step forward or backward (or rather just "sideways")?
Mark
Quoted 12 lines · Arno Wagner
Quoted 11 lines · On Tue, Dec 30, 2014 at 03:32:58 CET, [email protected] wrote:
Quoted 10 lines · Quentin Lefebvre
Quoted 5 lines · On 29/12/2014 20:06, [email protected] wrote :
Assuming I did create the container with aes-cbc-essiv:sha256; would cryptsetup automatically figure out the correct parameters when it is subsequently called without those parameters to mount the container? Or do non-default parameters at creation time require the same non-default parameters again for subsequent mounts?
As you may have understood, in plain mode, there is no header, so no way for cryptsetup to guess the algorithm used. Thus, if it is a non-default one, it must be specified also at mount time.
Quoted 8 lines
Quoted 4 lines
Hm, makes sense. Is there some kind of a config file that I could specify the parameters in, and that would be read prior to using the defaults - similar to how some parameters for mount can be specified in /etc/fstab ?
Only if the NAS-makers added one. cryptsetup does not have a mechanism for this.
Arno
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Signature · 23 lines
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: [email protected]
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier


------------------------------

Subject: Digest Footer

_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt


------------------------------

End of dm-crypt Digest, Vol 66, Issue 20
****************************************