On Dec 31, 2014, at 4:00 AM, dm-crypt-request@xxxxxxxx wrote: > Send dm-crypt mailing list submissions to > dm-crypt@xxxxxxxx > > 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@xxxxxxxx > > You can reach the person managing the list at > dm-crypt-owner@xxxxxxxx > > 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@xxxxxxx) > 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@xxxxxxxxx> > To: "dm-crypt@xxxxxxxx" <dm-crypt@xxxxxxxx> > Subject: unsafe??? use of memset > Message-ID: > <CAFnMBaQZp63DCZB9f9K1tPia237OGWjVQ6c2oYM7VNSDWqk_Vw@xxxxxxxxxxxxxx> > 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@xxxxxxxxx> > To: ".. ink .." <mhogomchungu@xxxxxxxxx>, "dm-crypt@xxxxxxxx" > <dm-crypt@xxxxxxxx> > Subject: Re: unsafe??? use of memset > Message-ID: <54A2B5FA.7040606@xxxxxxxxx> > 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@xxxxxxxxxxx> > To: dm-crypt@xxxxxxxx > Subject: Re: unsafe??? use of memset > Message-ID: <20141230163814.GA18851@xxxxxxxxx> > 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@xxxxxxxx >> http://www.saout.de/mailman/listinfo/dm-crypt > > > -- > Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx > 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@xxxxxxxxxxx> > To: dm-crypt@xxxxxxxx > Subject: Re: unsafe??? use of memset > Message-ID: <20141230164721.GB18851@xxxxxxxxx> > 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@xxxxxxxx >> http://www.saout.de/mailman/listinfo/dm-crypt > > -- > Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx > 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@xxxxxxx" <msalists@xxxxxxx> > To: "dm-crypt@xxxxxxxx" <dm-crypt@xxxxxxxx> > Subject: Re: Asustor NAS and cryptsetup 1.6.1 > Message-ID: <54A2EC7E.7030201@xxxxxxx> > 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@xxxxxxx wrote: >>> On 2014-12-29 11:29, Quentin Lefebvre wrote: >>>> On 29/12/2014 20:06, msalists@xxxxxxx 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@xxxxxxxxxxxxxxxxxxxxx> > To: dm-crypt@xxxxxxxx > Subject: Re: Asustor NAS and cryptsetup 1.6.1 > Message-ID: > <3f675aba93a2f8107f5271fade6c547b.squirrel@xxxxxxxxxxxxxxxxx> > 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@xxxxxxx 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@xxxxxxx wrote: >>>> On 2014-12-29 11:29, Quentin Lefebvre wrote: >>>>> On 29/12/2014 20:06, msalists@xxxxxxx 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@xxxxxxxx >> http://www.saout.de/mailman/listinfo/dm-crypt >> > > > > > ------------------------------ > > Message: 7 > Date: Wed, 31 Dec 2014 08:26:39 +0100 > From: Arno Wagner <arno@xxxxxxxxxxx> > To: dm-crypt@xxxxxxxx > Subject: Re: Asustor NAS and cryptsetup 1.6.1 > Message-ID: <20141231072639.GA304@xxxxxxxxx> > 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@xxxxxxx 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@xxxxxxx wrote: >>>> On 2014-12-29 11:29, Quentin Lefebvre wrote: >>>>> On 29/12/2014 20:06, msalists@xxxxxxx 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@xxxxxxxx >> http://www.saout.de/mailman/listinfo/dm-crypt > > -- > Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx > 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@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt > > > ------------------------------ > > End of dm-crypt Digest, Vol 66, Issue 20 > **************************************** _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
