Czy nie jest bezpieczne przekazywanie wektora inicjalizacyjnego i soli wraz z szyfrogramem?

Question

Jestem nowy we wdrażaniu szyfrowania i nadal uczę się podstaw, wydaje się.

Potrzebuję możliwości kodowania symetrycznego w mojej bazie kodu źródłowego. Istnieją trzy elementy tego systemu:

• serwer, który przechowuje pewne dane użytkownika oraz informacje o tym, czy jest czy nie jest szyfrowana, a jak
• AC# klient, który pozwala użytkownikowi szyfrować dane z prostym hasło przy wysyłaniu do serwera, i deszyfrowania z tym samym hasłem podczas odbierania
klienta
• javascript, który robi to samo i dlatego musi być zgodna z metodą szyfrowania C# klienta

Patrząc na różnych bibliotek JavaScript, doszedłem przez SJCL, który ha SA Strona piękny demo tutaj: http://bitwiseshiftleft.github.com/sjcl/demo/

Z tego, wydaje się, że to, co klient musi wiedzieć (oprócz hasła używanego) w celu odszyfrowania szyfrogram jest:

• Inicjalizacja wektor
• Wszelkie sól stosowana na hasło
• rozmiar klucza
• siła uwierzytelniania (nie jestem całkowicie pewien, co to jest)

Czy przechowywanie wszystkich tych danych za pomocą zaszyfrowanego tekstu jest względnie bezpieczne? Należy pamiętać, że jest to kod źródłowy o otwartym kodzie źródłowym i nie ma możliwości, aby rozsądnie ukryć te zmienne, chyba że poproszę użytkownika o ich zapamiętanie (tak, prawda).

Wszelkie porady są mile widziane.

Answer 1

Wektory inicjujące i sole są nazywane takimi, a nie kluczami, dokładnie dlatego, że nie muszą być trzymane w tajemnicy. Jest bezpieczne i zwyczajowo kodować takie dane wraz z zaszyfrowanym/zakodowanym elementem.

Jakie potrzeby IV lub soli należy użyć tylko jeden raz dla danego klucza lub hasła. W przypadku niektórych algorytmów (na przykład szyfrowania CBC) mogą występować pewne dodatkowe wymagania, spełnione przez losowe losowanie IV, z jednolitym prawdopodobieństwem i generatorem liczb losowych kryptograficznie. Jednak poufność nie jest potrzebną właściwością IV lub soli.

Szyfrowanie symetryczne rzadko wystarcza do zapewnienia bezpieczeństwa; samo szyfrowanie chroni przed atakami pasywnymi, w których atakujący obserwuje, ale nie ingeruje. Aby chronić przed aktywnymi atakami, potrzebujesz również pewnego rodzaju uwierzytelniania. SJCL używa trybów szyfrowania CCM lub OCB2, które łączą szyfrowanie i uwierzytelnianie, więc wszystko jest w porządku. "Siła uwierzytelniania" to długość (w bitach) pola poświęconego uwierzytelnianiu w zaszyfrowanym tekście; siła "64 bitów" oznacza, że ​​osoba atakująca próbująca zmienić wiadomość ma maksymalne prawdopodobieństwo, że 2 ^-64 może to zrobić bez wykrycia przez mechanizm uwierzytelniania (i nie może wiedzieć, czy odniósł sukces bez próbowania, tj. o zmienionej wiadomości wysłanej do kogoś, kto zna klucz/hasło). To wystarcza do większości celów. Większa siła uwierzytelniania implikuje większy tekst zaszyfrowany, o (mniej więcej) taką samą ilość.

Nie patrzyłem na implementację, ale z dokumentacji wydaje się, że autorzy SJCL znają się na handlu i robili to poprawnie. Polecam go używać.

Pamiętaj tradycyjnych zastrzeżeń haseł i javascript:

• JavaScript jest kod, który działa po stronie klienta, ale jest pobierany z serwera. Ten wymaga, aby pobieranie było w jakiś sposób chronione pod względem integralności; w przeciwnym razie osoba atakująca może wstrzyknąć część swojego własnego kodu, na przykład prostą łatkę, która również rejestruje kopię hasła wprowadzonego przez użytkownika w dowolnym miejscu. W praktyce oznacza to, że kod SJCL powinien być obsługiwany podczas sesji SSL/TLS (tzn. HTTPS).

• Użytkownicy to ludzie, a ludzie źle znają hasła. Jest to ograniczenie ludzkiego mózgu. Co więcej, komputery stają się coraz potężniejsze, podczas gdy ludzkie mózgi wciąż są mniej lub bardziej niezmienione. Dzięki temu hasła stają się coraz słabsze w stosunku do ataków słownikowych , tj. Wyczerpujące wyszukiwanie haseł (osoba atakująca próbuje odgadnąć hasło użytkownika, wypróbowując "prawdopodobne" hasła). Tekst zaszyfrowany wygenerowany przez SJCL może być użyty w ataku słownikowym w trybie offline:: atakujący może "wypróbować" hasła na swoich komputerach, bez konieczności sprawdzania ich na serwerze, a ogranicza go tylko jego własna moc obliczeniowa. SJCL zawiera kilka funkcji, aby uczynić zalogowany ataki słownikowe trudniejsze:

  1. SJCL wykorzystuje się sól, która zapobiega podziału kosztów (zwykle znany jako „precomputed stoły”, w szczególności „tęczowe tablice”, które są specjalnym rodzajem tabelach precomputed). Przynajmniej atakujący będzie musiał zapłacić pełną cenę za wyszukiwanie słownika za każde zaatakowane hasło.
  2. SJCL używa soli kilkakrotnie, poprzez mieszanie jej z hasłem w kółko w celu wytworzenia klucza. Właśnie to SJCL nazywa "czynnikiem wzmacniającym hasło". To sprawia, że ​​transformacja hasła do klucza jest droższa dla klienta, ale także dla atakującego, co jest celem. Sprawienie, że kluczowa transformacja 1000 razy dłużej oznacza, że ​​użytkownik będzie musiał poczekać, może, pół sekundy; ale także mnoży przez 1000 koszt ataku.