[gentoo-user] Encrypting a hard drive's data. Best method.

[gentoo-user] Encrypting a hard drive's data. Best method.

[Dale]

[-- Attachment #1: Type: text/plain, Size: 3785 bytes --]

Howdy,

I think I got a old 3TB hard drive to work.  After dd'ing it, redoing
partitions and such, it seems to be working.  Right now, I'm copying a
bunch of data to it to see how it holds up.  Oh, it's a PMR drive too. 
lol  Once I'm pretty sure it is alive and working well, I want to play
with encryption.  At some point, I plan to encrypt /home.  I found a bit
of info with startpage but some is dated.  This is one link that seems
to be from this year, at least updated this year. 

https://linoxide.com/linux-how-to/encrypt-linux-filesystem/

It seems like a nice one since it has commands and what it should look
like when it is performing the commands.  I like knowing what I'm doing
sort of matches what the howto shows.  It also seems to use LVM which I
will be using as well.  I think I can follow that and get a working
encrypted storage.  Later, I can attempt this on /home without doing it
blind.  I also have the options in the kernel as well.  I'll post them
at the bottom.  I enabled quite a lot a while back.  ;-) 

Is this a secure method or is there a more secure way?  Is there any
known issues with using this?  Anyone here use this method?  Keep in
mind, LVM.  BTFRS, SP?, may come later. 

One other question, can one change the password every once in a while? 
Or once set, you stuck with it from then on? 

If anyone has links to even better howtos, I'd love to check them out. 

Dale

:-)  :-) 


root@fireball / # zcat /proc/config.gz | grep crypt | grep =y
CONFIG_ARCH_HAS_MEM_ENCRYPT=y
CONFIG_DM_CRYPT=y
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_SKCIPHER=y
CONFIG_CRYPTO_SKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_RNG_DEFAULT=y
CONFIG_CRYPTO_AKCIPHER2=y
CONFIG_CRYPTO_AKCIPHER=y
CONFIG_CRYPTO_KPP2=y
CONFIG_CRYPTO_ACOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
CONFIG_CRYPTO_GF128MUL=y
CONFIG_CRYPTO_NULL=y
CONFIG_CRYPTO_NULL2=y
CONFIG_CRYPTO_CRYPTD=y
CONFIG_CRYPTO_AUTHENC=y
CONFIG_CRYPTO_SIMD=y
CONFIG_CRYPTO_GLUE_HELPER_X86=y
CONFIG_CRYPTO_RSA=y
CONFIG_CRYPTO_ECHAINIV=y
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_LRW=y
CONFIG_CRYPTO_XTS=y
CONFIG_CRYPTO_NHPOLY1305=y
CONFIG_CRYPTO_NHPOLY1305_SSE2=y
CONFIG_CRYPTO_NHPOLY1305_AVX2=y
CONFIG_CRYPTO_ESSIV=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_CRC32C=y
CONFIG_CRYPTO_XXHASH=y
CONFIG_CRYPTO_BLAKE2B=y
CONFIG_CRYPTO_CRCT10DIF=y
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_RMD128=y
CONFIG_CRYPTO_RMD160=y
CONFIG_CRYPTO_RMD256=y
CONFIG_CRYPTO_RMD320=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA1_SSSE3=y
CONFIG_CRYPTO_SHA256_SSSE3=y
CONFIG_CRYPTO_SHA512_SSSE3=y
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=y
CONFIG_CRYPTO_WP512=y
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_AES_TI=y
CONFIG_CRYPTO_ARC4=y
CONFIG_CRYPTO_BLOWFISH=y
CONFIG_CRYPTO_BLOWFISH_COMMON=y
CONFIG_CRYPTO_BLOWFISH_X86_64=y
CONFIG_CRYPTO_CAMELLIA=y
CONFIG_CRYPTO_CAMELLIA_X86_64=y
CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64=y
CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64=y
CONFIG_CRYPTO_DES=y
CONFIG_CRYPTO_SERPENT=y
CONFIG_CRYPTO_SERPENT_SSE2_X86_64=y
CONFIG_CRYPTO_TWOFISH=y
CONFIG_CRYPTO_TWOFISH_COMMON=y
CONFIG_CRYPTO_TWOFISH_X86_64=y
CONFIG_CRYPTO_TWOFISH_X86_64_3WAY=y
CONFIG_CRYPTO_ANSI_CPRNG=y
CONFIG_CRYPTO_DRBG_MENU=y
CONFIG_CRYPTO_DRBG_HMAC=y
CONFIG_CRYPTO_DRBG=y
CONFIG_CRYPTO_JITTERENTROPY=y
CONFIG_CRYPTO_USER_API=y
CONFIG_CRYPTO_USER_API_HASH=y
CONFIG_CRYPTO_USER_API_SKCIPHER=y
CONFIG_CRYPTO_USER_API_RNG=y
CONFIG_CRYPTO_LIB_AES=y
CONFIG_CRYPTO_LIB_ARC4=y
CONFIG_CRYPTO_LIB_DES=y
CONFIG_CRYPTO_LIB_POLY1305_GENERIC=y
CONFIG_CRYPTO_LIB_SHA256=y
CONFIG_CRYPTO_HW=y
root@fireball / #

Just wanted to have a few extras.  ROFL 

[-- Attachment #2: Type: text/html, Size: 5010 bytes --]

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[J. Roeleveld]

On 6 June 2020 06:37:23 CEST, Dale <rdalek1967@gmail.com> wrote:
>Howdy,
>
>I think I got a old 3TB hard drive to work.  After dd'ing it, redoing
>partitions and such, it seems to be working.  Right now, I'm copying a
>bunch of data to it to see how it holds up.  Oh, it's a PMR drive too. 
>lol  Once I'm pretty sure it is alive and working well, I want to play
>with encryption.  At some point, I plan to encrypt /home.  I found a
>bit
>of info with startpage but some is dated.  This is one link that seems
>to be from this year, at least updated this year. 
>
>https://linoxide.com/linux-how-to/encrypt-linux-filesystem/
>
>It seems like a nice one since it has commands and what it should look
>like when it is performing the commands.  I like knowing what I'm doing
>sort of matches what the howto shows.  It also seems to use LVM which I
>will be using as well.  I think I can follow that and get a working
>encrypted storage.  Later, I can attempt this on /home without doing it
>blind.  I also have the options in the kernel as well.  I'll post them
>at the bottom.  I enabled quite a lot a while back.  ;-) 
>
>Is this a secure method or is there a more secure way?  Is there any
>known issues with using this?  Anyone here use this method?  Keep in
>mind, LVM.  BTFRS, SP?, may come later. 
>
>One other question, can one change the password every once in a while? 
>Or once set, you stuck with it from then on? 
>
>If anyone has links to even better howtos, I'd love to check them out. 
>
>Dale
>
>:-)  :-) 
>
>
>root@fireball / # zcat /proc/config.gz | grep crypt | grep =y
>CONFIG_ARCH_HAS_MEM_ENCRYPT=y
>CONFIG_DM_CRYPT=y
>CONFIG_CRYPTO=y
>CONFIG_CRYPTO_ALGAPI=y
>CONFIG_CRYPTO_ALGAPI2=y
>CONFIG_CRYPTO_AEAD=y
>CONFIG_CRYPTO_AEAD2=y
>CONFIG_CRYPTO_SKCIPHER=y
>CONFIG_CRYPTO_SKCIPHER2=y
>CONFIG_CRYPTO_HASH=y
>CONFIG_CRYPTO_HASH2=y
>CONFIG_CRYPTO_RNG=y
>CONFIG_CRYPTO_RNG2=y
>CONFIG_CRYPTO_RNG_DEFAULT=y
>CONFIG_CRYPTO_AKCIPHER2=y
>CONFIG_CRYPTO_AKCIPHER=y
>CONFIG_CRYPTO_KPP2=y
>CONFIG_CRYPTO_ACOMP2=y
>CONFIG_CRYPTO_MANAGER=y
>CONFIG_CRYPTO_MANAGER2=y
>CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
>CONFIG_CRYPTO_GF128MUL=y
>CONFIG_CRYPTO_NULL=y
>CONFIG_CRYPTO_NULL2=y
>CONFIG_CRYPTO_CRYPTD=y
>CONFIG_CRYPTO_AUTHENC=y
>CONFIG_CRYPTO_SIMD=y
>CONFIG_CRYPTO_GLUE_HELPER_X86=y
>CONFIG_CRYPTO_RSA=y
>CONFIG_CRYPTO_ECHAINIV=y
>CONFIG_CRYPTO_CBC=y
>CONFIG_CRYPTO_ECB=y
>CONFIG_CRYPTO_LRW=y
>CONFIG_CRYPTO_XTS=y
>CONFIG_CRYPTO_NHPOLY1305=y
>CONFIG_CRYPTO_NHPOLY1305_SSE2=y
>CONFIG_CRYPTO_NHPOLY1305_AVX2=y
>CONFIG_CRYPTO_ESSIV=y
>CONFIG_CRYPTO_HMAC=y
>CONFIG_CRYPTO_CRC32C=y
>CONFIG_CRYPTO_XXHASH=y
>CONFIG_CRYPTO_BLAKE2B=y
>CONFIG_CRYPTO_CRCT10DIF=y
>CONFIG_CRYPTO_MD5=y
>CONFIG_CRYPTO_RMD128=y
>CONFIG_CRYPTO_RMD160=y
>CONFIG_CRYPTO_RMD256=y
>CONFIG_CRYPTO_RMD320=y
>CONFIG_CRYPTO_SHA1=y
>CONFIG_CRYPTO_SHA1_SSSE3=y
>CONFIG_CRYPTO_SHA256_SSSE3=y
>CONFIG_CRYPTO_SHA512_SSSE3=y
>CONFIG_CRYPTO_SHA256=y
>CONFIG_CRYPTO_SHA512=y
>CONFIG_CRYPTO_WP512=y
>CONFIG_CRYPTO_AES=y
>CONFIG_CRYPTO_AES_TI=y
>CONFIG_CRYPTO_ARC4=y
>CONFIG_CRYPTO_BLOWFISH=y
>CONFIG_CRYPTO_BLOWFISH_COMMON=y
>CONFIG_CRYPTO_BLOWFISH_X86_64=y
>CONFIG_CRYPTO_CAMELLIA=y
>CONFIG_CRYPTO_CAMELLIA_X86_64=y
>CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64=y
>CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64=y
>CONFIG_CRYPTO_DES=y
>CONFIG_CRYPTO_SERPENT=y
>CONFIG_CRYPTO_SERPENT_SSE2_X86_64=y
>CONFIG_CRYPTO_TWOFISH=y
>CONFIG_CRYPTO_TWOFISH_COMMON=y
>CONFIG_CRYPTO_TWOFISH_X86_64=y
>CONFIG_CRYPTO_TWOFISH_X86_64_3WAY=y
>CONFIG_CRYPTO_ANSI_CPRNG=y
>CONFIG_CRYPTO_DRBG_MENU=y
>CONFIG_CRYPTO_DRBG_HMAC=y
>CONFIG_CRYPTO_DRBG=y
>CONFIG_CRYPTO_JITTERENTROPY=y
>CONFIG_CRYPTO_USER_API=y
>CONFIG_CRYPTO_USER_API_HASH=y
>CONFIG_CRYPTO_USER_API_SKCIPHER=y
>CONFIG_CRYPTO_USER_API_RNG=y
>CONFIG_CRYPTO_LIB_AES=y
>CONFIG_CRYPTO_LIB_ARC4=y
>CONFIG_CRYPTO_LIB_DES=y
>CONFIG_CRYPTO_LIB_POLY1305_GENERIC=y
>CONFIG_CRYPTO_LIB_SHA256=y
>CONFIG_CRYPTO_HW=y
>root@fireball / #
>
>Just wanted to have a few extras.  ROFL 

Dale,

I didn't read the full page, but as it uses LUKS to manage the encryption, it is (at least similar) to what I do on my laptops.

A LUKS volume has support for multiple (I think 4) key slots (passwords that will decrypt the volume)

So, in order to change the password you would do:
1) add the new password into an unused slot
2) test the new password works
3) delete the old password (freeing the slot)

--
Joost

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[J. Roeleveld]

On 6 June 2020 06:37:23 CEST, Dale <rdalek1967@gmail.com> wrote:
>Howdy,
>
>I think I got a old 3TB hard drive to work.  After dd'ing it, redoing
>partitions and such, it seems to be working.  Right now, I'm copying a
>bunch of data to it to see how it holds up.  Oh, it's a PMR drive too. 
>lol  Once I'm pretty sure it is alive and working well, I want to play
>with encryption.  At some point, I plan to encrypt /home.  I found a
>bit
>of info with startpage but some is dated.  This is one link that seems
>to be from this year, at least updated this year. 
>
>https://linoxide.com/linux-how-to/encrypt-linux-filesystem/
>
>It seems like a nice one since it has commands and what it should look
>like when it is performing the commands.  I like knowing what I'm doing
>sort of matches what the howto shows.  It also seems to use LVM which I
>will be using as well.  I think I can follow that and get a working
>encrypted storage.  Later, I can attempt this on /home without doing it
>blind.  I also have the options in the kernel as well.  I'll post them
>at the bottom.  I enabled quite a lot a while back.  ;-) 
>
>Is this a secure method or is there a more secure way?  Is there any
>known issues with using this?  Anyone here use this method?  Keep in
>mind, LVM.  BTFRS, SP?, may come later. 
>
>One other question, can one change the password every once in a while? 
>Or once set, you stuck with it from then on? 
>
>If anyone has links to even better howtos, I'd love to check them out. 
>
>Dale
>
>:-)  :-) 
>
>
>root@fireball / # zcat /proc/config.gz | grep crypt | grep =y
>CONFIG_ARCH_HAS_MEM_ENCRYPT=y
>CONFIG_DM_CRYPT=y
>CONFIG_CRYPTO=y
>CONFIG_CRYPTO_ALGAPI=y
>CONFIG_CRYPTO_ALGAPI2=y
>CONFIG_CRYPTO_AEAD=y
>CONFIG_CRYPTO_AEAD2=y
>CONFIG_CRYPTO_SKCIPHER=y
>CONFIG_CRYPTO_SKCIPHER2=y
>CONFIG_CRYPTO_HASH=y
>CONFIG_CRYPTO_HASH2=y
>CONFIG_CRYPTO_RNG=y
>CONFIG_CRYPTO_RNG2=y
>CONFIG_CRYPTO_RNG_DEFAULT=y
>CONFIG_CRYPTO_AKCIPHER2=y
>CONFIG_CRYPTO_AKCIPHER=y
>CONFIG_CRYPTO_KPP2=y
>CONFIG_CRYPTO_ACOMP2=y
>CONFIG_CRYPTO_MANAGER=y
>CONFIG_CRYPTO_MANAGER2=y
>CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
>CONFIG_CRYPTO_GF128MUL=y
>CONFIG_CRYPTO_NULL=y
>CONFIG_CRYPTO_NULL2=y
>CONFIG_CRYPTO_CRYPTD=y
>CONFIG_CRYPTO_AUTHENC=y
>CONFIG_CRYPTO_SIMD=y
>CONFIG_CRYPTO_GLUE_HELPER_X86=y
>CONFIG_CRYPTO_RSA=y
>CONFIG_CRYPTO_ECHAINIV=y
>CONFIG_CRYPTO_CBC=y
>CONFIG_CRYPTO_ECB=y
>CONFIG_CRYPTO_LRW=y
>CONFIG_CRYPTO_XTS=y
>CONFIG_CRYPTO_NHPOLY1305=y
>CONFIG_CRYPTO_NHPOLY1305_SSE2=y
>CONFIG_CRYPTO_NHPOLY1305_AVX2=y
>CONFIG_CRYPTO_ESSIV=y
>CONFIG_CRYPTO_HMAC=y
>CONFIG_CRYPTO_CRC32C=y
>CONFIG_CRYPTO_XXHASH=y
>CONFIG_CRYPTO_BLAKE2B=y
>CONFIG_CRYPTO_CRCT10DIF=y
>CONFIG_CRYPTO_MD5=y
>CONFIG_CRYPTO_RMD128=y
>CONFIG_CRYPTO_RMD160=y
>CONFIG_CRYPTO_RMD256=y
>CONFIG_CRYPTO_RMD320=y
>CONFIG_CRYPTO_SHA1=y
>CONFIG_CRYPTO_SHA1_SSSE3=y
>CONFIG_CRYPTO_SHA256_SSSE3=y
>CONFIG_CRYPTO_SHA512_SSSE3=y
>CONFIG_CRYPTO_SHA256=y
>CONFIG_CRYPTO_SHA512=y
>CONFIG_CRYPTO_WP512=y
>CONFIG_CRYPTO_AES=y
>CONFIG_CRYPTO_AES_TI=y
>CONFIG_CRYPTO_ARC4=y
>CONFIG_CRYPTO_BLOWFISH=y
>CONFIG_CRYPTO_BLOWFISH_COMMON=y
>CONFIG_CRYPTO_BLOWFISH_X86_64=y
>CONFIG_CRYPTO_CAMELLIA=y
>CONFIG_CRYPTO_CAMELLIA_X86_64=y
>CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64=y
>CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64=y
>CONFIG_CRYPTO_DES=y
>CONFIG_CRYPTO_SERPENT=y
>CONFIG_CRYPTO_SERPENT_SSE2_X86_64=y
>CONFIG_CRYPTO_TWOFISH=y
>CONFIG_CRYPTO_TWOFISH_COMMON=y
>CONFIG_CRYPTO_TWOFISH_X86_64=y
>CONFIG_CRYPTO_TWOFISH_X86_64_3WAY=y
>CONFIG_CRYPTO_ANSI_CPRNG=y
>CONFIG_CRYPTO_DRBG_MENU=y
>CONFIG_CRYPTO_DRBG_HMAC=y
>CONFIG_CRYPTO_DRBG=y
>CONFIG_CRYPTO_JITTERENTROPY=y
>CONFIG_CRYPTO_USER_API=y
>CONFIG_CRYPTO_USER_API_HASH=y
>CONFIG_CRYPTO_USER_API_SKCIPHER=y
>CONFIG_CRYPTO_USER_API_RNG=y
>CONFIG_CRYPTO_LIB_AES=y
>CONFIG_CRYPTO_LIB_ARC4=y
>CONFIG_CRYPTO_LIB_DES=y
>CONFIG_CRYPTO_LIB_POLY1305_GENERIC=y
>CONFIG_CRYPTO_LIB_SHA256=y
>CONFIG_CRYPTO_HW=y
>root@fireball / #
>
>Just wanted to have a few extras.  ROFL 

A gentoo centric manual/howto:

https://wiki.gentoo.org/wiki/Dm-crypt

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Dale]

[-- Attachment #1: Type: text/plain, Size: 4935 bytes --]

J. Roeleveld wrote:
> On 6 June 2020 06:37:23 CEST, Dale <rdalek1967@gmail.com> wrote:
>> Howdy,
>>
>> I think I got a old 3TB hard drive to work.  After dd'ing it, redoing
>> partitions and such, it seems to be working.  Right now, I'm copying a
>> bunch of data to it to see how it holds up.  Oh, it's a PMR drive too. 
>> lol  Once I'm pretty sure it is alive and working well, I want to play
>> with encryption.  At some point, I plan to encrypt /home.  I found a
>> bit
>> of info with startpage but some is dated.  This is one link that seems
>> to be from this year, at least updated this year. 
>>
>> https://linoxide.com/linux-how-to/encrypt-linux-filesystem/
>>
>> It seems like a nice one since it has commands and what it should look
>> like when it is performing the commands.  I like knowing what I'm doing
>> sort of matches what the howto shows.  It also seems to use LVM which I
>> will be using as well.  I think I can follow that and get a working
>> encrypted storage.  Later, I can attempt this on /home without doing it
>> blind.  I also have the options in the kernel as well.  I'll post them
>> at the bottom.  I enabled quite a lot a while back.  ;-) 
>>
>> Is this a secure method or is there a more secure way?  Is there any
>> known issues with using this?  Anyone here use this method?  Keep in
>> mind, LVM.  BTFRS, SP?, may come later. 
>>
>> One other question, can one change the password every once in a while? 
>> Or once set, you stuck with it from then on? 
>>
>> If anyone has links to even better howtos, I'd love to check them out. 
>>
>> Dale
>>
>> :-)  :-) 
>>
>>
>> root@fireball / # zcat /proc/config.gz | grep crypt | grep =y
>> CONFIG_ARCH_HAS_MEM_ENCRYPT=y
>> CONFIG_DM_CRYPT=y
>> CONFIG_CRYPTO=y
>> CONFIG_CRYPTO_ALGAPI=y
>> CONFIG_CRYPTO_ALGAPI2=y
>> CONFIG_CRYPTO_AEAD=y
>> CONFIG_CRYPTO_AEAD2=y
>> CONFIG_CRYPTO_SKCIPHER=y
>> CONFIG_CRYPTO_SKCIPHER2=y
>> CONFIG_CRYPTO_HASH=y
>> CONFIG_CRYPTO_HASH2=y
>> CONFIG_CRYPTO_RNG=y
>> CONFIG_CRYPTO_RNG2=y
>> CONFIG_CRYPTO_RNG_DEFAULT=y
>> CONFIG_CRYPTO_AKCIPHER2=y
>> CONFIG_CRYPTO_AKCIPHER=y
>> CONFIG_CRYPTO_KPP2=y
>> CONFIG_CRYPTO_ACOMP2=y
>> CONFIG_CRYPTO_MANAGER=y
>> CONFIG_CRYPTO_MANAGER2=y
>> CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
>> CONFIG_CRYPTO_GF128MUL=y
>> CONFIG_CRYPTO_NULL=y
>> CONFIG_CRYPTO_NULL2=y
>> CONFIG_CRYPTO_CRYPTD=y
>> CONFIG_CRYPTO_AUTHENC=y
>> CONFIG_CRYPTO_SIMD=y
>> CONFIG_CRYPTO_GLUE_HELPER_X86=y
>> CONFIG_CRYPTO_RSA=y
>> CONFIG_CRYPTO_ECHAINIV=y
>> CONFIG_CRYPTO_CBC=y
>> CONFIG_CRYPTO_ECB=y
>> CONFIG_CRYPTO_LRW=y
>> CONFIG_CRYPTO_XTS=y
>> CONFIG_CRYPTO_NHPOLY1305=y
>> CONFIG_CRYPTO_NHPOLY1305_SSE2=y
>> CONFIG_CRYPTO_NHPOLY1305_AVX2=y
>> CONFIG_CRYPTO_ESSIV=y
>> CONFIG_CRYPTO_HMAC=y
>> CONFIG_CRYPTO_CRC32C=y
>> CONFIG_CRYPTO_XXHASH=y
>> CONFIG_CRYPTO_BLAKE2B=y
>> CONFIG_CRYPTO_CRCT10DIF=y
>> CONFIG_CRYPTO_MD5=y
>> CONFIG_CRYPTO_RMD128=y
>> CONFIG_CRYPTO_RMD160=y
>> CONFIG_CRYPTO_RMD256=y
>> CONFIG_CRYPTO_RMD320=y
>> CONFIG_CRYPTO_SHA1=y
>> CONFIG_CRYPTO_SHA1_SSSE3=y
>> CONFIG_CRYPTO_SHA256_SSSE3=y
>> CONFIG_CRYPTO_SHA512_SSSE3=y
>> CONFIG_CRYPTO_SHA256=y
>> CONFIG_CRYPTO_SHA512=y
>> CONFIG_CRYPTO_WP512=y
>> CONFIG_CRYPTO_AES=y
>> CONFIG_CRYPTO_AES_TI=y
>> CONFIG_CRYPTO_ARC4=y
>> CONFIG_CRYPTO_BLOWFISH=y
>> CONFIG_CRYPTO_BLOWFISH_COMMON=y
>> CONFIG_CRYPTO_BLOWFISH_X86_64=y
>> CONFIG_CRYPTO_CAMELLIA=y
>> CONFIG_CRYPTO_CAMELLIA_X86_64=y
>> CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64=y
>> CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64=y
>> CONFIG_CRYPTO_DES=y
>> CONFIG_CRYPTO_SERPENT=y
>> CONFIG_CRYPTO_SERPENT_SSE2_X86_64=y
>> CONFIG_CRYPTO_TWOFISH=y
>> CONFIG_CRYPTO_TWOFISH_COMMON=y
>> CONFIG_CRYPTO_TWOFISH_X86_64=y
>> CONFIG_CRYPTO_TWOFISH_X86_64_3WAY=y
>> CONFIG_CRYPTO_ANSI_CPRNG=y
>> CONFIG_CRYPTO_DRBG_MENU=y
>> CONFIG_CRYPTO_DRBG_HMAC=y
>> CONFIG_CRYPTO_DRBG=y
>> CONFIG_CRYPTO_JITTERENTROPY=y
>> CONFIG_CRYPTO_USER_API=y
>> CONFIG_CRYPTO_USER_API_HASH=y
>> CONFIG_CRYPTO_USER_API_SKCIPHER=y
>> CONFIG_CRYPTO_USER_API_RNG=y
>> CONFIG_CRYPTO_LIB_AES=y
>> CONFIG_CRYPTO_LIB_ARC4=y
>> CONFIG_CRYPTO_LIB_DES=y
>> CONFIG_CRYPTO_LIB_POLY1305_GENERIC=y
>> CONFIG_CRYPTO_LIB_SHA256=y
>> CONFIG_CRYPTO_HW=y
>> root@fireball / #
>>
>> Just wanted to have a few extras.  ROFL 
> A gentoo centric manual/howto:
>
> https://wiki.gentoo.org/wiki/Dm-crypt
>


Thanks for both replies.  I found one other Gentoo one but it was
encrypting the whole thing, /boot and all, plus they used efi.  I didn't
find the one you linked too. 

First drive seems to have died.  Got part way copying files and things
got interesting.  When checking smartctrl, it even puked on my
keyboard.  Drive only had a few hundred hours on it so maybe the drive
was iffy from the start or that enclosure did damage somehow.  Either
way, drive two being tested.  Running smartctrl test first and then
restart from scratch and fill it up with files or something. 

Thanks much.

Dale

:-)  :-) 

[-- Attachment #2: Type: text/html, Size: 5399 bytes --]

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Michael]

[-- Attachment #1: Type: text/plain, Size: 6366 bytes --]

On Saturday, 6 June 2020 08:49:54 BST Dale wrote:
> J. Roeleveld wrote:
> > On 6 June 2020 06:37:23 CEST, Dale <rdalek1967@gmail.com> wrote:
> >> Howdy,
> >> 
> >> I think I got a old 3TB hard drive to work.  After dd'ing it, redoing
> >> partitions and such, it seems to be working.  Right now, I'm copying a
> >> bunch of data to it to see how it holds up.  Oh, it's a PMR drive too. 
> >> lol  Once I'm pretty sure it is alive and working well, I want to play
> >> with encryption.  At some point, I plan to encrypt /home.  I found a
> >> bit
> >> of info with startpage but some is dated.  This is one link that seems
> >> to be from this year, at least updated this year. 
> >> 
> >> https://linoxide.com/linux-how-to/encrypt-linux-filesystem/
> >> 
> >> It seems like a nice one since it has commands and what it should look
> >> like when it is performing the commands.  I like knowing what I'm doing
> >> sort of matches what the howto shows.  It also seems to use LVM which I
> >> will be using as well.  I think I can follow that and get a working
> >> encrypted storage.  Later, I can attempt this on /home without doing it
> >> blind.  I also have the options in the kernel as well.  I'll post them
> >> at the bottom.  I enabled quite a lot a while back.  ;-) 
> >> 
> >> Is this a secure method or is there a more secure way?  Is there any
> >> known issues with using this?  Anyone here use this method?  Keep in
> >> mind, LVM.  BTFRS, SP?, may come later. 
> >> 
> >> One other question, can one change the password every once in a while? 
> >> Or once set, you stuck with it from then on? 
> >> 
> >> If anyone has links to even better howtos, I'd love to check them out. 
> >> 
> >> Dale
> >> 
> >> :-)  :-) 
> >> 
> >> root@fireball / # zcat /proc/config.gz | grep crypt | grep =y
> >> CONFIG_ARCH_HAS_MEM_ENCRYPT=y
> >> CONFIG_DM_CRYPT=y
> >> CONFIG_CRYPTO=y
> >> CONFIG_CRYPTO_ALGAPI=y
> >> CONFIG_CRYPTO_ALGAPI2=y
> >> CONFIG_CRYPTO_AEAD=y
> >> CONFIG_CRYPTO_AEAD2=y
> >> CONFIG_CRYPTO_SKCIPHER=y
> >> CONFIG_CRYPTO_SKCIPHER2=y
> >> CONFIG_CRYPTO_HASH=y
> >> CONFIG_CRYPTO_HASH2=y
> >> CONFIG_CRYPTO_RNG=y
> >> CONFIG_CRYPTO_RNG2=y
> >> CONFIG_CRYPTO_RNG_DEFAULT=y
> >> CONFIG_CRYPTO_AKCIPHER2=y
> >> CONFIG_CRYPTO_AKCIPHER=y
> >> CONFIG_CRYPTO_KPP2=y
> >> CONFIG_CRYPTO_ACOMP2=y
> >> CONFIG_CRYPTO_MANAGER=y
> >> CONFIG_CRYPTO_MANAGER2=y
> >> CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
> >> CONFIG_CRYPTO_GF128MUL=y
> >> CONFIG_CRYPTO_NULL=y
> >> CONFIG_CRYPTO_NULL2=y
> >> CONFIG_CRYPTO_CRYPTD=y
> >> CONFIG_CRYPTO_AUTHENC=y
> >> CONFIG_CRYPTO_SIMD=y
> >> CONFIG_CRYPTO_GLUE_HELPER_X86=y
> >> CONFIG_CRYPTO_RSA=y
> >> CONFIG_CRYPTO_ECHAINIV=y
> >> CONFIG_CRYPTO_CBC=y
> >> CONFIG_CRYPTO_ECB=y
> >> CONFIG_CRYPTO_LRW=y
> >> CONFIG_CRYPTO_XTS=y
> >> CONFIG_CRYPTO_NHPOLY1305=y
> >> CONFIG_CRYPTO_NHPOLY1305_SSE2=y
> >> CONFIG_CRYPTO_NHPOLY1305_AVX2=y
> >> CONFIG_CRYPTO_ESSIV=y
> >> CONFIG_CRYPTO_HMAC=y
> >> CONFIG_CRYPTO_CRC32C=y
> >> CONFIG_CRYPTO_XXHASH=y
> >> CONFIG_CRYPTO_BLAKE2B=y
> >> CONFIG_CRYPTO_CRCT10DIF=y
> >> CONFIG_CRYPTO_MD5=y
> >> CONFIG_CRYPTO_RMD128=y
> >> CONFIG_CRYPTO_RMD160=y
> >> CONFIG_CRYPTO_RMD256=y
> >> CONFIG_CRYPTO_RMD320=y
> >> CONFIG_CRYPTO_SHA1=y
> >> CONFIG_CRYPTO_SHA1_SSSE3=y
> >> CONFIG_CRYPTO_SHA256_SSSE3=y
> >> CONFIG_CRYPTO_SHA512_SSSE3=y
> >> CONFIG_CRYPTO_SHA256=y
> >> CONFIG_CRYPTO_SHA512=y
> >> CONFIG_CRYPTO_WP512=y
> >> CONFIG_CRYPTO_AES=y
> >> CONFIG_CRYPTO_AES_TI=y
> >> CONFIG_CRYPTO_ARC4=y
> >> CONFIG_CRYPTO_BLOWFISH=y
> >> CONFIG_CRYPTO_BLOWFISH_COMMON=y
> >> CONFIG_CRYPTO_BLOWFISH_X86_64=y
> >> CONFIG_CRYPTO_CAMELLIA=y
> >> CONFIG_CRYPTO_CAMELLIA_X86_64=y
> >> CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64=y
> >> CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64=y
> >> CONFIG_CRYPTO_DES=y
> >> CONFIG_CRYPTO_SERPENT=y
> >> CONFIG_CRYPTO_SERPENT_SSE2_X86_64=y
> >> CONFIG_CRYPTO_TWOFISH=y
> >> CONFIG_CRYPTO_TWOFISH_COMMON=y
> >> CONFIG_CRYPTO_TWOFISH_X86_64=y
> >> CONFIG_CRYPTO_TWOFISH_X86_64_3WAY=y
> >> CONFIG_CRYPTO_ANSI_CPRNG=y
> >> CONFIG_CRYPTO_DRBG_MENU=y
> >> CONFIG_CRYPTO_DRBG_HMAC=y
> >> CONFIG_CRYPTO_DRBG=y
> >> CONFIG_CRYPTO_JITTERENTROPY=y
> >> CONFIG_CRYPTO_USER_API=y
> >> CONFIG_CRYPTO_USER_API_HASH=y
> >> CONFIG_CRYPTO_USER_API_SKCIPHER=y
> >> CONFIG_CRYPTO_USER_API_RNG=y
> >> CONFIG_CRYPTO_LIB_AES=y
> >> CONFIG_CRYPTO_LIB_ARC4=y
> >> CONFIG_CRYPTO_LIB_DES=y
> >> CONFIG_CRYPTO_LIB_POLY1305_GENERIC=y
> >> CONFIG_CRYPTO_LIB_SHA256=y
> >> CONFIG_CRYPTO_HW=y
> >> root@fireball / #
> >> 
> >> Just wanted to have a few extras.  ROFL 

Nowt wrong with that, as long as you remember MD5, SHA1 and some other 
offerings from your list above have been compromised and should not be used if 
strong encryption/integrity is required.


> > A gentoo centric manual/howto:
> > 
> > https://wiki.gentoo.org/wiki/Dm-crypt
> 
> Thanks for both replies.  I found one other Gentoo one but it was
> encrypting the whole thing, /boot and all, plus they used efi.  I didn't
> find the one you linked too. 
> 
> First drive seems to have died.  Got part way copying files and things
> got interesting.  When checking smartctrl, it even puked on my
> keyboard.  Drive only had a few hundred hours on it so maybe the drive
> was iffy from the start or that enclosure did damage somehow.  Either
> way, drive two being tested.  Running smartctrl test first and then
> restart from scratch and fill it up with files or something. 
> 
> Thanks much.
> 
> Dale
> 
> :-)  :-) 

There is also ecryptfs, kernel ext4 fs encryption, CryFS, if encrypting a 
directory/file may be desired, rather than encrypting a whole block device.  
CryFS in particular supports cloud storage as a use case.

I have not tried any of them and don't know how they compare.  I wanted to 
look into ext4 native kernel encryption, but the Gentoo wiki only describes a 
systemd-centric implementation.  :-(

Of particular interest to me is recovery of encrypted files/partitions, using 
a different installation than the original.  Having to keep a copy of the 
original installation kernel keys for ext4 with any data backups and 
additionally remembering to refresh them every time a new kernel is installed, 
adds to the user-un-friendliness of an encryption method.

For block level encryption there's also veracrypt.

https://wiki.gentoo.org/wiki/User:Maffblaster/Drafts/eCryptfs
https://wiki.gentoo.org/wiki/Ext4_encryption

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[antlists]

On 06/06/2020 11:32, Michael wrote:
> Of particular interest to me is recovery of encrypted files/partitions, using
> a different installation than the original.  Having to keep a copy of the
> original installation kernel keys for ext4 with any data backups and
> additionally remembering to refresh them every time a new kernel is installed,
> adds to the user-un-friendliness of an encryption method.

Just to throw a BIG monkey-wrench into the picture, be careful if you 
install or upgrade any operating system ...

One of the problems that crops up every now and then on the raid mailing 
list is "intelligent" utilities writing an MBR or GPT without asking...

And the latest one was an upgrade to debian. Something seemed to have 
written a GPT to /dev/md0 which obviously didn't do the array much good 
... it always used to be just writing to a hard drive like /dev/sdX and 
now it seems to be writing to other block devices as well :-(

Cheers,
Wol

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Rich Freeman]

On Sat, Jun 6, 2020 at 3:49 AM Dale <rdalek1967@gmail.com> wrote:
>
> Thanks for both replies.  I found one other Gentoo one but it was encrypting the whole thing, /boot and all, plus they used efi.  I didn't find the one you linked too.

The Gentoo guide that was linked uses an example of encrypting a partition.

This is just block device layering though.  You can probably stack
them anyway you want as long as the various services/etc are set up to
load in the right order.  You could encrypt the disk and stick LVM on
it.  Or you could stick LVM on the disk and use LUKS on the logical
volumes inside.

Usually you want the encryption as close to the disk as possible
because if somebody gets your disk it gives them less to work with.
They don't know that you have a logical volume called "home" on it,
and so on.

Some more recent filesystems have encryption built into them, like
zfs/etc (well, the most recent version).  There can be benefits to
doing it this way as the filesystem might be better able to cope with
data corruption if there is some problem later.

However, you can always stick dm-crypt/LUKS/etc on a physical disk and
then just treat the resulting block device as if it were your disk.
dm-crypt itself has very little overhead.

As you pointed out, the main thing you do have to be careful about is
/boot.  As long as you're using an appropriate initramfs you can do
just about anything else after that, but your firmware isn't going to
go prompting for your LUKS password/etc.

I should mention it for completeness, but I don't recommend this: you
can also use ATA security with a password that unlocks the hard drive.
In theory the drive should be encrypting its data when security is in
use, and it makes the drive inaccessible without the password.  The
problem is that this is generally not audited by anybody and you have
no way of knowing what the drive is doing or whether it is a secure
implementation.  But, I mention it for completeness, because it can be
done on Linux.

-- 
Rich

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Victor Ivanov]

[-- Attachment #1.1: Type: text/plain, Size: 5223 bytes --]


On 06/06/2020 12:05, Rich Freeman wrote:
> Usually you want the encryption as close to the disk as possible
> because if somebody gets your disk it gives them less to work with.
> They don't know that you have a logical volume called "home" on it,
> and so on.

I concur with Rich on this.

One of the key considerations for encryption is how much is it that want
encrypted and what metadata are you willing to have publicly visible. As
an extreme example, you can think of the simplest form of encryption -
on a per file basis. Contents are encrypted, but things like file name
and size, creation and modification timestamps, filesystem directory
tree are all available to an imaginary adversary. One can further deduce
information about the file by its extension, and use all of that to come
up with a good attack strategy for decryption. In other cases, contents
may be irrelevant to an adversary, as they can already infer a lot about
a person - if that's what they are interested in - from directory
listings etc, depending on what they are looking for. Filesystem-based
support for encryption will inevitably leak some metadata.

On the other extreme you have block-level encryption which hides all
contents, including filesystem information, for a given block device.
With multiple physical partitions, however, this too can leak a degree
of information. For example, it would be reasonable to assume that the
largest partition is a person's "storage" partition. So attempts can be
targeted at that block device, ignoring all other ones. It's also
cumbersome to manage as unlocking multiple block devices would require
multiple password entries unless a common key file is used.

Michael mentioned CryFS which is kind of in the middle. It's an
"overlay" filesystem, anything within a CyFS volume is encrypted into
fixed-size (e.g. 64KB) block files. This includes file names and all
file meta data, directory structure, etc., and all encrypted content can
be interleaved across different blocks. However, depending on the size
of the average files you have, it can have a significant overhead where
contents of the encrypted CryFS volume can be considerably larger than
the actual contents of your encrypted data. This can addressed, to a
degree, by playing with the block size. Smaller block size will reduce
overhead but will increase the number of block-sized encrypted files on
the actual filesystem, which can eat up a lot of INodes.  The downside
is, the block size cannot be changed once a CryFS volume is created, and
neither can the password. These require creating a new CryFS volume and
migrating your files. As such, my personal view on the matter is that
CryFS is usually good for small volumes and is indeed very good for
securing content on cloud services like Dropbox that do not normally
encrypt your data.

Personally, I have been using LUKS and LVM for many years. On OS-bearing
drives I would have a non-encrypted /boot partition for the kernel and
initrd whilst the remainder of the drive would be a LUKS encrypted block
device - two partitions in total (3 for a GPT system). Within the
latter, I would create LVM partitions as I desire (including OS root).
LUKS has 8 slots that can hold up to 8 passwords or key files (or any
combination of both) at a time. This set up is pretty much zero-leak.
For an external drive I would use LUKS across the whole drive. Note in
the former case the /boot partition is still vulnerable and a
compromised kernel image could lead to a leaked LUKS password once the
LUKS block device is opened. Signing the kernel and its modules is one
possible solution. At the end of the day, which method you choose is
based on a balancing trade-offs and likelihoods of an attack.

That said, virtually all modern processors in the last 10y or so have
native hardware extensions for accelerating common encryption algorithms
such as AES. As such, having full-disk encryption has very little
performance overhead on read/write speeds. You can use "cryptsetup
benchmark" to see upper bound estimates of read/write speeds. The values
shown are in-memory estimates and are thus CPU/memory bottlenecked. For
example, on one of my systems with a mobile i7 CPU AES with 512b key
(maximum supported by LUKS with AES) shows about 2,000MB/s for both
read/write. This is more than enough to saturate a SATA3 drive's 6Gb/s
best-case data rate as well as a lot of current generation consumer
grade NVMe drives.

In summary (and final remarks):
* Performance overhead these days is largely irrelevant for common use cases
* Use case (e.g. cloud storage or local drives) and what is left behind
unencrypted is a key consideration when choosing a method.
* Generally, block-level encryption is preferable to filesystem encryption
* LUKS is Linux-specific. If cross-platform compatibility is required
this won't be a good choice. Then again, so is LVM.
* TrueCrypt is obsolete - do not use this if you can avoid it
* VeraCrypt (its successor) is cross platform. Probably a good choice
for block-level encryption between different OS [I haven't personally
tried this].

Hope this helps.

- Victor


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[antlists]

On 06/06/2020 08:49, Dale wrote:
> First drive seems to have died.  Got part way copying files and things 
> got interesting.  When checking smartctrl, it even puked on my 
> keyboard.  Drive only had a few hundred hours on it so maybe the drive 
> was iffy from the start or that enclosure did damage somehow. Either 
> way, drive two being tested.  Running smartctrl test first and then 
> restart from scratch and fill it up with files or something.

Take it out the enclosure and it might be fine. I regularly have drives 
"die" in an enclosure and then work fine when I take them out.

That's why I bought an open bay - it's eSATA and the only bit of the 
drive that is enclosed is the connectors. Keeps the drive from cooking ...

Oh - the other thing - if it's PMR and you're copying files onto it, 
expect a puke! That thing on WD Reds going PMR, I copied most of that on 
to the linux raid mailing list and the general feeling I get is "PMR is 
bad".

Cheers,
Wol

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Rich Freeman]

On Sat, Jun 6, 2020 at 9:57 AM antlists <antlists@youngman.org.uk> wrote:
>
> Oh - the other thing - if it's PMR and you're copying files onto it,
> expect a puke! That thing on WD Reds going PMR, I copied most of that on
> to the linux raid mailing list and the general feeling I get is "PMR is
> bad".
>

You're mixing up PMR/SMR there.  PMR=CMR=the way things have been for
the last few decades.  SMR is the new shingled technology.

There is nothing wrong with it per se, but it is NOT a drop-in
substitute for all applications.  It works best if it is host-managed
with a filesystem or application that was engineered specifically to
use it.

If you tried to swap a hard drive with a tape drive you'd have
terrible results 99% of the time, but that doesn't make tape drives a
bad thing.  They just aren't drop-in substitutes for hard drives and
you need to use them with appropriate applications.

One of the problems with drive-managed SMR is that it can seem to be
ok when you're just doing light duty access, and then when one of your
other drives fails and you're doing a zfs resilver the SMR drive
starts performing an order of magnitude or more worse and you find
yourself painted in to a corner.

-- 
Rich

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Jack]

On 6/6/20 10:10 AM, Rich Freeman wrote:
> One of the problems with drive-managed SMR is that it can seem to be
> ok when you're just doing light duty access, and then when one of your
> other drives fails and you're doing a zfs resilver the SMR drive
> starts performing an order of magnitude or more worse and you find
> yourself painted in to a corner.

The first time I read that, I saw "....and you find yourself pained into 
a corner."  I suppose that's also true.

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[antlists]

On 06/06/2020 14:57, antlists wrote:
> Oh - the other thing - if it's PMR and you're copying files onto it, 
> expect a puke! That thing on WD Reds going PMR, I copied most of that on 
> to the linux raid mailing list and the general feeling I get is "PMR is 
> bad".
Whoops have I got my PMR and SMR mixed up ... ?

Cheers,
Wol

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Dale]

[-- Attachment #1: Type: text/plain, Size: 2538 bytes --]

antlists wrote:
> On 06/06/2020 08:49, Dale wrote:
>> First drive seems to have died.  Got part way copying files and
>> things got interesting.  When checking smartctrl, it even puked on my
>> keyboard.  Drive only had a few hundred hours on it so maybe the
>> drive was iffy from the start or that enclosure did damage somehow.
>> Either way, drive two being tested.  Running smartctrl test first and
>> then restart from scratch and fill it up with files or something.
>
> Take it out the enclosure and it might be fine. I regularly have
> drives "die" in an enclosure and then work fine when I take them out.
>
> That's why I bought an open bay - it's eSATA and the only bit of the
> drive that is enclosed is the connectors. Keeps the drive from cooking
> ...
>
> Oh - the other thing - if it's PMR and you're copying files onto it,
> expect a puke! That thing on WD Reds going PMR, I copied most of that
> on to the linux raid mailing list and the general feeling I get is
> "PMR is bad".
>
> Cheers,
> Wol
>
>


I may test it later by connecting it directly to the SATA card but I
suspect the drive is bad.  I managed to get the selftest data from the
drive once after several tries and it had a lot of failures.  It had
more than one type of error as well.  At this point, I don't see me
trusting any data on it anyway.  The first type of enclosure I think is
just cheaply made.  The new types, rock solid. 

Read other replies, yea, SMR isn't good for my use case.  I do have a
external drive that I do incremental backups on that is SMR.  It works
OK but the other day I had a rather large list of new files.  It got a
little slow toward the end.  I suspect its PMR section got full.  It
eventually finished but I did notice a slow down, a good sized one. 
Avoiding SMR like its the plague. 

Reading other replies, some two or three times.  ;-)  Lots of good
info.  I'm wanting to encrypt /home but also want another drive that
when I'm gone, it is no longer accessible.  A person can dd the drive or
something and start over but not access the data on it.  Right now, the
3TB will be more than enough for that. 

Thanks to all for the info.  Getting new reading glasses today.  Should
have new prescription glasses this coming week, hope anyway.  Sometimes
it takes a while to get the lenses made.  They have to use a really
complicated process.  I think each lens costs around $200.  My eyes
aren't much to work with.  Basically, I'm more cyclops, just in the
right place.  :/

Dale

:-)  :-)

[-- Attachment #2: Type: text/html, Size: 3312 bytes --]

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[J. Roeleveld]

On 6 June 2020 17:07:37 CEST, Dale <rdalek1967@gmail.com> wrote:
>antlists wrote:
>> On 06/06/2020 08:49, Dale wrote:
>>> First drive seems to have died.  Got part way copying files and
>>> things got interesting.  When checking smartctrl, it even puked on
>my
>>> keyboard.  Drive only had a few hundred hours on it so maybe the
>>> drive was iffy from the start or that enclosure did damage somehow.
>>> Either way, drive two being tested.  Running smartctrl test first
>and
>>> then restart from scratch and fill it up with files or something.
>>
>> Take it out the enclosure and it might be fine. I regularly have
>> drives "die" in an enclosure and then work fine when I take them out.
>>
>> That's why I bought an open bay - it's eSATA and the only bit of the
>> drive that is enclosed is the connectors. Keeps the drive from
>cooking
>> ...
>>
>> Oh - the other thing - if it's PMR and you're copying files onto it,
>> expect a puke! That thing on WD Reds going PMR, I copied most of that
>> on to the linux raid mailing list and the general feeling I get is
>> "PMR is bad".
>>
>> Cheers,
>> Wol
>>
>>
>
>
>I may test it later by connecting it directly to the SATA card but I
>suspect the drive is bad.  I managed to get the selftest data from the
>drive once after several tries and it had a lot of failures.  It had
>more than one type of error as well.  At this point, I don't see me
>trusting any data on it anyway.  The first type of enclosure I think is
>just cheaply made.  The new types, rock solid. 
>
>Read other replies, yea, SMR isn't good for my use case.  I do have a
>external drive that I do incremental backups on that is SMR.  It works
>OK but the other day I had a rather large list of new files.  It got a
>little slow toward the end.  I suspect its PMR section got full.  It
>eventually finished but I did notice a slow down, a good sized one. 
>Avoiding SMR like its the plague. 
>
>Reading other replies, some two or three times.  ;-)  Lots of good
>info.  I'm wanting to encrypt /home but also want another drive that
>when I'm gone, it is no longer accessible.  A person can dd the drive
>or
>something and start over but not access the data on it.  Right now, the
>3TB will be more than enough for that. 
>
>Thanks to all for the info.  Getting new reading glasses today.  Should
>have new prescription glasses this coming week, hope anyway.  Sometimes
>it takes a while to get the lenses made.  They have to use a really
>complicated process.  I think each lens costs around $200.  My eyes
>aren't much to work with.  Basically, I'm more cyclops, just in the
>right place.  :/
>
>Dale
>
>:-)  :-)

One thing to add to this: Encryption keys are stored in memory (or else it doesn't work)
This can also be leaked to disk (SWAP, for instance).

I tend to either encrypt it all (apart from the boot partition) or don't bother at all.
For me, it depends in how and where the system is used. Laptops travel with me and if they can be physically compromised, they get reinstalled with a fully new encryption key. Normally, the laptop is fully switched off when nog in use and the boot process, on the encrypted section, will check the boot partition with a known clean state. If it fails that check, there is a big warning and several services will fail to start.

--
Joost
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Victor Ivanov]

[-- Attachment #1.1: Type: text/plain, Size: 3046 bytes --]

On 06/06/2020 05:37, Dale wrote:
> One other question, can one change the password every once in a while? 
> Or once set, you stuck with it from then on? 

A point I forgot to mention in my previous email is regarding passwords.
While most encryption methods will allow for a password change (CryFS
doesn't) be mindful that with methods used to encrypt large amounts of
data the actual encryption key is generated once at volume creation time
and is never changed. A password is only used to decrypt/derive the key
itself.

This is purely due to practical considerations. If you change the actual
encryption key, then all encrypted data will have to be decrypted with
the old key and re-encrypted with the new key. This may be a perfectly
reasonable thing to do for file-based encryption or small amounts of
data where a password change also means a key change, but is completely
infeasible for larger scale volume encryption that may contain hundreds
of GB of data.

Thus, if a password has been compromised, it is not unreasonable to
assume that anyone who knows the password and has had access to the
encrypted volume might be able to get [or has already got] hold of the
encryption key itself once the volume was opened. Hence, changing a
leaked password doesn't make a compromised volume secure again.

Of course, if it can be safely determined that a leaked password has not
yet been used to access the volume, a swift preemptive change of the
password will retain security.

There is one exception to this where an adversary has a copy of the
header (or similar) of the encryption volume. Here's a quick example
with LUKS. A LUKS volume has a ~2MB header which stores all (hashed)
passwords and the password-encrypted decryption key. The header can be
read and stored separately. In fact, it's good practice for one to back
up the header in case it ever gets corrupted (a corrupt header often
means saying goodbye to your data w/o a backup).

The problem here is that a leaked header immediately means a compromised
volume. An adversary who gets hold of the header can now spend as much
time as they would like to brute force a password (depending on password
strength) and derive the encryption key. Or if they have an (older) copy
of the header with a leaked password before it was changed they can get
hold of the encryption key with virtually no effort at all by using said
password. The only solution to a compromised header is full
re-encryption. Even having a rolling password won't change that.

Bottom line wrt passwords, one should not rely on or assume that having
the facility to change a password will keep their data safe. If using a
password, a strong password is a must.

Again, it boils down to the usual trade-offs, likelihood of physical
access, etc, etc. But I thought it an important point to note, as a
surprisingly large number of people I have spoken to before seem to be
unaware of this caveat (I'm not suggesting you are one of them).

Regards,
Victor


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Rich Freeman]

On Sat, Jun 6, 2020 at 10:07 AM Victor Ivanov <vic.m.ivanov@gmail.com> wrote:
>
> The problem here is that a leaked header immediately means a compromised
> volume. An adversary who gets hold of the header can now spend as much
> time as they would like to brute force a password (depending on password
> strength) and derive the encryption key. Or if they have an (older) copy
> of the header with a leaked password before it was changed they can get
> hold of the encryption key with virtually no effort at all by using said
> password. The only solution to a compromised header is full
> re-encryption. Even having a rolling password won't change that.

If you're talking about the drive header that is actually written to
disk, it is as secure as the entire drive is, since the drive contains
the header.  The whole point of full-disk encryption is to keep the
contents of the disk secure even if you lose physical possession of
the disk.

If the password can be brute-forced then the encryption is worthless.

Sure, if the attacker has a copy of the header they can spend as much
time as they wish brute-forcing it.  However, the same is true if they
have the entire disk, and that is precisely the scenario we're trying
to guard against.

If you're using LUKS the security of the system is only as secure as
your password(s).  LUKS uses a random key to encrypt the drive, and it
applies many rounds of encryption to your password to protect the
session key.  That will greatly slow down a brute force attack.
However, if your encryption key is "12345" then a brute force attack
is likely to succeed.

-- 
Rich

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Victor Ivanov]

[-- Attachment #1.1: Type: text/plain, Size: 2587 bytes --]

On 06/06/2020 19:51, Rich Freeman wrote:
> If you're talking about the drive header that is actually written to
> disk, it is as secure as the entire drive is, since the drive contains
> the header.

I never said it was any less secure. It would be daft to even assume
something like that as it's de facto the door to the encrypted data.

The point I was making is simply that it increases the risk of data
breach when a password is used, especially if (one of) the password(s)
has been or is subsequently compromised. After all, it's difficult to
remember passwords that are long enough and have high entropy. There are
also the practicals inconveniences of having to type a long password.

On 06/06/2020 19:51, Rich Freeman wrote:
> If the password can be brute-forced then the encryption is worthless.
> ...
> If you're using LUKS the security of the system is only as secure as
> your password(s).  LUKS uses a random key to encrypt the drive, and it
> applies many rounds of encryption to your password to protect the
> session key.  That will greatly slow down a brute force attack.
> However, if your encryption key is "12345" then a brute force attack
> is likely to succeed.

Hence my previous point on ensuring a strong password.

On 06/06/2020 19:51, Rich Freeman wrote:
> Sure, if the attacker has a copy of the header they can spend as much
> time as they wish brute-forcing it.  However, the same is true if they
> have the entire disk, and that is precisely the scenario we're trying
> to guard against.

Not true. A key file stored outside the header is arguably way more
secure than a password - there's no longer a single point of failure.
Then there is also the option of having a detached LUKS header that is
never written to the block device in the first place which effectively
leaves the adversary with a stolen brick.

Are any of the "more secure" setups inconvenient to use? Sure. And I
doubt the average person would be that paranoid to use a detached
header, which by itself introduces a whole lot of issues like how do you
store the header itself securely. I was merely emphasising the fact that
when using a password, having the facility to change the password can
give a false sense of security in a select number of cases, especially
if the password being used prioritises memorability over sophistication,
often leading to low entropy, and that this is particularly problematic
for leaked passwords as brute-forcing high entropy passwords is not
feasible anyway as per your own words.

Regards,
Victor


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Rich Freeman]

On Sat, Jun 6, 2020 at 3:38 PM Victor Ivanov <vic.m.ivanov@gmail.com> wrote:
>
> On 06/06/2020 19:51, Rich Freeman wrote:
> > Sure, if the attacker has a copy of the header they can spend as much
> > time as they wish brute-forcing it.  However, the same is true if they
> > have the entire disk, and that is precisely the scenario we're trying
> > to guard against.
>
> Not true. A key file stored outside the header is arguably way more
> secure than a password - there's no longer a single point of failure.
> Then there is also the option of having a detached LUKS header that is
> never written to the block device in the first place which effectively
> leaves the adversary with a stolen brick.

Maybe we're miscommunicating, but it seems like you're moving the
goalposts here.  My point remains:

The header is as secure as the disk.  If the disk is secure against
brute-force, then so is the header.

Your original point was, "The problem here is that a leaked header
immediately means a compromised volume."

This makes no sense.  The whole reason you're using encryption is to
protect the data if your disk is stolen/etc.  If they steal the disk
they get the header too.  So, if a leaked header means that your
volume is compromised, then a stolen disk does so as well, which means
your encryption is worthless.

Now, obviously if you don't store the key in the header or store the
header on the disk, that is more secure.  However, if the key isn't in
the header then a leaked header does not give an attacker any
opportunity to brute-force it, because there is nothing to brute
force.

There are many things that can be done to make the disk more secure,
like not using a memorable password or not storing the key on the
disk.  Obviously these sorts of solutions create additional problems
with key management, and if you solve them incorrectly then you might
actually reduce security.

> I was merely emphasising the fact that
> when using a password, having the facility to change the password can
> give a false sense of security

Sure, there is really no point in "rotating passwords" with LUKS.  If
somebody gets a copy of your disk then they effectively have a
snapshot of your password.  If you later change it the data they still
have a copy of what it used to be.

And if they do have the ability to periodically snapshot your header
and you keep changing your password, then they can bruteforce all your
passwords in parallel and if they obtain any of them they can decrypt
the drive, unless you change the session key and re-encrypt the drive.

With any of these things you have to understand your threat model.
For example, on my distributed filesystem I'm moving to encrypted
drives to protect me in case I have to dispose of a drive without the
opportunity to wipe it first.  To do this I'm just going to store my
keys on the root filesystem so that the systems can be booted without
interaction.  Obviously if somebody compromises the files with the
keys they can decrypt my drives, but this means that I just have to
protect a couple of SD cards which contain my root filesystems,
instead of worrying about each individual hard drive.  The drives
themselves end up being much more secure, because the password used to
protect each drive is random and long - brute-forcing the password
will be no easier than brute-forcing AES itself.  This doesn't protect
me at all if somebody breaks into my house and steals everything.

-- 
Rich

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Victor Ivanov]

[-- Attachment #1.1: Type: text/plain, Size: 3621 bytes --]

On 06/06/2020 21:12, Rich Freeman wrote:
> My point remains:
>
> The header is as secure as the disk.  If the disk is secure against
> brute-force, then so is the header.

I never said otherwise. This was, in fact, explicitly stated in my
concluding remarks of my original post where I say "If using a password,
a strong password is a must." It was also emphasised once more in my
response to your previous email, towards the end.

But it also doesn't mean that one might not want to take additional
preemptive steps following an attack, depending on the circumstances
surrounding the attack.

On 06/06/2020 21:12, Rich Freeman wrote:
> Maybe we're miscommunicating, but it seems like you're moving the
> goalposts here.
> ...
> Your original point was, "The problem here is that a leaked header
> immediately means a compromised volume."

I believe we're on the same page and it's indeed due to miscommunication
and I suspect this is where the main point of miscommunication lies.
You're taking my statement out of context. No doubt, I most certainly
could have phrased this part better and made it clearer. It may not have
been obvious but that sentence was aimed specifically in the context
where a weak password is used or, especially, when a password has been
compromised and how being able to change said password might have little
effect. In which case the point still stands - when a password is
compromised, there is a possibility that changing said password may not
necessarily be the end of the matter as the (old) header may or may not
have been leaked too either as part of the same or a previous attack -
not necessarily involving physical access.

On 06/06/2020 21:12, Rich Freeman wrote:
> The whole reason you're using encryption is to
> protect the data if your disk is stolen/etc.  If they steal the disk
> they get the header too.  So, if a leaked header means that your
> volume is compromised, then a stolen disk does so as well, which means
> your encryption is worthless.

This is probably another point of confusion. You make a strong case
about a stolen drive, but this was never a case I specifically argued
about. If the whole drive itself is stolen then there's little to
discuss as there's nothing that can be done post facto to mitigate the
circumstances, so any points raised re a leaked header or a change of
password can be thrown out of the window and the only hope in such a
scenario is that the password used is strong enough to safe guard
against guessing attacks. So this case is largely irrelevant re some of
the points I made.

Perhaps it seems that the goalpost moves because I never set one - my
original email was a _general discussion_ on the different
considerations that one might want to have if using a password and how
the ability to change a password may lead to a false sense of security.
Clearly, at the end of the day how exactly all these points fit together
is dependent on the threat model and what scenarios are more and less
likely to happen, which I also pointed out but perhaps not as clearly as
I should have. And so is the analysis, assessment of implications, and
steps to take following an attack.

The only time I referred to non-password methods (such as detached
header) was in response to your previous email re header security.
Retrospectively, I admit I too may have taken your point into a
different, more general direction that takes the discussion beyond the
scope of just passwords. For which I'm certainly liable.

I hope this clarifies the matter.

Best Regards,
Victor


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Rich Freeman]

On Sat, Jun 6, 2020 at 8:47 PM Victor Ivanov <vic.m.ivanov@gmail.com> wrote:
>
> On 06/06/2020 21:12, Rich Freeman wrote:
> > Maybe we're miscommunicating, but it seems like you're moving the
> > goalposts here.
> > ...
> > Your original point was, "The problem here is that a leaked header
> > immediately means a compromised volume."
>
> I believe we're on the same page and it's indeed due to miscommunication
> and I suspect this is where the main point of miscommunication lies.
> You're taking my statement out of context. No doubt, I most certainly
> could have phrased this part better and made it clearer. It may not have
> been obvious but that sentence was aimed specifically in the context
> where a weak password is used or, especially, when a password has been
> compromised and how being able to change said password might have little
> effect. In which case the point still stands - when a password is
> compromised, there is a possibility that changing said password may not
> necessarily be the end of the matter as the (old) header may or may not
> have been leaked too either as part of the same or a previous attack -
> not necessarily involving physical access.

I think we're on the same page and just talking past each other.  I
didn't catch that as being the intended context, and in the scenario
you describe you are of course completely correct.

Thanks for bringing this point up though, as it isn't really something
I'd given much thought to.

-- 
Rich

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Dale]

[-- Attachment #1: Type: text/plain, Size: 2909 bytes --]

Rich Freeman wrote:
> On Sat, Jun 6, 2020 at 8:47 PM Victor Ivanov <vic.m.ivanov@gmail.com> wrote:
>> On 06/06/2020 21:12, Rich Freeman wrote:
>>> Maybe we're miscommunicating, but it seems like you're moving the
>>> goalposts here.
>>> ...
>>> Your original point was, "The problem here is that a leaked header
>>> immediately means a compromised volume."
>> I believe we're on the same page and it's indeed due to miscommunication
>> and I suspect this is where the main point of miscommunication lies.
>> You're taking my statement out of context. No doubt, I most certainly
>> could have phrased this part better and made it clearer. It may not have
>> been obvious but that sentence was aimed specifically in the context
>> where a weak password is used or, especially, when a password has been
>> compromised and how being able to change said password might have little
>> effect. In which case the point still stands - when a password is
>> compromised, there is a possibility that changing said password may not
>> necessarily be the end of the matter as the (old) header may or may not
>> have been leaked too either as part of the same or a previous attack -
>> not necessarily involving physical access.
> I think we're on the same page and just talking past each other.  I
> didn't catch that as being the intended context, and in the scenario
> you describe you are of course completely correct.
>
> Thanks for bringing this point up though, as it isn't really something
> I'd given much thought to.
>


My take.  Bad password, easy to guess, easy to crack because it is
simple or common; not very secure even if the password is changed since
one could use the old password in certain situations and get at the
data.  Good strong password, changed or not; hard to crack even if the
whole drive is taken. 

Moral of the story.  Have a good strong password and keep your mouth
shut about what the password is, unless you want that person to spill
the beans.  Or you plan to knock them off later.  ROFLMBO

I'm not storing the secrets to some new weapon that will destroy the
world and everything on it, including the roaches.  Well, that last one
might be OK. lol  I just want it so that when I fall into the cremation
chamber or a cemetery plot, it won't be easy for a person to access the
drive.  I'm good at the keeping password to myself bit.  Still thinking
on killing all the roaches tho .  I'd keep that secure but I wouldn't
mind being rid of those.  :/ 

I think I need to watch a youtube video on this tho.  I want to watch a
person not only install it but actually use it.  For example, what
triggers it asking for a password and what does it look like?  Is it
pretty fast, take a few seconds or what?  I got a lot of questions but
they are things that can't be answered easily in text.  Yea, gotta go
visit youtube.  Test drive youtube-dl again. 

Dale

:-)  :-) 

[-- Attachment #2: Type: text/html, Size: 3674 bytes --]

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Dale]

[-- Attachment #1: Type: text/plain, Size: 3199 bytes --]

Dale wrote:
>
>
> My take.  Bad password, easy to guess, easy to crack because it is
> simple or common; not very secure even if the password is changed
> since one could use the old password in certain situations and get at
> the data.  Good strong password, changed or not; hard to crack even if
> the whole drive is taken. 
>
> Moral of the story.  Have a good strong password and keep your mouth
> shut about what the password is, unless you want that person to spill
> the beans.  Or you plan to knock them off later.  ROFLMBO
>
> I'm not storing the secrets to some new weapon that will destroy the
> world and everything on it, including the roaches.  Well, that last
> one might be OK. lol  I just want it so that when I fall into the
> cremation chamber or a cemetery plot, it won't be easy for a person to
> access the drive.  I'm good at the keeping password to myself bit. 
> Still thinking on killing all the roaches tho .  I'd keep that secure
> but I wouldn't mind being rid of those.  :/ 
>
> I think I need to watch a youtube video on this tho.  I want to watch
> a person not only install it but actually use it.  For example, what
> triggers it asking for a password and what does it look like?  Is it
> pretty fast, take a few seconds or what?  I got a lot of questions but
> they are things that can't be answered easily in text.  Yea, gotta go
> visit youtube.  Test drive youtube-dl again. 
>
> Dale
>
> :-)  :-) 


OK.  Found some videos and jeez, there is a ton of ways to use this. 
You can have a password, a key file, both or likely other options as
well.  On one video, the guy generated a key file with urandom that was
1024 characters.  As he put it, try typing that in.  Anyway, he put the
file in / and used the file to mount the thing automatically after some
setup. If however he goes to another puter, either you have to have that
key file on it to or type in the password.  He also set it up to mount
automatically. 

Then I found out about crypttab.  I don't have that on my system, yet. 
I was wondering how the system would know when a drive or partition was
encrypted or not.  Well, there you go.  Once crypttab and fstab are set
up, it can mount automatically.  Well neato.  ;-)

When watching a video or two, I had to google some things.  I run up on
zulucrypt.  It's a GUI that can handle several different encryption
tools.  Yes, one should at least be familiar with command line just in
case the GUI doesn't work but having a GUI does make it easier. 

I still don't think I'm ready to try and do this on a hard drive.  I'm
certainly not going to do this with /home yet.  Between this thread and
a few videos, pictures says a lot, it's starting to make sense.  I also
noticed, it is really fast.  One may need a stopwatch to even notice it
is encrypted at all. 

I notice that one can use different encryption tools.  I have Blowfish,
Twofish, AES and sha*** as well as many others.  I know some have been
compromised.  Which ones are known to be secure?  I seem to recall that
after Snowden some had to be redone and some new ones popped up to make
sure they were secure.  Thoughts??

Dale

:-)  :-) 

[-- Attachment #2: Type: text/html, Size: 4071 bytes --]

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[antlists]

On 07/06/2020 09:08, Dale wrote:
> I notice that one can use different encryption tools.  I have Blowfish, 
> Twofish, AES and sha*** as well as many others.  I know some have been 
> compromised.  Which ones are known to be secure?  I seem to recall that 
> after Snowden some had to be redone and some new ones popped up to make 
> sure they were secure.  Thoughts??

Some had to be redone ... Elliptic Cryptograph Curve or whatever it's 
called. The basic maths is secure, but the NSA got a standard released 
(you have to pick a set of constants) where the constants had been 
nobbled. DJB has released a different set of constants (ECD25519) which 
is thought to be secure.

I think it was LWN, there was an interesting article on crypto recently.

Cheers,
Wol

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[antlists]

On 07/06/2020 10:07, antlists wrote:
> I think it was LWN, there was an interesting article on crypto recently.

https://lwn.net/Articles/821544/

Cheers,
Wol

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Dale]

[-- Attachment #1: Type: text/plain, Size: 1858 bytes --]

antlists wrote:
> On 07/06/2020 10:07, antlists wrote:
>> I think it was LWN, there was an interesting article on crypto recently.
>
> https://lwn.net/Articles/821544/
>
> Cheers,
> Wol
>
>


Looks like they are getting ready to toss sha1 overboard.  If it is not
secure, they should.  At least most people who should know, already know
it is not secure.  I didn't have the details but I knew something was
hacked and asked to be sure.  I ended up using a AES one.  I did set up,
using zulucrypt at the moment, to encrypt a 3TB external hard drive.  So
far, it is working fine.  I've closed it a few times and opened it a few
times. 

The one thing I have not figure out yet, about to look into it, how to
mount it to a place I pick.  It's likely a setting I haven't noticed yet
but I'll find it.  Still not ready to even think of doing /home yet
tho.  That's a doozy.  I guess first I'd have to move everything off the
drives it's currently on, encrypt that drive and then move everything
back.  Another thing, having a secure password that is easy to type and
remember but can't be guesses.  Anyone remember the thread when I came
up with a password for PGP and LastPass a year or so ago???  It took me
a month to accomplish that but it is a good one.  Then I got a cell
phone.  Easy to type on the keyboard, not so much on the cell phone
tho.  Still, it works well.  It is a good one.  Good luck to anyone
trying to guess it or even hack it.  lol 

I wish my other drive would have worked.  I'd like to be able to compare
things.  They are both the same brand and size.  Likely even the same
model.  But it has some serious issues.  Even smartctrl was having
trouble chatting with the drive.  That's bad. 

May redo the drive but with command line tools this go around.  Just for
giggles. 

Thanks again.

Dale

:-)  :-) 

[-- Attachment #2: Type: text/html, Size: 2634 bytes --]

Re: [gentoo-user] Encrypting a hard drive's data. Best method. PICS attached

[Dale]

[-- Attachment #1.1: Type: text/plain, Size: 624 bytes --]

Dale wrote:
>
> May redo the drive but with command line tools this go around.  Just
> for giggles. 
>
> Thanks again.
>
> Dale
>
> :-)  :-) 


For those who are curious, or run up on this thread, this is the
encryption options I'm seeing for zulucrypt.  I can't figure out how to
list them so I'm attaching a picture of the options.  It takes three
images and I think I got them all.  I also can't figure out how to add
options.  There's no USE flags that would change it and I can't find a
config option either. 

I plan to do this with command line tools next.  Hope this info helps
someone.

Dale

:-)  :-) 

[-- Attachment #1.2: Type: text/html, Size: 1261 bytes --]

[-- Attachment #2: 2020-06-09-15-23-47-0001-scale.JPG --]
[-- Type: image/jpeg, Size: 348634 bytes --]

[-- Attachment #3: 2020-06-09-15-24-04-0002-scale.JPG --]
[-- Type: image/jpeg, Size: 331148 bytes --]

[-- Attachment #4: 2020-06-09-15-24-26-0003-scale.JPG --]
[-- Type: image/jpeg, Size: 359271 bytes --]

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Rich Freeman]

On Sun, Jun 7, 2020 at 4:08 AM Dale <rdalek1967@gmail.com> wrote:
>
> I still don't think I'm ready to try and do this on a hard drive.  I'm certainly not going to do this with /home yet.

If you have a spare drive or just a USB stick lying around, set it up
on that.  Then you can test that it mounts on boot and prompts for a
password and all that stuff.

Or you can use a loopback filesystem using a file on your hard drive.
That is pretty safe as long as you don't enter "/bin/bash" as your
loopback filename or whatever.  I'm not sure if that will correctly
mount itself automatically at boot though, as I'm not sure if the
various service dependencies are set up to handle it (the drive
containing the file has to be mounted first).

> I notice that one can use different encryption tools.  I have Blowfish, Twofish, AES and sha*** as well as many others.

I'd stick with AES.  If you're trying to keep the NSA out of your hard
drive and you think they're part of a conspiracy to get people to use
AES despite having cracked it, then I don't know what to tell you
because they're probably going to get you no matter what you do...  :)

AES is probably the most mainstream crypto system out there and is
considered very secure.  It is also widely supported by hardware and
all recent Intel/AMD CPUs.  128-bit keys are the most standard.  Linux
supports 256-bit though if you use that I'm not sure if
hardware-acceleration is available.

-- 
Rich

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Victor Ivanov]

[-- Attachment #1.1: Type: text/plain, Size: 4882 bytes --]

On 07/06/2020 09:08, Dale wrote:
> You can have a password, a key file, both or likely other options as
> well.  On one video, the guy generated a key file with urandom that was
> 1024 characters.  As he put it, try typing that in.

Indeed! All of these techniques have various pros/cons which is partly
why my last reply  / novel ended up being long yet still shallow.

A key file would, generally, be more secure provided you can keep the
medium on which it is stored secure as well. A long and strong password
doesn't have to be difficult to type though. A lot of 2FA dongles, such
as the YubiKey will allow for one (or more) of its key slots to be
programmed in plain text. If you have one, this would allow you to
effectively "paste" a very long password in less than a second. Then
again, you will have to keep your dongle secure as well, as plain text
means anyone can "paste" the password into a text file. Again, pros/cons
of the strategy.

On 07/06/2020 09:08, Dale wrote:
> Then I found out about crypttab.  I don't have that on my system, yet.

Crypttab is the standard on most distributions. Gentoo, however, uses
"/etc/conf.d/dmcrypt". Personally, I find its syntax less of an eyesore
and more favourable, but it does effectively the same thing. And the
comments inside it are even better than a man page haha

On 07/06/2020 09:08, Dale wrote:
> I still don't think I'm ready to try and do this on a hard drive.

Don't let any of that discourage you :) It's a lot simpler than it may
seem, and most desktop environments (I believe you we using KDE?) have
excellent support for mounting and unmounting/ejecting encrypted volumes
both internal, as well as removable, once the LUKS container has been
set up.

The guide [1] (also linked to earlier) is comprehensive, but
fundamentally the most relevant part for getting started are steps
2.3-2.5. If you use genkernel, with LUKS="yes" in the config it will
have taken care of the kernel for you and even created a initramfs
suitable for an encrypted root.

As Rich suggested try it out with a flash drive or a loopback file.

On a side note re drives, if using LUKS with an SSD you may or may not
wish to keep trimming disabled, as it may lead to leaked data regarding
the blocks being trimmed [2]. For this reason, trim pass-through is left
OFF by default. The leaked information, however, is minimal and I doubt
it poses any significant risk for the average use case.

On 07/06/2020 09:08, Dale wrote:
> I notice that one can use different encryption tools.  I have Blowfish,
> Twofish, AES and sha***

Bear in mind not all of the items listed are encryption algorithms per
se. The SHA and Argon families are hashing algorithms/functions used to
hash your password and store it an obfuscated form. They are also used
as HMAC functions in the context of encrypted data exchange. The key
thing is that hash functions are one-way. That is, it's computationally
straightforward to create the hash of a given input, but computationally
infeasible to reverse the process. They do not use a a separate
encryption key, and the result is always deterministic and reproducible.

I would stick with SHA as its widely supported. Except for sha1 which
was cracked a few years back. If you choose sha256 or better yet sha512
you can't go wrong.

Argon2 is a great choice, but if I'm not mistaken it's only supported by
LUKS2 which Gentoo only recently made the default. I believe most
current distros have LUKS2 by default, but older ones, including some
LTS versions and distros with release cycles of once per century or so
may not support that, so for removable drives I would stick to LUKS1.

On 07/06/2020 11:33, Rich Freeman wrote:
> AES is probably the most mainstream crypto system out there and is
> considered very secure.  It is also widely supported by hardware and
> all recent Intel/AMD CPUs.

Indeed. I second Rich and too would recommend sticking with AES for this
reason. LUKS will support an AES key of up to 512 bits. It's fast and
hardware acceleration is widely available.

For example, Intel's native AES  extensions work in 4x4 data blocks of
128 bits but will support variable key lengths. Their white paper [3]
suggests supported key lengths are 128, 192, and 256 bits but I've been
using a 512 bit key on my drives for years with negligible performance
impact (Skylake systems). But since data block size is fixed, this
hardly surprising. Acceleration of key length > 128b then only becomes
relevant at key generation time which is a one-time step, so the cost of
this step becomes largely irrelevant.

[1] https://wiki.gentoo.org/wiki/Dm-crypt
[2] http://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html
[3]
https://www.intel.com/content/dam/doc/white-paper/enterprise-security-aes-ni-white-paper.pdf


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Victor Ivanov]

[-- Attachment #1.1: Type: text/plain, Size: 1440 bytes --]

On 07/06/2020 12:52, Victor Ivanov wrote:
> Indeed. I second Rich and too would recommend sticking with AES for this
> reason. LUKS will support an AES key of up to 512 bits. It's fast and
> hardware acceleration is widely available.
>  ...
> For example, Intel's native AES  extensions work in 4x4 data blocks of
> 128 bits but will support variable key lengths. Their white paper [3]
> suggests supported key lengths are 128, 192, and 256 bits but I've been
> using a 512 bit key on my drives for years with negligible performance
> impact (Skylake systems).

Perhaps this requires extra clarification re key length, which I should
have included, as it may give misleading information.

As an algorithm AES fundamentally only goes up to 256 bits for key
length. However, in XTS mode (aes-xts) two _separate_ keys are used for
the initialisation vector and the block encryption. As such, for AES-256
in XTS mode, one needs to supply 2x256b keys.

Effectively, 512b are used, but this too may be misleading. It's better
than 1x256b but certainly not as good as 1x512: (2^256 + 2^256) vs
2^512. It also maps well to hardware extensions already supporting key
sizes of 256b.

This is not possible in CBC or GCM mode which only allows for a single
key of up to 256b.

My apologies, it was a case of my fingers getting ahead of my thoughts
and not having formulating the latter appropriately.

Regards,
Victor


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[antlists]

On 06/06/2020 21:12, Rich Freeman wrote:
>   To do this I'm just going to store my
> keys on the root filesystem so that the systems can be booted without
> interaction.  Obviously if somebody compromises the files with the
> keys they can decrypt my drives, but this means that I just have to
> protect a couple of SD cards which contain my root filesystems,
> instead of worrying about each individual hard drive.  The drives
> themselves end up being much more secure, because the password used to
> protect each drive is random and long - brute-forcing the password
> will be no easier than brute-forcing AES itself.  This doesn't protect
> me at all if somebody breaks into my house and steals everything.

On the other hand, if you're always present at boot, stick the keys on a 
USB that has to be in the laptop when it starts. If that's on your 
(physical) keyring, chances are it won't be compromised at the same time 
as the laptop - and hopefully the attacker won't realise it's needed for 
boot :-)

(yes I know - security through obscurity is bad as your MAIN defence, 
but a few layers on top of something secure just makes life more of a 
pain for an attacker :-)

Cheers,
Wol

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Frank Steinmetzger]

[-- Attachment #1: Type: text/plain, Size: 3559 bytes --]

On Fri, Jun 05, 2020 at 11:37:23PM -0500, Dale wrote:
> Howdy,
> 
> I think I got a old 3TB hard drive to work.  After dd'ing it, redoing
> partitions and such, it seems to be working.  Right now, I'm copying a
> bunch of data to it to see how it holds up.  Oh, it's a PMR drive too. 
> lol  Once I'm pretty sure it is alive and working well, I want to play
> with encryption.  At some point, I plan to encrypt /home.  I found a bit
> of info with startpage but some is dated.  This is one link that seems
> to be from this year, at least updated this year. 

Encryption is a means to protect against adversaries, but in my case I
mostly want to protect from incidental access. My top “use” cases:
- I need to send in a broken disk for service/replacement
- $DEVICE is stolen and I dont’t want the thief to access my personal stuff
- the device needs to be serviced, but has its storage soldered on
- protect from recovery on flash storage

I’ve been running full-disk encryption with LUKS/LVM for some years now on
my laptop’s SSD. I used Sakaki’s scripts to set up the kernel and initrd.
The encryption password is entered during the boot process while still in
the initrd phase. I don’t know of the current status of Sakaki’s stuff
though (I must admit I moved away from Gentoo because portage took to much
time on the laptop).

On my main PC I used to have ~ on a hard disk and / on an SSD. So I left /
unencrypted and symlinked sensitive files such as wpa_supplicant.conf and
database files onto a directory beneath /home. Since decryption is done
early at boot, there is no race condition. By now I upgraded the SSD and
have both / and ~ on it, but I kept the scheme out of laziness.

A week ago I got me and myself a used Surface Go (a little X86 tablet) which
only has a small SSD soldered onto the board. There is no way to access or
replace it. I didn’t want to use the same approach as with the laptop,
because I wanted to be able to boot without a keyboard. This meant that PW
entry at early boot was no option because there is no touch support at this
stage. So I researched a little towards decryption at login. Ext4-internal
encryption was a strong contender, because it allowed me to decrypt ~ on
login, while still using a shared partitions for / and ~, which would give
me more flexibility on the constrained SSD. It also encrypts filenames, but
not access times (which I was OK with). Eventually though, I decided to go
for more encapsulation and put ~ on a separate partition again. I set it up
with LUKS and auto-mount it on login with pam_mount.

On a performance not: the Surface Go has an NVME SSD and hdparm -t varies
wildly between 220 and 640 MB/s. OTOH, cryptsetup benchark resulted in 1330
MiB/s for aes-cbc with a 128 bit key. Aes-xts was slower, but once I
disabled all kernel mitigations¹, its throughput went up by more than 40 %
and also reached 1300 MiB/s. And this is for the meagre Pentium Gold
processor. So no worries in that department.


¹ Many of those vulnerabilities are about violating memory boundaries, which
is most relevant for server operators and securing their users from each
other. Thus, I don’t care about those on my personal machines and rather
have the original performance. Exploits need to get *on* my machines first
before they can snoop in my memory.

-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me on any social network.

I hate being bi-polar.  It’s fantastic!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Sebastiaan L. Zoutendijk]

Dear Dale,

    On Friday 5 June 2020, 11.37pm -0500, Dale wrote:

> Is this a secure method or is there a more secure way?  Is there any
> known issues with using this?  Anyone here use this method?  Keep in
> mind, LVM.  BTFRS, SP?, may come later.

    Another thing to keep in mind: if you only encrypt your /home, it is
possible  that some data leak out of the encrypted volume. For  example,
if  you  use swap, then the decrypted contents of /home residing in  RAM
can  be  swapped out. If you want to protect yourself against that,  you
will need to encrypt the swap volume as well. The same could happen with
temporary files, so /tmp and /var/tmp might also need special treatment.
Aside from encrypting, tmpfs is another possibility here.
    This  problem is similar, but slightly different, to that  described
by  J.  Roeleveld.  Here I am talking about the contents of  your  files
leaking, instead of the LUKS keys.
    If  you  are going to encrypt multiple filesystems, you  can  either
make  separate  LUKS  volumes for each of them (each LUKS  volume  being
inside  a  partition or LVM volume, for example), or you can create  one
LUKS volume with several LVM volumes inside.

                                                              Sincerely,

                                                                 Bas


--
Sebastiaan L. Zoutendijk | slzoutendijk@gmail.com

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Dale]

[-- Attachment #1: Type: text/plain, Size: 1862 bytes --]

Sebastiaan L. Zoutendijk wrote:
> Dear Dale,
>
>     On Friday 5 June 2020, 11.37pm -0500, Dale wrote:
>
>> Is this a secure method or is there a more secure way?  Is there any
>> known issues with using this?  Anyone here use this method?  Keep in
>> mind, LVM.  BTFRS, SP?, may come later.
>     Another thing to keep in mind: if you only encrypt your /home, it is
> possible  that some data leak out of the encrypted volume. For  example,
> if  you  use swap, then the decrypted contents of /home residing in  RAM
> can  be  swapped out. If you want to protect yourself against that,  you
> will need to encrypt the swap volume as well. The same could happen with
> temporary files, so /tmp and /var/tmp might also need special treatment.
> Aside from encrypting, tmpfs is another possibility here.
>     This  problem is similar, but slightly different, to that  described
> by  J.  Roeleveld.  Here I am talking about the contents of  your  files
> leaking, instead of the LUKS keys.
>     If  you  are going to encrypt multiple filesystems, you  can  either
> make  separate  LUKS  volumes for each of them (each LUKS  volume  being
> inside  a  partition or LVM volume, for example), or you can create  one
> LUKS volume with several LVM volumes inside.
>
>                                                               Sincerely,
>
>                                                                  Bas
>
>
> --
> Sebastiaan L. Zoutendijk | slzoutendijk@gmail.com
>
>


That's something to think on.  Right now, I'm going sorta simple and
data that if I forget the password, I still got copies of.  No big
loss.  Later on tho, that info could come in handy.  I know a guy that
has his locked down tight.  I suspect everything is password protected. 
He was in China for a bit and it was sort of a requirement. 

Off to youtube.

Dale

:-)  :-) 

[-- Attachment #2: Type: text/html, Size: 2440 bytes --]

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Dale]

[-- Attachment #1: Type: text/plain, Size: 1083 bytes --]

Howdy,

Same topic just new question.  I use KDE and am wanting to have it so
the Device Notifier will allow me to mount the drive when I turn it on. 
So far, I got it set up and when I turn the drive on and click for it to
mount it, it asks me for a password.  I type in the password but it
mounts it to the wrong place.  If I do it on the command line, it works
as expected.  I have it set up in dmcrypt and fstab.  So, command line
works, KDE's Device Notifier doesn't.  It tells me I don't have
permission to access but it also mounts it in the wrong place.  I
suspect it mounting it in the wrong place leads to the permissions
error.  It mounts under /run.  I want it mounted under /home.

How do I tell the Device Notifier that I want it mounted somewhere
else?  I've never done this part before since I let everything else
mount under /run.  My cameras, cell phone, card reader and such mounts
under it.  That's fine for those.  This I want to mount under /home tho. 

Is this doable?  Is there another tool KDE needs to do this? 

Thanks.

Dale

:-)  :-) 

[-- Attachment #2: Type: text/html, Size: 1405 bytes --]

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Michael]

[-- Attachment #1: Type: text/plain, Size: 2074 bytes --]

On Wednesday, 10 June 2020 07:59:19 BST Dale wrote:
> Howdy,
> 
> Same topic just new question.  I use KDE and am wanting to have it so
> the Device Notifier will allow me to mount the drive when I turn it on. 

I probably missed in earlier threads, but is this is an externally powered USB 
device?


> So far, I got it set up and when I turn the drive on and click for it to
> mount it, it asks me for a password.

Where do you "click for it"?


> I type in the password but it mounts it to the wrong place.  

Please define "wrong place".


> If I do it on the command line, it works  as expected.  

What is expected?


> I have it set up in dmcrypt and fstab.  So, command line
> works, KDE's Device Notifier doesn't.

For the avoidance of doubt:

"command line" = /bin/mount

"KDE's Device Notifier" = /usr/bin/udisksctl

There is a difference between the two:

$ ls -la /bin/mount
-rws--x--x 1 root root 56360 May 11 00:25 /bin/mount

$ ls -la /usr/bin/udisksctl 
-rwxr-xr-x 1 root root 60496 Nov 23  2019 /usr/bin/udisksctl


You run mount as root with temporarily elevated privileges and operate on 
devices directly via the kernel, but can only mount such block devices if they 
have a corresponding /etc/fstab entry - unless you are root.

You run udisksctl as plain user - it is a userspace command which operates on 
the udisks daemon to manipulate mountable devices via D-Bus.  The default 
mountpoint by udisksctl is under /run/media/<user_name>/LABEL


> It tells me I don't have
> permission to access but it also mounts it in the wrong place.  I
> suspect it mounting it in the wrong place leads to the permissions
> error.  It mounts under /run.  I want it mounted under /home.

You may be able to achieve this via udev rules for the specific UUID of the 
disk, or perhaps via a symlink from /home to the /run mountpoint.  I haven't 
tested this, but you could give it a spin and see what you get.

PS. You can ignore my earlier questions, no need to answer them.  The 
structure of your message was perhaps back to front to assist my 
understanding.  :-)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Dale]

[-- Attachment #1: Type: text/plain, Size: 3299 bytes --]

Michael wrote:
> On Wednesday, 10 June 2020 07:59:19 BST Dale wrote:
>> Howdy,
>>
>> Same topic just new question.  I use KDE and am wanting to have it so
>> the Device Notifier will allow me to mount the drive when I turn it on. 
> I probably missed in earlier threads, but is this is an externally powered USB 
> device?
>

Not USB but eSATA. 

>> So far, I got it set up and when I turn the drive on and click for it to
>> mount it, it asks me for a password.
> Where do you "click for it"?

The Device Notifier in the KDE panel thingy.  I use it to access my
cameras, SD cards put in my card reader and even my cell phone. 


>
>
>> I type in the password but it mounts it to the wrong place.  
> Please define "wrong place".
>

It mounts under /run.  I want it mounted under /home. 


>> If I do it on the command line, it works  as expected.  
> What is expected?
>

I was expecting it to mount from the Device Notifier just like it does
from the command line.

>> I have it set up in dmcrypt and fstab.  So, command line
>> works, KDE's Device Notifier doesn't.
> For the avoidance of doubt:
>
> "command line" = /bin/mount
>
> "KDE's Device Notifier" = /usr/bin/udisksctl
>
> There is a difference between the two:
>
> $ ls -la /bin/mount
> -rws--x--x 1 root root 56360 May 11 00:25 /bin/mount
>
> $ ls -la /usr/bin/udisksctl 
> -rwxr-xr-x 1 root root 60496 Nov 23  2019 /usr/bin/udisksctl
>
>
> You run mount as root with temporarily elevated privileges and operate on 
> devices directly via the kernel, but can only mount such block devices if they 
> have a corresponding /etc/fstab entry - unless you are root.
>
> You run udisksctl as plain user - it is a userspace command which operates on 
> the udisks daemon to manipulate mountable devices via D-Bus.  The default 
> mountpoint by udisksctl is under /run/media/<user_name>/LABEL
>

True but since I'm wanting to mount it under the same /home directory as
the user doing the mounting, it shouldn't require any additional
privileges. 


>> It tells me I don't have
>> permission to access but it also mounts it in the wrong place.  I
>> suspect it mounting it in the wrong place leads to the permissions
>> error.  It mounts under /run.  I want it mounted under /home.
> You may be able to achieve this via udev rules for the specific UUID of the 
> disk, or perhaps via a symlink from /home to the /run mountpoint.  I haven't 
> tested this, but you could give it a spin and see what you get.
>
> PS. You can ignore my earlier questions, no need to answer them.  The 
> structure of your message was perhaps back to front to assist my 
> understanding.  :-)


No problem.  Sometimes when anyone is writing, it's assumed that
everyone else knows the steps that are taken.  Usually that is not the
case.  It's why we always ask for error messages, commands used etc etc
etc.  ;-)

Based on everything I've found with google, I think the Device Notifier
is badly limited.  It can get to a certain point but it can't go any
further.  It seems we need a better tool or the current tool needs a
little extra programming.  I was wanting to avoid the command line part
in case something happened to me and someone needed to access a
encrypted device.  Victor seems to confirm that with his reply. 

Thanks.

Dale

:-)  :-)

[-- Attachment #2: Type: text/html, Size: 5102 bytes --]

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Victor Ivanov]

[-- Attachment #1.1: Type: text/plain, Size: 2639 bytes --]

On 10/06/2020 07:59, Dale wrote:
> It tells me I don't have permission to access but it also mounts it

This KDE bug re Device Notifier has been present for a long time and
it's seriously infuriating. Mounting from Dolphin, on the other hand,
seems to work just fine, though it too doesn't miss the opportunity to
complain about privileges.

It's not a Gentoo specific issue, as I've experienced this on other
distros too. I believe there was an upstream bug report that kept
getting resolved and reopened.

On 10/06/2020 07:59, Dale wrote:
> I type in the password but it mounts it to the wrong place.
This is normal. By default, volumes mounted from userspace will be
mounted under "/run/media/<uid>/<volume name>". This makes sense and is
entirely due to user privileges. Mounting under other directories would
require escalation of privileges. But most basic UI features are
designed for the most common scenario.

On 10/06/2020 07:59, Dale wrote:
> How do I tell the Device Notifier that I want it mounted somewhere
> else?
From KDE you can't and there's no KDE-specific tool to allow you to do
that. But you can add the UUID of the filesystem to /etc/fstab and KDE
will then mount it under that location. However, make sure that the UUID
is that of the open volume, not the encrypted container.

For example, if you manually open the encrypted volume via the command
line, e.g.:

  # cryptsetup open /dev/sdz1 crypto_volume_name

This will ask you for the encryption password and, if correct, will
create a new block device "/dev/mapper/crypto_volume_name".

You can then get the UUID of "/dev/mapper/crypto_volume_name" with:

  # blkid /dev/crypto_volume_name

At this point you can close your LUKS container via:

  # cryptsetup close crypto_volume_name

You can bypass steps 1 and 3 above by mounting via the KDE as usual,
which will automatically create the block device
"/dev/mapper/luks_abcdef1234". You can then get its UUID via step 2 and
replace step 3 by ejecting the mounted volume.

Finally, add this UUID to /etc/fstab in the usual way:

UUID=<uuid from step2> /dst/mount/dir <fstype> [mount_options],user 0 0

Note "user" under mount options. This is critical to making it work
seamlessly from KDE, otherwise it will require escalation of privileges
to mount the volume.

Once you do the above, the volume should automatically be mounted under
"/dst/mount/dir" the next time you mount it via Dolphin or Device Notifier.

It still won't get rid of the annoying "You don't have permissions"
error message, but it does work.

Hope this helps.

- Victor


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Dale]

[-- Attachment #1: Type: text/plain, Size: 3410 bytes --]

Victor Ivanov wrote:
> On 10/06/2020 07:59, Dale wrote:
>> It tells me I don't have permission to access but it also mounts it
> This KDE bug re Device Notifier has been present for a long time and
> it's seriously infuriating. Mounting from Dolphin, on the other hand,
> seems to work just fine, though it too doesn't miss the opportunity to
> complain about privileges.
>
> It's not a Gentoo specific issue, as I've experienced this on other
> distros too. I believe there was an upstream bug report that kept
> getting resolved and reopened.
>
> On 10/06/2020 07:59, Dale wrote:
>> I type in the password but it mounts it to the wrong place.
> This is normal. By default, volumes mounted from userspace will be
> mounted under "/run/media/<uid>/<volume name>". This makes sense and is
> entirely due to user privileges. Mounting under other directories would
> require escalation of privileges. But most basic UI features are
> designed for the most common scenario.
>
> On 10/06/2020 07:59, Dale wrote:
>> How do I tell the Device Notifier that I want it mounted somewhere
>> else?
> From KDE you can't and there's no KDE-specific tool to allow you to do
> that. But you can add the UUID of the filesystem to /etc/fstab and KDE
> will then mount it under that location. However, make sure that the UUID
> is that of the open volume, not the encrypted container.
>
> For example, if you manually open the encrypted volume via the command
> line, e.g.:
>
>   # cryptsetup open /dev/sdz1 crypto_volume_name
>
> This will ask you for the encryption password and, if correct, will
> create a new block device "/dev/mapper/crypto_volume_name".
>
> You can then get the UUID of "/dev/mapper/crypto_volume_name" with:
>
>   # blkid /dev/crypto_volume_name
>
> At this point you can close your LUKS container via:
>
>   # cryptsetup close crypto_volume_name
>
> You can bypass steps 1 and 3 above by mounting via the KDE as usual,
> which will automatically create the block device
> "/dev/mapper/luks_abcdef1234". You can then get its UUID via step 2 and
> replace step 3 by ejecting the mounted volume.
>
> Finally, add this UUID to /etc/fstab in the usual way:
>
> UUID=<uuid from step2> /dst/mount/dir <fstype> [mount_options],user 0 0
>
> Note "user" under mount options. This is critical to making it work
> seamlessly from KDE, otherwise it will require escalation of privileges
> to mount the volume.
>
> Once you do the above, the volume should automatically be mounted under
> "/dst/mount/dir" the next time you mount it via Dolphin or Device Notifier.
>
> It still won't get rid of the annoying "You don't have permissions"
> error message, but it does work.
>
> Hope this helps.
>
> - Victor
>


I've got that in dmcrypt and fstab as the wiki says.  That part works. 
It's the KDE part that isn't working correctly.  However, I did do one
thing different, I put users instead of user.  Plural not singular. 
Should users work the same as user?

I wonder, other distros have crypttab file instead of dmcrypt.  I wonder
if I created a crypttab file if that would help KDE even if Gentoo
ignores it or doesn't know it exists.  It sounds like the Device
Notifier is just not set up or designed to do what I want to do.  Given
the number of people who do what I'm doing, it looks like KDE would
either update the Device Notifier or have a new tool that handles
encrypted things. 

Dale

:-)  :-) 

[-- Attachment #2: Type: text/html, Size: 4087 bytes --]

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Victor Ivanov]

[-- Attachment #1.1: Type: text/plain, Size: 1530 bytes --]

On 10/06/2020 21:52, Dale wrote:
> I've got that in dmcrypt and fstab as the wiki says.  That part works. 
> It's the KDE part that isn't working correctly.  However, I did do one
> thing different, I put users instead of user.  Plural not singular. 
> Should users work the same as user?

This makes little sense. The main difference between user and users is
that the former only allows the user who mounted the filesystem (or
root) to unmount the filesystem, whereas the latter (plural) relaxes
this rule and allows any user to unmount the filesystem.

On 10/06/2020 21:52, Dale wrote:
> I wonder, other distros have crypttab file instead of dmcrypt.  I wonder
> if I created a crypttab file if that would help KDE even if Gentoo
> ignores it or doesn't know it exists.

Doubtful. As far as I'm aware "/etc/crypttab" is for systems that use
that atrocity called systemd. So unless you have your system set up to
use systemd, "/etc/conf.d/dmcrypt" is the correct one to use.

On 10/06/2020 21:52, Dale wrote: 
> It sounds like the Device Notifier is just not set up or designed to do
> what I want to do.
Unfortunately, it's quite basic indeed. I still, however, think you can
achieve what you intend to with fstab. I personally tested what I wrote
in my previous email and, apart from the usual false error message, it
mounts it exactly where I've described in /etc/fstab. I can also eject
it via Device Notifier. Could it be that there's something else going on
in your case?

- Victor


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Dale]

[-- Attachment #1: Type: text/plain, Size: 2305 bytes --]

Victor Ivanov wrote:
> On 10/06/2020 21:52, Dale wrote:
>> I've got that in dmcrypt and fstab as the wiki says.  That part works. 
>> It's the KDE part that isn't working correctly.  However, I did do one
>> thing different, I put users instead of user.  Plural not singular. 
>> Should users work the same as user?
> This makes little sense. The main difference between user and users is
> that the former only allows the user who mounted the filesystem (or
> root) to unmount the filesystem, whereas the latter (plural) relaxes
> this rule and allows any user to unmount the filesystem.


Then maybe that isn't the issue.  I didn't think it would matter but did
want to mention it.  Just in case.  ;-) 


>
> On 10/06/2020 21:52, Dale wrote:
>> I wonder, other distros have crypttab file instead of dmcrypt.  I wonder
>> if I created a crypttab file if that would help KDE even if Gentoo
>> ignores it or doesn't know it exists.
> Doubtful. As far as I'm aware "/etc/crypttab" is for systems that use
> that atrocity called systemd. So unless you have your system set up to
> use systemd, "/etc/conf.d/dmcrypt" is the correct one to use.

No systemd here.  Whew!!


> On 10/06/2020 21:52, Dale wrote: 
>> It sounds like the Device Notifier is just not set up or designed to do
>> what I want to do.
> Unfortunately, it's quite basic indeed. I still, however, think you can
> achieve what you intend to with fstab. I personally tested what I wrote
> in my previous email and, apart from the usual false error message, it
> mounts it exactly where I've described in /etc/fstab. I can also eject
> it via Device Notifier. Could it be that there's something else going on
> in your case?
>
> - Victor
>


My dmcrypt entry:


## 3TB private drive external
target='private'
source=UUID='107be33c-b31c-44b8-b4e7-400ee19fb440'


I think I got that right but I'm me.  lol  This is my fstab entry:


UUID="7f0cf585-57c8-4a50-808b-987fc13ceee0"
/home/dale/Desktop/Videos/Private  ext4 defaults,users 0 0


Right now I stuck it under Videos but it's because that was where I was
when I started.  Later on, I'll move it to be under Documents.  I'll
worry about moving it later on. 

You notice anything off about that?  I make a error somewhere?  Miss a
option maybe?

Thanks.

Dale

:-)  :-) 

[-- Attachment #2: Type: text/html, Size: 3472 bytes --]

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Victor Ivanov]

[-- Attachment #1.1: Type: text/plain, Size: 2490 bytes --]

From what I gather, taking into account your other email as well, there
are two separate things going on which may or may not be related:

1) The (now open) filesystem isn't being mounted where it should as per
fstab

2) Even then, there appears to be a bogus 'private' parent directory:
/run/media/private/<uid>/<volume> as opposed to /run/media/<uid>/<volume>

On 11/06/2020 23:17, Dale wrote:
> This is my fstab entry:
>
> UUID="7f0cf585-57c8-4a50-808b-987fc13ceee0"
> /home/dale/Desktop/Videos/Private  ext4 defaults,users 0 0
> ...
> You notice anything off about that?  I make a error somewhere?  Miss a
> option maybe?

fstab doesn't like quotes. The correct syntax would be:
UUID=7f0cf585-57c8-4a50-808b-987fc13ceee0

Re (1) above, given that /etc/conf.d/dmcrypt is only used by the dmcrypt
service through OpenRC its contents are irrelevant when using KDE. So,
from the perspective of DN updating fstab with the correct syntax should
be a two birds, one stone solution to both (1) and (2).

Unless your encrypted volume is always connected to the system and you
would like it to be automatically unlocked (via means of being asked to
enter your password), there is no need to enter anything into
/etc/conf.d/dmcrypt and you can leave the file blank/commented out.

Re (2), frankly, I have no idea but I'm curious as to where that
"private" parent directory might come from. The only possible source for
this that I can guess is from your entry in /etc/conf.d/dmcrypt in the
value for "target":

> ## 3TB private drive external
> target='private'
> source=UUID='107be33c-b31c-44b8-b4e7-400ee19fb440'

While this should only affect the name of the block device created under
"/dev/mapper" it seems too much of a coincidence that the bogus parent
directory bears the same name. I've tried to reproduce your set-up but I
still don't get such a parent under /run/media. Perhaps you can try
changing the value to something else and see if it creates a directory
with the new name? If so, this would confirm the theory, but it still
shouldn't be doing that. At least it would be a starting point for
diagnosis, if it's worth going into that at all.

Also, note that, as I mentioned, when mounting a crypto container
through KDE DN or Dolphin your dmcrypt config is irrelevant and
disregarded. You should hence expect upon opening the container to have
the filesystem's block device appear as "/dev/mapper/luks_abcd1234".

- Victor


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Encrypting a hard drive's data. Best method.

[Dale]

[-- Attachment #1: Type: text/plain, Size: 4867 bytes --]

Victor Ivanov wrote:
> From what I gather, taking into account your other email as well, there
> are two separate things going on which may or may not be related:
>
> 1) The (now open) filesystem isn't being mounted where it should as per
> fstab
>
> 2) Even then, there appears to be a bogus 'private' parent directory:
> /run/media/private/<uid>/<volume> as opposed to /run/media/<uid>/<volume>

When I named it, I named it private.  It could be that is where it got
that word from.  It could be DN picked it up, it could be other things
picked it up as well.  Basically, that's the LVM name for the group
thingy.  I named the partition privatepart.  I added part so I would
know it is a partition.  Sometimes the names LVM uses can be confusing. 
I try to avoid naming a LVM group and a partition with the same name. 
If nothing else, I add 'part' for partitions or something that I can
tell what they are more than what they are called.  Example, I have a
internal backup drive that has a LVM group named backup.  The partition
is also named backup.  Yea, now which is which?  If I ever redo that,
I'll name the partition backuppart or something.  Then I know which is a
LVM group and which is a partition.


> On 11/06/2020 23:17, Dale wrote:
>> This is my fstab entry:
>>
>> UUID="7f0cf585-57c8-4a50-808b-987fc13ceee0"
>> /home/dale/Desktop/Videos/Private  ext4 defaults,users 0 0
>> ...
>> You notice anything off about that?  I make a error somewhere?  Miss a
>> option maybe?
> fstab doesn't like quotes. The correct syntax would be:
> UUID=7f0cf585-57c8-4a50-808b-987fc13ceee0
>
> Re (1) above, given that /etc/conf.d/dmcrypt is only used by the dmcrypt
> service through OpenRC its contents are irrelevant when using KDE. So,
> from the perspective of DN updating fstab with the correct syntax should
> be a two birds, one stone solution to both (1) and (2).
>
> Unless your encrypted volume is always connected to the system and you
> would like it to be automatically unlocked (via means of being asked to
> enter your password), there is no need to enter anything into
> /etc/conf.d/dmcrypt and you can leave the file blank/commented out.
>
> Re (2), frankly, I have no idea but I'm curious as to where that
> "private" parent directory might come from. The only possible source for
> this that I can guess is from your entry in /etc/conf.d/dmcrypt in the
> value for "target":

I copied that method from a wiki.  I also have this in fstab.  The first
one has been there for several years.  It mounts when booting up.


UUID="13d4bec9-1271-490c-b718-d8b1c68ae1e6"   /backup    
ext4            defaults    0 2
UUID="7f0cf585-57c8-4a50-808b-987fc13ceee0"
/home/dale/Desktop/Videos/Private  ext4 defaults,users 0 0


It has quote marks and it works fine.  Maybe that is a new thing??  That
said, I'll remove them since on a Gentoo wiki, it doesn't show them. 

I commented out the entries in dmcrypt.  I saved them in case I need to
refer back later tho.  It took me a while to figure out what all I
needed and what I didn't tho.  Poor google. 

>> ## 3TB private drive external
>> target='private'
>> source=UUID='107be33c-b31c-44b8-b4e7-400ee19fb440'
> While this should only affect the name of the block device created under
> "/dev/mapper" it seems too much of a coincidence that the bogus parent
> directory bears the same name. I've tried to reproduce your set-up but I
> still don't get such a parent under /run/media. Perhaps you can try
> changing the value to something else and see if it creates a directory
> with the new name? If so, this would confirm the theory, but it still
> shouldn't be doing that. At least it would be a starting point for
> diagnosis, if it's worth going into that at all.
>
> Also, note that, as I mentioned, when mounting a crypto container
> through KDE DN or Dolphin your dmcrypt config is irrelevant and
> disregarded. You should hence expect upon opening the container to have
> the filesystem's block device appear as "/dev/mapper/luks_abcd1234".
>
> - Victor
>


I been doing it manually.  I open the drive on the command line, make
sure it is open and then mount it manually.  It uses fstab and mounts
where I want it that way.  The DN tool just doesn't work.  Actually,
trying to use it to handle encrypted drives sort of screwed up my normal
drives and such.  Now it's mounting those things wrong.  I'm concerned
it is going to break some thing such as my SDHC cards that I put in a
card reader.  I started a new thread on that.

How do you mount something within Dolphin?  I've looked through the
menus and I can't find anything on mounting listed.  I haven't got my
new glasses yet so maybe I'm not seeing it???  lol 

Thanks.  I had to read this twice to make sure I got where you were
going here.  I think I got it tho.  ;-)

Dale

:-)  :-) 

[-- Attachment #2: Type: text/html, Size: 5961 bytes --]