2014-04-23 9 views
7

Pole AesCryptoServiceProvider.LegalKeySizes pokazuje dozwolone rozmiary w bitach.Czy prawny rozmiar klucza AES to naprawdę limit?

Jednak nie rozumiem, jeśli są one prawdziwe, w jaki sposób mogę z powodzeniem wykorzystać klucz o długości 2048 bitów (256 bajtów)?

Przypuszczam, że moje prawdziwe pytanie brzmi: czy mój klucz zostanie wyprodukowany zgodnie z żądanym rozmiarem (większy niż 32 bajty), ale wtedy tylko pierwsze 32 bajty (256 bitów) są faktycznie brane pod uwagę w procesie szyfrowania/odszyfrowywania, renderowanie większy rozmiar klucza to marnowanie miejsca?

Nie wiem, czy istnieje sposób na mówienie tego, co faktycznie jest narażony w API ...

Wszelkie myśli? Może patrzę na to w niewłaściwy sposób?

+3

'(nowy AesCryptoServiceProvider()). Key = nowy bajt [256];' -> "CryptographicException: Podany klucz nie jest prawidłowym rozmiarem dla tego algorytmu." - Czy możesz pokazać kod, którego używasz z kluczem 256-bajtowym? – Blorgbeard

+0

Napisałem bezpośrednią odpowiedź, ale zgadzam się z Blorgbeard na ten temat, nie widzę jak "AesCryptoServiceProvider" może być używany z dowolnymi kluczami o rozmiarach innych niż "legalne" rozmiary kluczy. To powiedziawszy, dokumenty Mickeysoft są - znowu - dość niejasne, by nie podawać żadnych błędów, które mogą się pojawić. –

+1

Jeśli najpierw ustawisz klucz na 256, następnie wygenerujesz klucz, API wygeneruje 256 bajtowych kluczy bez błędów i pozwoli ci użyć go we właściwy sposób bez żadnych błędów. Napisałem całą bibliotekę klas funkcjonalnych, która używa klucza o rozmiarze 256 bajtów dla AES i hybrydowego RSA/AES, aby sprawdzić, czy zadziała podczas pisania programów na większej liczbie platform. I robi ... tylko wyjaśnienia 8, że albo klucze prawne są błędne, albo większość klucza nie jest używana. Jestem skłonny uwierzyć w to drugie. – SteakNinja

Odpowiedz

5

AES może być używany dla 3 kluczy wielkości: 128, 192 i 256-bitowych. Zasadniczo, jeśli możesz użyć większych kluczy niż 256 bitów, biblioteka "kłamie", to znaczy, że niektóre bity większego klucza są w jakiś sposób odrzucane lub kompresowane. Na przykład PHP mcrypt ogranicza rozmiar klucza do największego możliwego rozmiaru.

Większe kluczowe "nasiona" są dość powszechne w świecie kryptografii. Na przykład Diffie-Hellman - algorytm uzgodnienia klucza - zwykle generuje sekret większy niż wymagany rozmiar klucza. Tak więc często pojawia się pytanie, czy , wyodrębniając (koncentrując) ilość entropii w kluczu. Jeśli bity są obcięte, to entropia w tych bitach jest odrzucana.

Tym, czego właściwie używa się w nowoczesnej kryptografii, jest KDF, funkcja wyprowadzania klucza. Jeśli wejście - nasiono - jest hasłem, powinieneś użyć PBKDF (Password Based KDF). Współczesne PBKDF to PBKDF2, bcrypt, scrypt i Argon2.

Jeśli dane wejściowe są już kluczem - dane, które zapewniają wystarczającą entropię (losowość), jeśli są wzięte razem - należy użyć KBKDF (Key Based KDF). Nowoczesny KBKDF to na przykład HKDF. Zauważ, że te algorytmy wymagają dodatkowego wejścia, więc jeśli nie podano żadnych dodatkowych danych, najprawdopodobniej bity dodatkowych kluczy są po prostu ignorowane.

Siła kryptograficzna AES-128 jest i pozostaje 128 bitów oczywiście. Tak długo jak te bity są nie do odróżnienia od przypadkowego przez atakującego, AES-128 should provide enough security for practical needs. AES-256 może być użyty, jeśli obawiasz się przełomów w kryptografii kwantowej.


Tak więc dla odpowiedzi: "Czy AES legalne wielkości klucza naprawdę są limitem?" odpowiedź brzmi: tak. 2048 bitowych rozmiarów kluczy jest częściej spotykanych dla algorytmów asymetrycznych, takich jak RSA/DSA. W przypadku RSA i DSA rozmiar klucza jest raczej niski, mimo że powinien być poza zasięgiem praktycznych ataków. Może szyfrowany tekst został zaszyfrowany przy użyciu hybrid encryption.

+0

OK, więc dodatkowe bajty są zdecydowanie ignorowane? Może uda mi się znaleźć test, aby to udowodnić ... może wygenerować większy klucz, a następnie zaszyfrować zarówno w pełnym rozmiarze, jak iw maksymalnym dozwolonym rozmiarze (ta sama sól) i sprawdzić, czy tekst jest taki sam? – SteakNinja

+0

Nie sądzę, że są one ignorowane, jeśli używasz 'AesCryptoServiceProvider' bezpośrednio. Kod byłby miły, tak! Prawdopodobnie jednak wskaże błąd, dołącz informacje o API i runtime, jeśli zdecydujesz się je opublikować (w pytaniu, proszę). –

+0

Ok zauważyłem, że dokumentacja stwierdza, że ​​zmienna do ustawiania keyize jest w bitach. Jeśli to prawda, to dlaczego API zwróci wprowadzoną ilość bajtów? "AES.KeySize = Xbits;" ale KeyProduced = Xbytes ... – SteakNinja

1

Można użyć larger key sizes with Rijndael, algorytmu szyfrowania, na którym opiera się AES, zwykle do pewnego limitu zdefiniowanego w bibliotece. Jednak z AES można używać tylko wielkości klucza 128, 192 lub 256 bitów. Niektóre implementacje mogą wykorzystywać pierwsze bity X (gdzie jest kluczowy rozmiar 128, 192 lub 256 bitów) tablicy bajtów lub strumienia bitów (zazwyczaj C/C++), ale implementacje biblioteki .Net Base Class Library (BCL) nie , jak wspomina @Blorgbeard w swoim komentarzu.

Edycja: W celu wyjaśnienia zależności pomiędzy Rijndael AES AES jest specyfikacja utworzony przez USA National Institute of Standards and Technology (NIST) (FIPS 197 dokładniej), który definiuje podzbiór Rijndael.AES jest zawarty w FIPS 140-2, co oznacza, że ​​jest zatwierdzony do pewnych zastosowań przez departamenty rządu Stanów Zjednoczonych.

+1

"na podstawie" może tu użyć pewnych wyjaśnień - AES jest identyczny z Rijndael, z wyjątkiem ograniczonych rozmiarów kluczy/bloków. –

+0

Nie można użyć rozmiaru klucza * większego * niż 256 bitów, nawet z Rijndael, Rijndael używa kluczy 128, 160, 192, 224 lub 256 bitowych, jednak implementacje Rijndael często po prostu implementują klucze AES. –

Powiązane problemy