Pomoc QTS 4.2 nie chce zainstalować veracrypt - różne Md5

[badziewiak]

Próbowałem zainstalować przez konsolę veracrypt, ale instalator zgłasza błąd sumy kontrolnej. Na wirtualnej maszynie na PC pod xbuntu chodzi to poprawnie, nawet pobrałem ten plik instalacyjny na wirtualną maszynę przez sambę z samego qnapa. Jaka może być przyczyna?

[/share/Archiwum] # sh veracrypt-1.16-setup-console-x64
Verifying archive integrity...Error in MD5 checksums: d41d8cd98f00b204e9800998ecf8427e is different from edd60459a497ac4101be200f2029faff
[/share/Archiwum] # sh veracrypt-1.16-setup-console-x64

A na wirtualnej maszynie:

user@ubuntu:~$ sudo sh /home/user/Desktop/veracrypt-1.16-setup-console-x64
Verifying archive integrity... All good.
Uncompressing VeraCrypt 1.16 Installer..
VeraCrypt 1.16 Setup
____________________


Installation options:

 1) Install veracrypt_1.16_console_amd64.tar.gz
 2) Extract package file veracrypt_1.16_console_amd64.tar.gz and place it to /tmp

To select, enter 1 or 2: 1

Before you can use, extract, or install VeraCrypt, you must accept the
terms of the VeraCrypt License.

Press Enter to display the license terms...

Press Enter or space bar to see the rest of the license.


VeraCrypt License
(...)


Do you accept and agree to be bound by the license terms? (yes/no): yes   

Uninstalling VeraCrypt:
-----------------------

To uninstall VeraCrypt, please run 'veracrypt-uninstall.sh'.

Installing package...
usr/
usr/bin/
usr/bin/veracrypt-uninstall.sh
usr/bin/veracrypt
usr/share/
usr/share/applications/
usr/share/applications/veracrypt.desktop
usr/share/veracrypt/
usr/share/veracrypt/doc/
usr/share/veracrypt/doc/License.txt
usr/share/veracrypt/doc/VeraCrypt User Guide.pdf
usr/share/pixmaps/
usr/share/pixmaps/veracrypt.xpm

Press Enter to exit...

 

[badziewiak]

No tak, przecież 3 dni temu zrobiłem identycznie z poziomu routera, by skopiować dane z dysku routera na NAS. Dziwne tylko że w gui nie działa, bo to oczywiście hula.
Dziękować. Teraz walczę z konfiguracją serwera samby z gui (opensuse), ale chyba zaraz się wkurzę i zrobię to z konsoli.
Kiedyś wysłałem do nich:

Please fix the problem with veracrypt installation. I want use encrypted container (not whole RAID). Limitation of length of password to 16 character causes too weak encryption. Veracrypt is tested very strong encryption tool. I want install it on QTS 4.2 but the installation script return error message:

[/share/Archiwum] # sh veracrypt-1.16-setup-console-x64
Verifying archive integrity...Error in MD5 checksums: d41d8cd98f00b204e9800998ecf8427e is different from edd60459a497ac4101be200f2029faff

The same file downloaded from the same NAS to ubuntu work fine:
user@ubuntu:~$ sudo sh /home/user/Desktop/veracrypt-1.16-setup-console-x64
Verifying archive integrity... All good.

Na to mi odpisali:

Hello
What is the password limitation for admin user ? it is limited only by 64 characters.
Ticket Details(...)

czyli baba o chlebie, dziad o niebie, bo co wspólnego ma długość hasła admina do długości hasła szyfrowania???
Odpisałem więc na ile umiałem po murzyńsku:

The length of the password to encrypt the shared folder is 16 characters, I checked it. Assuming the strength of the password 6 bits per character, must be at least 43 characters for 256 bit encryption strength. I am thinking of data security if the hardware will be stolen. Limiting the length of passwords seems to me pointless.
Temporarily I worked it out by creating a virtual machine with veracrypt and samba server (encrypted container is stored on the NAS, virtual machine has access via CIFS or NFS and provides the decrypted data via CIFS server). However, this is inefficient. The read speed is good (over 110MB / s per link 1Gb), but the write is 20MB/s. It is also dangerous, because the attacker after turning off the NAS only resumes the virtual machine and has access to the sensitive data.
Can mount the encrypted container directly without a virtual machine by CIFS but only one user has access to it. Writing speed is then more than 60MB / s, whereas without a CIFS connection (on PC) speed is more than 3.6GB/s by benchmark (on SSD disk is over 400MB/s).
If the encryption of folders will be available without a limit the of length of the password, the data can be considered safe.
Another problem is the content of password. They must be allowed all the characters available with the English keyboard, including the characters! @ # $% ^ & * () _ +:"/.?. Restricting these elements are the next undermining the sense to use a password.

Czy oni naprawdę są tak niekumaci i tak drastycznie zaniedbują kwestie bezpieczeństwa danych nieświadomie, czy z premedytacją?! Załamka...
Podszedłem do sprawy jeszcze inaczej. Użyłem tego Cryptsetup/wolumeny - Wikibooks, biblioteka wolnych podręczników i chodzi to lepiej. Pytałem się o shred, żeby wypełnić zawartość pliku na dane zaszyfrowane, ale ten brak ominąłem przez skopiowanie kontenera z veracrypt. Co zrobiłem? Wg poradnika, ale dla potomnych lub gdyby ta stronka zniknęła:

opkg install cryptsetup shred <-Nie powtarzać przy kolejnym użyciu!
touch /share/abc/zaszyfrowane<-Nie powtarzać przy kolejnym użyciu!
shred -n1 -s500G /share/abc/zaszyfrowane <-Tu właśnie mi tego brakowało na dzień dobry. Nie powtarzać przy kolejnym użyciu!
losetup /dev/loop0 /share/abc/zaszyfrowane
cryptsetup -y create mycrypt /dev/loop0
dmsetup ls <-aby wylistować i sprawdzić czy poszło pomyślnie
mke2fs -t ext4 /dev/mapper/mycrypt <-Nie powtarzać przy kolejnym użyciu!

#Tu zastanawiałem się gdzie podmontować dane rozszyfrowane, ale utworzyłem nowy udział sieciowy i w nim podmontowałem.
mount /dev/mapper/mycrypt -t ext4 /share/rozszyfrowane

#Jeszcze ustawić prawa zapisu dla wszystkich, bo dostęp i tak jest ustawiany z poziomu QTS
chmod 777 /share/rozszyfrowane <-Nie powtarzać przy kolejnym użyciu!

Uzupełnienie: @pigers wykonał za mnie robotę odszukania właściwego pakietu do shred, zamieścił właściwy opisu tu Rozwiązany - shred niedostępne?. Nie sprawdzałem, ale wierzę na słowo. Dziękuję, na pewno kiedyś się przyda.

Poniżej obrazki z transferami ok. 28GB danych. W obydwu przypadkach na początku szło 112MB/s, później były mniejsze lub większe wahania. Jak się łatwo domyśleć, pierwszy obrazek dotyczy kopiowania na NAS bez szyfrowania, drugi z szyfrowaniem.

Na wszelki wypadek wrzucam w załączeniu spakowaną stronkę.
Dobra, a może by ograniczyć pracochłonność uruchamiania szyfrowania do minimum? Ja zrobiłem skrypt o następującej zawartości:

losetup /dev/loop0 /share/abc/zaszyfrowane
cryptsetup -y create mycrypt /dev/loop0
mount /dev/mapper/mycrypt -t ext4 /share/rozszyfrowane

a obsługa z konsoli wygląda tak:

[~] # sh zamontuj.sh
/dev/loop0Enter passphrase:
Verify passphrase:
[~] #

Dzięki temu mamy z głowy rażące zaniedbania firmy Qnap w kwestii bezpieczeństwa danych, bo:
1. Można stosować chyba wszystkie znaki w haśle, a nie a-z A-Z 0-9 jak w QTS 4.2.
2. Mogłem wprowadzić ponad 40-znakowe hasło, a nie 16 jak w QTS 4.2.
3. Nie ma problemu nieautoryzowanego dostępu do danych, jeśli NAS zostanie zamknięty, a użyliśmy do szyfrowania wirtualną maszynę z veracrypt czy czymś podobnym. Wirtualna maszyna przechodzi bowiem do trybu suspend po zamknięciu QTS 4.2.

No i oczywiście mam satysfakcję, że dzięki wspaniałej pracy twórców jądra linuxa, którzy wkompilowali w niego dm-crypt, mogłem sobie poradzić w tak prosty sposób. Oczywiście @pigers podpowiedział mi jak zainstalować shred, za co również dziękuję.

 

[kaktus]

zrób sobie folder /NAS

• mount.cifs //192.168.88.250/NazwaUDZIAŁUQnaP /NAS -o username=admin,password=adminpassword

i voila - oczywisćie po reboocie VMki to zniknie i trzeba sobie dodać do /etc/fstab

uuuu pigersie to do Ciebie nie podobne, podpowiedz lepiej koledze jak uniknąć w pliku ogólnie dostępnym, hasła zapisanego jawnie.

 

[Usunięty użytkownik pigers]

Serio ? @kaktus leniu jeden , sam byś poszukał na wujku g00glu !
Let me google that for you