Czy bezpieczne jest szyfrowanie ciągu za pomocą tego samego ciągu znaków, co klucz?

Question

Czy istnieją jakieś błędy w zabezpieczeniach podczas szyfrowania danego klucza przy użyciu AES w trybie CBC i przy użyciu IV (oczywiście)?

Zasady są przestrzegane: klucz jest tajny, a IV jest publiczny (ponieważ nie wpływa to na bezpieczeństwo szyfrowania).

Jednak potencjalny intruz będzie znał (ponieważ może uzyskać dostęp do kodu źródłowego), że ciąg jest zaszyfrowany przy użyciu siebie jako klucza.

Mój sąd nie widzi żadnych problemów, ale próbuję się upewnić.

Dziękuję.

EDIT - szczegóły zadania, mam nadzieję, że będę w stanie przekazać je w poprzek wyraźnie, że nie jest jeszcze jasne dla siebie:

1. Mój system używa szyfrowania do przechowywania pewnych wartości w tabelach MySQL . Szyfrowanie odbywa się na kodzie PHP (nie wbudowanym w AES MySQL). Oczywiście potrzebuję tajnego klucza, który musi zostać skonfigurowany przez administratora systemu, tylko RAZ, podczas konfiguracji systemu. Ma to kluczowe znaczenie, ponieważ zmiana klucza po zapisaniu zaszyfrowanych danych spowoduje, że dane nie będą odszyfrowywane.

2. Administrator może ustawić tajny klucz, po prostu edytując plik skryptowy PHP przez FTP (lub cokolwiek innego). Ale tego nie chcę.

3. Potrzebuję skryptu instalacyjnego, w którym administrator wybiera tajny klucz, który zostaje zaszyfrowany i zapisany w tabeli. To prawda, że ​​ważnym punktem, który został zrobiony poniżej, jest to, że potrzebujesz klucza do odszyfrowania klucza ... Nie doszedłem tak daleko w moim rozumowaniu, byłem na etapie sprawdzania, czy szyfrowanie klucza samo w sobie klucz jest nadal bezpieczny.

Jeśli masz jakieś pomysły dotyczące powyższego, będzie to bardzo cenne.

Dzięki.

Answer 1

Pytanie brzmi, o co chodzi? Jeśli chcesz odszyfrować ciąg, musisz znać już łańcuch; jeśli go nie znasz, nie możesz go odszyfrować. To możliwe, ale bezcelowe IMHO.

Answer 2

pierwsze: Nie bardzo ekspert bezpieczeństwa

Tak, aby uzyskać to obecnie, chcesz przechowywać tajne wartości, a tylko być w stanie uzyskać tajny wartość, ale mówiąc to tajny wartość? :)

Ale mogę zobaczyć, gdzie chcesz iść z tym, na system haseł (być może), możesz następnie po prostu sprawdzić je razem.

Niektóre wady mogą polegać na tym, że jeśli haker uzyska dostęp do wszystkich haseł użytkowników, a haker ma konto z hasłem, które może zapamiętać, wówczas bardzo łatwo może wykryć twoją logikę szyfrowania. Po tym może zrobić atak słownikowy i uzyskać wiele haseł. W tym celu powinienem rozważyć użycie unikalnego skrótu dla każdego rekordu. Potem może nadal atakować słownik, ale potrwa to znacznie dłużej. Następnie dodaj niestandardowy hash zapisany głęboko w aplikacji, więc musi to również odgadnąć lub mieć dostęp do kodu aplikacji.

więc już będzie przynajmniej polecić klucz, który jest złożony z hasłem + record_hash + shared_hash

UPDATE: Widzę, że haker będzie miał dostęp do kodu, a następnie spróbuj zapisać shared_hash A miejsce, do którego nie ma dostępu.

Answer 3

Jak wspomniałeś w swoim komentarzu w odpowiedzi Jespera, "siła znajduje się w kluczu szyfrowania" oraz w algorytmie szyfrowania. Jeśli oba są silne, powinno być bezpiecznie. O ile mi wiadomo, technicznym słabym ogniwem silnego szyfrowania i klucza jest implementacja, jeśli taka istnieje.

Chcesz wiedzieć, do której aplikacji zamierzasz użyć tej metody, jeśli możesz to powiedzieć.

Edit To nie jest dokładnie odpowiadając na pytanie w tytule słupka, ale przypuszczam, że jest to istotne dla zaktualizowanego postu:

Zakładając silne i prawidłowo wdrożone AES z CBC i IV oraz, że atakujący może uzyskać dostęp do tabeli, w której przechowywany jest zaszyfrowany klucz główny.

Różnica w zabezpieczeniach powinna być niewielka, niezależnie od tego, czy przechowujesz zaszyfrowany klucz główny, czy też przechowujesz skrót kryptograficzny klucza głównego. Zakładając, że zarówno skrót kryptograficzny, jak i AES w trybie CBC są jednakowo bezpieczne, siła leży w sile klucza głównego.

Jeśli klucz główny jest słaby, nawet jeśli osoba atakująca nie może uzyskać klucza głównego z szyfru kryptograficznego klucza głównego, będzie mógł uzyskać klucz główny, a zatem "określone wartości" za pomocą "pewnych". wartości "tabela. Jeśli do szyfrowania używa się klucza głównego, może uzyskać klucz główny za pośrednictwem tabeli "niektóre wartości" lub tabeli kluczy głównych.

Niezależnie od tego, czy używasz tego samego szyfrowania do szyfrowania i przechowywania klucza głównego lub skrótu kryptograficznego i przechowujesz klucz główny, upewnij się, że klucz główny jest silny. Wygląda na to, że piszesz jakiś system open source. Moja sugestia jest taka, że ​​twój system sprawdza każdy potencjalny klucz główny przed wyrażeniem regularnym (lub funkcją) i odrzuca ten klucz, jeśli zostanie uznany za niewystarczająco silny.

Mam nadzieję, że dobrze zrozumiałem Twój post.

Nota prawna: Nie jestem specjalistą ds. Bezpieczeństwa ani w branży zabezpieczeń.

Answer 4

Szyfrowanie klucza samo w sobie jest po prostu funkcją skrótu ad-hoc. Więc zamiast tego możesz użyć prawdziwego.