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-plain64
blowfish-cbc-essiv:sha256
aes: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óczlmk
trybu 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ą, żeecb
nie 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. plain64
wydaje się być najczęściej polecany.
null
IV 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.
essiv
Uż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 ecb
tryb 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 name
dla 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 type
of skcipher
wskazuje, że jest to symetryczny szyfr klucza, z którego korzysta dm-crypt, a nazwa xts(aes)
zostanie zapisana, aes-xts
gdy zostanie określona za pomocą dm-crypt. Te keysize
pola 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 module
wierszu. 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 anubis
moduł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-anubis
Załadowałby moduł zapewniający szyfr anubisa.
Podczas korzystania z cryptsetup benchmark
polecenia 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-foobar
są 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.