Re: UUID PARTUUID
Moltes gràcies, Orestes. Com sempre, tant didàctic i útil.
Salutacions
On Tue, 17 Sep 2019 19:55:29 +0200
Orestes Mas <orestes@tsc.upc.edu> wrote:
> El 17/9/19 a les 11:08, Griera ha escrit:
> > Hola, bon dia:
> >
> > Una pregunta sobre encriptar. Fa molt més lent Debian?
> >
> > Jo executo Debian instal·lat en un disc dur extern i arranco l'ordinador des del USB on està (així sempre tinc el "mateix" ordinador vagi on vagi) des de, fonamentalment, un ordinador ja antic amb Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz i 8GB de RAM.
> >
> > Si encripto el volum, penseu que anirà molt més lent o no?
> >
> > Moltes gràcies i salutacions.
>
> Sense ser un gran (ni petit) expert en temes de xifrat jo diria que, a
> banda del tema del coll d'ampolla USB, les operacions de (dex)xifrat
> s'executen molt més ràpidament si la CPU les suporta directament al
> maquinari. En aquest cas hauries de mirar (cat /proc/cpuinfo) si la teva
> CPU suporta el flag "aes" (i usar un mètode de xifrat basat en AES, clar).
>
> A banda d'això, llegeixo que hi ha sistemes de xifrat que són
> inherentment més lents que altres. Per exemple, sembla que xifrar tot el
> disc amb LUKS és més ràpid que xifrar només el /home amb eCryptfs.
>
> Més encara: llegeixo que hi ha una ordre que pot ser molt interessant:
>
> "cryptsetup benchmark"
>
> En el PC des del que escric això a mi em retorna el següent:
>
> 19:52 $ cryptsetup benchmark
> # Tests are approximate using memory only (no storage IO).
> PBKDF2-sha1 1605782 iterations per second for 256-bit key
> PBKDF2-sha256 1771243 iterations per second for 256-bit key
> PBKDF2-sha512 1388842 iterations per second for 256-bit key
> PBKDF2-ripemd160 1151016 iterations per second for 256-bit key
> PBKDF2-whirlpool 713317 iterations per second for 256-bit key
> argon2i 6 iterations, 1048576 memory, 4 parallel threads (CPUs)
> for 256-bit key (requested 2000 ms time)
> argon2id 6 iterations, 1048576 memory, 4 parallel threads (CPUs)
> for 256-bit key (requested 2000 ms time)
> # Algorithm | Key | Encryption | Decryption
> aes-cbc 128b 576,4 MiB/s 3075,7 MiB/s
> serpent-cbc 128b 90,7 MiB/s 633,4 MiB/s
> twofish-cbc 128b 197,7 MiB/s 394,4 MiB/s
> aes-cbc 256b 557,3 MiB/s 2403,5 MiB/s
> serpent-cbc 256b 98,1 MiB/s 636,3 MiB/s
> twofish-cbc 256b 202,3 MiB/s 395,5 MiB/s
> aes-xts 256b 2013,7 MiB/s 2014,7 MiB/s
> serpent-xts 256b 631,7 MiB/s 612,8 MiB/s
> twofish-xts 256b 391,9 MiB/s 395,1 MiB/s
> aes-xts 512b 1672,5 MiB/s 1653,2 MiB/s
> serpent-xts 512b 629,3 MiB/s 609,9 MiB/s
> twofish-xts 512b 394,0 MiB/s 394,8 MiB/s
>
> Com es pot apreciar, la velocitat en els xifrats basats en AES és molt
> més gran (5 a 10 vegades) perquè la CPU ho suporta per hardware.
>
> Cordialment,
>
> Orestes.
>
>
> >
> >
> >
> >
> > On Sat, 14 Sep 2019 12:16:54 +0200
> > Jordi <215639@runbox.com> wrote:
> >
> >> Bon dia. Des que vaig instal·lar el Buster, tinc alguns problemes per
> >> encriptar la swap. Després de configurar tot i funcionar correctament,
> >> quan reinicio l'ordinador sembla que el UUID de la swap es perd i
> >> canvia, amb la qual cosa em quedo sense swap i em surt el "Gave up
> >> waiting for suspend/resume device".
> >>
> >> He desfet i refet els canvis unes quantes vegades. Per ara sembla que
> >> funciona només ficant el nom del dispositiu /dev/sdXX a /etc/crypttab i
> >> a /etc/initramfs-tools/conf.d/resume de la següent forma:
> >>
> >> /etc/fstab : /dev/mapper/cryptswap none swap sw 0 0
> >>
> >> /etc/crypttab : cryptswap /dev/sda8 /dev/urandom swap
> >>
> >> /etc/initramfs-tools/conf.d/resume : RESUME=/dev/sda8
> >>
> >> Si hi fico el UUID, no funciona. Si no encripto la swap, funciona tot
> >> be amb la UUID.
> >>
> >> Fent sudo blkid :
> >> /dev/mapper/cryptswap: UUID="d832f5be-0915-486b-8725-xxxxxxxxxxx"
> >> TYPE="swap"
> >> /dev/sda8: PARTUUID="000b0989-08"
> >> On veiem dues entrades per la swap, la UUID de la primera no és la
> >> mateixa que vaig configurar i a /dev/sda8 no surt la UUID, a totes les
> >> altres /dev/sdXX surt PARTUUID i UUID
> >>
> >> Salutacions
> >>
> >> Jordi.
> >>
> --
> Cordialment,
>
> Orestes Mas
>
Reply to: