Jądro 5.1, obecne w chwili, gdy to piszę, ma dwa różne formaty: łańcuch znaków, „stary” i „nowy”. Jak dotąd wszystko w tym pytaniu, a także najwyraźniej wszystkie dokumenty, dotyczy „starego” formatu, więc opiszę to tutaj. To jest po prostu szyfrowanie. Jeśli używasz integralności z dm-crypt, należy wziąć pod uwagę szyfry AEAD i staje się to jeszcze bardziej skomplikowane.
Format analizowany przez jądro to „ tryb szyfrowania [ :keycount ] ivmode [ ivopts ]”. Przykłady: , , .--:aes-xts-plain64blowfish-cbc-essiv:sha256aes:64-cbc-lmk
szyfr
szyfr do użycia, przykładyaes,anubis,twofish,arc4, itd dm-crypt sterownik jądra nie posiada listę szyfrów. To jest przekazywane do Linux Crypto API, więc można użyć dowolnego odpowiedniego szyfru obsługiwanego przez jądro.
keycount
Opcjonalna moc dwóch liczb kluczy do użycia z szyfrem. Domyślnie jest to 1 dla wszystkiego opróczlmktrybu iv, gdzie domyślnie jest to 64. To naprawdę dotyczy tylko LMK, a wartości inne niż 1 nie będą działać poprawnie z innymi trybami.
mode Tryb łączenia bloków do użycia z szyfrem. Przykładami sąecb,cbc,xts. Poza wiedzą, żeecbnie używa IV, sterownik md-crypt przekazuje to do interfejsu Linux Crypto API i może korzystać z dowolnego trybu łączenia obsługiwanego przez jądro.
ivmode Algorytm używany do generowania wektora inicjalizacji (IV) dla każdego sektora. W typowym szyfrowaniu kluczem symetrycznym, w przeciwieństwie do dm-crypt, IV to kolejny bit danych przekazywanych do szyfru wraz z kluczem podczas szyfrowania lub deszyfrowania. Dla całej operacji przekazano tylko jeden IV. Ponieważ dm-crypt musi być w stanie odczytywać i zapisywać każdy sektor osobno, nie szyfruje całego dysku jako pojedynczej operacji. Zamiast tego istnieje IV dla każdego sektora. Zamiast przekazywania IV jako danych, tutaj określono algorytm tworzenia IV. Nie jest to częścią interfejsu API Linux Crypto, ponieważ szyfrowanie IV nie wykonuje generowania IV, a dozwolonewartości trybu ivmode są definiowane przez sterownik dm-crypt. Oni są:
plain, plain64, plain64be, benbi
To po prostu użyć numeru sektora, w różnych formatach, jak IV. Przeznaczony do trybów blokowych, takich jak XTS, które są zaprojektowane tak, aby były odporne na ataki takie jak znak wodny przy użyciu prostej i przewidywalnej IV. plain64wydaje się być najczęściej polecany.
nullIV zawsze wynosi zero. Do testowania i kompatybilności wstecznej nie powinieneś tego używać.
lmk Kompatybilny ze schematem szyfrowania Loop-AES.
tcw Kompatybilny z TrueCrypt.
essivUżywa numeru sektora zaszyfrowanego skrótem klucza. Przeznaczony dla trybów, takich jak CBC, które nie są odporne na różne ataki, gdy używa się prostej IV plain64.
ivopts Hash używany w trybieessiv ivmode , ignorowany dla wszystkich innych trybów.
W szczególnym przypadku „ szyfr-plain ” lub po prostu „ szyfr ” są interpretowane jako „ szyfr-cbc-plain ”. Innym szczególnym przypadkiem jest to, że ecbtryb nie ma określonego trybu iv .
Jak to się odnosi /proc/crypto
W odniesieniu do /proc/crypto, tylko szyfr i tryb są istotne. dm-crypt z konstruowaniem specyfikacji API Crypto postaci „ tryb (szyfru) ” i poproś o to z jądra. To jest to, co powinno się zwracać uwagę /proc/crypto, jak namedla skcipher. Przykład:
name : xts(aes)
driver : xts-aes-aesni
module : kernel
priority : 401
refcnt : 1
selftest : passed
internal : no
type : skcipher
async : yes
blocksize : 16
min keysize : 32
max keysize : 64
ivsize : 16
chunksize : 16
walksize : 16
Symbol typeof skcipherwskazuje, że jest to symetryczny szyfr klucza, z którego korzysta dm-crypt, a nazwa xts(aes)zostanie zapisana, aes-xtsgdy zostanie określona za pomocą dm-crypt. Te keysizepola powiedzieć nam również co klucz rozmiary mogą być używane z tym szyfrem.
Jeśli pochodzi z modułu, nazwa modułu może pojawić się w modulewierszu. Jednak wiele szyfrów (zwykle tych w oprogramowaniu, które nie mają żadnego kodu specyficznego dla sprzętu) jest zaimplementowanych jako ogólny szyfr, który jest połączony z ogólnym kodem łańcucha blokowego w celu wytworzenia końcowego skryphera. Na przykład:
name : xts(anubis)
driver : xts(ecb(anubis-generic))
module : kernel
type : skcipher
name : anubis
driver : anubis-generic
module : anubis
type : cipher
W tym przypadku szyfr Anubisa jest łączony z kodem trybu łańcucha blokowego jądra XTS w celu wytworzenia końcowego szyfru xts(anbuis), któremu przypisano moduł kernel. Ale aby to było dostępne, potrzebujemy ogólnego szyfru anubis, który pochodzi z anubismodułu. Większość szyfrów ma alias modułu „ crypto-szyfr ”, który może być użyty do ich załadowania, np. modprobe crypto-anubisZaładowałby moduł zapewniający szyfr anubisa.
Podczas korzystania z cryptsetup benchmarkpolecenia ważny jest tylko szyfr i tryb , ponieważ to wszystko, co jest testowane. Jeśli tryb nie jest określony, domyślnie jest to CBC. Tryb iv jest całkowicie ignorowany. Tak więc, na benchmarking, aes, aes-cbc, i aes-cbc-foobarsą równoważne.
/lib/modules/*/kernel/crypto/jest prawdopodobnie miejscem, w którym można szukać, ale moduły mogą znajdować się w dowolnym miejscu systemu plików.