[dm-crypt] dm-crypt Digest, Vol 66, Issue 20

Stephen smzboise at gmail.com
Wed Dec 31 21:18:23 CET 2014


On Dec 31, 2014, at 4:00 AM, dm-crypt-request at saout.de wrote:

> Send dm-crypt mailing list submissions to
> 	dm-crypt at saout.de
> 
> 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
> 	dm-crypt-request at saout.de
> 
> You can reach the person managing the list at
> 	dm-crypt-owner at saout.de
> 
> 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 (msalists at gmx.net)
>   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 .." <mhogomchungu at gmail.com>
> To: "dm-crypt at saout.de" <dm-crypt at saout.de>
> Subject: [dm-crypt] unsafe??? use of memset
> Message-ID:
> 	<CAFnMBaQZp63DCZB9f9K1tPia237OGWjVQ6c2oYM7VNSDWqk_Vw at 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 <gmazyland at gmail.com>
> To: ".. ink .." <mhogomchungu at gmail.com>,  "dm-crypt at saout.de"
> 	<dm-crypt at saout.de>
> Subject: Re: [dm-crypt] unsafe??? use of memset
> Message-ID: <54A2B5FA.7040606 at gmail.com>
> Content-Type: text/plain; charset=windows-1252
> 
> On 12/30/2014 02:57 PM, .. ink .. wrote:
>> 
>> 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
> 
>> 
>> [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 <arno at wagner.name>
> To: dm-crypt at saout.de
> Subject: Re: [dm-crypt] unsafe??? use of memset
> Message-ID: <20141230163814.GA18851 at tansi.org>
> 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
> 
> On Tue, Dec 30, 2014 at 14:57:56 CET, .. ink .. wrote:
>> 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
>> dm-crypt at saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
> 
> 
> -- 
> Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno at wagner.name
> 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 <arno at wagner.name>
> To: dm-crypt at saout.de
> Subject: Re: [dm-crypt] unsafe??? use of memset
> Message-ID: <20141230164721.GB18851 at tansi.org>
> Content-Type: text/plain; charset=us-ascii
> 
> On Tue, Dec 30, 2014 at 15:26:02 CET, Milan Broz wrote:
>> On 12/30/2014 02:57 PM, .. ink .. wrote:
>>> 
>>> 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
> 
> 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
> 
> 
>> 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
>> 
>>> 
>>> [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
>> dm-crypt at saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
> 
> -- 
> Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno at wagner.name
> 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: "msalists at gmx.net" <msalists at gmx.net>
> To: "dm-crypt at saout.de" <dm-crypt at saout.de>
> Subject: Re: [dm-crypt] Asustor NAS and cryptsetup 1.6.1
> Message-ID: <54A2EC7E.7030201 at gmx.net>
> 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
> 
> On 2014-12-30 02:04, Arno Wagner wrote:
>> On Tue, Dec 30, 2014 at 03:32:58 CET, msalists at gmx.net wrote:
>>> On 2014-12-29 11:29, Quentin Lefebvre wrote:
>>>> On 29/12/2014 20:06, msalists at gmx.net 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.
>>>> 
>>> 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" <sven at whgl.uni-frankfurt.de>
> To: dm-crypt at saout.de
> Subject: Re: [dm-crypt] Asustor NAS and cryptsetup 1.6.1
> Message-ID:
> 	<3f675aba93a2f8107f5271fade6c547b.squirrel at ssl.verfeiert.org>
> 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
> 
> 
> On Tue, December 30, 2014 19:18, msalists at gmx.net 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
>> 
>> On 2014-12-30 02:04, Arno Wagner wrote:
>>> On Tue, Dec 30, 2014 at 03:32:58 CET, msalists at gmx.net wrote:
>>>> On 2014-12-29 11:29, Quentin Lefebvre wrote:
>>>>> On 29/12/2014 20:06, msalists at gmx.net 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.
>>>>> 
>>>> 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
>> dm-crypt at saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Wed, 31 Dec 2014 08:26:39 +0100
> From: Arno Wagner <arno at wagner.name>
> To: dm-crypt at saout.de
> Subject: Re: [dm-crypt] Asustor NAS and cryptsetup 1.6.1
> Message-ID: <20141231072639.GA304 at tansi.org>
> 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
> 
> On Tue, Dec 30, 2014 at 19:18:38 CET, msalists at gmx.net 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
>> 
>> On 2014-12-30 02:04, Arno Wagner wrote:
>>> On Tue, Dec 30, 2014 at 03:32:58 CET, msalists at gmx.net wrote:
>>>> On 2014-12-29 11:29, Quentin Lefebvre wrote:
>>>>> On 29/12/2014 20:06, msalists at gmx.net 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.
>>>>> 
>>>> 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
>> dm-crypt at saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
> 
> -- 
> Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno at wagner.name
> 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
> dm-crypt at saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 
> 
> ------------------------------
> 
> End of dm-crypt Digest, Vol 66, Issue 20
> ****************************************



More information about the dm-crypt mailing list