Różne wyniki szyfrowania danych

Chciałem sprawdzić działanie online'owych szyfratorów danych. Wrzuciłem jakiś tekst na stronę:
https://aesencryption.net/
wybrałem hasło i 128-bitowy blok. Dostałem zaszyfrowany tekst, który spróbowałem odszyfrować na Linuxie:

openssl aes-128-cbc -d -base64 -in AES_15866030531541.txt -out plain.txt

Niestety hasło zostało odrzucone.
Sprawdziłem jaki byłby efekt zaszyfrowania tego samego oryginalnego tekstu komendą openssl, i był zupełnie inny niż ten wygenerowany online. W obu przypadkach zastosowano 128 bitów, metodę CBC i base64. Z czego może wynikać różnica?

Hasło pewnie nie leci tak jak je podajesz bezpośrednio do klucza tylko przez jakieś PBKDF ;) Na tej stronce widać ze używają SHA-1 zeby zamienić hasło na klucz AESa. To wieśniackie więc openssl raczej zamiast tego ma jakieś PBKFD2. No i ta stronka nie bierze żadnego IV / nie dodaje IV do ciphertextu więc szyfruje ECB a nie CBC.

Shalom napisał(a):

Hasło pewnie nie leci tak jak je podajesz bezpośrednio do klucza tylko przez jakieś PBKDF ;) Na tej stronce widać ze używają SHA-1 zeby zamienić hasło na klucz AESa. To wieśniackie więc openssl raczej zamiast tego ma jakieś PBKFD2. No i ta stronka nie bierze żadnego IV / nie dodaje IV do ciphertextu więc szyfruje ECB a nie CBC.

Dziwne mi się wydaje, że nie ma ustalonego standardu wg którego dane do szyfrowania i hasła są przekazywane algorytmom. W końcu chcąc zaszyfrować coś daną metodą, nie powinienem być zależny od konkretnych narzędzi. Według kodu, który tam umieszczono wyglądało, że użyta metoda to jednak CBC (linia 62).

Jedyne przenosne metody "szyfrowania" jakie widzialem to ROT13 i base64. Ta ostatnia tez chyba poczatkowo miala jakies wariacje.
Reszta algorytmow zwykle wymaga tej samej implementacji po obu stronach.
Najbardziej haniebny przyklad na podparcie tej tezy: MD5, ktore z niewiadomych dla mnie do dzis powodow dziala(lo) roznie w zaleznosci od narzedzia i platformy.
Teoretycznie DES/3DES nie da sie spieprzyc, ale to przestalo byc bezpieczne dekady temu.

Dziwne mi się wydaje, że nie ma ustalonego standardu wg którego dane do szyfrowania i hasła są przekazywane algorytmom.

A czemu miałby być? Ogólnie algorytm zawsze otrzymuje dane w ten sam sposób:

• string jako hasło (przy czym string tutaj oznacza dowolny ciąg bajtów, nie ich reprezentację w ASCII)
• string jako dane do zaszyfrowania

To jest wszystko. Natomiast cała otoczka związana z tym już jest zależna od narzędzia.

hauleth napisał(a):

Dziwne mi się wydaje, że nie ma ustalonego standardu wg którego dane do szyfrowania i hasła są przekazywane algorytmom.

A czemu miałby być? Ogólnie algorytm zawsze otrzymuje dane w ten sam sposób:

Żeby można było jednoznacznie szyfrować i deszyfrować, wiedząc jaki algorytm i metoda zostały użyte.

Tylko, że algorytm to nie jest całość procesu, bo masz jeszcze padding, format składowania danych, format klucza, KDF, MAC/AEAD. Szyfrowanie składa się z wielu rzeczy, nie tylko samego algorytmu. Powiedział bym więcej, jak w swoim kodzie masz gdzieś napisane "AES" to najprawdopodobniej masz błąd pozwalający odszyfrować Twoje dane.

Ale tak jest! AES zawsze dziala tak samo dla podanych parametrów. Tylko ze parametrem AESa NIE JEST hasło, tylko KLUCZ :) To że ty chcesz sobie użyć jakiegoś printable hasła to jest twoja sprawa, ale musisz jasno określić jak z tego hasła zrobić klucz. State-of-the-art to użycie jakiegoś PBKDF2 albo w nowszych zastosowaniach argon2, a ta stronka z d**y której użyłeś robi to za pomocą SHA.

hauleth napisał(a):

Tylko, że algorytm to nie jest całość procesu, bo masz jeszcze padding, format składowania danych, format klucza, KDF, MAC/AEAD. Szyfrowanie składa się z wielu rzeczy, nie tylko samego algorytmu. Powiedział bym więcej, jak w swoim kodzie masz gdzieś napisane "AES" to najprawdopodobniej masz błąd pozwalający odszyfrować Twoje dane.

Ale ja nie mówię o algorytmie tylko właśnie o całym procesie, który jest zaimplementowany w narzędziu.
Z punktu widzenia końcowego użytkownika nie są istotne wymienione przez Ciebie rzeczy. Istotne jest, czy dana wiadomość, zaszyfrowana przy konkretnym zestawie parametrów da się odszyfrować przy tym samym zestawie parametrów przy użyciu innych implementacji. Na tym polega standard.

Shalom napisał(a):

Ale tak jest! AES zawsze dziala tak samo dla podanych parametrów. Tylko ze parametrem AESa NIE JEST hasło, tylko KLUCZ :)

Powtarzam, nie mówię o algorytmie AES tylko narzędziach szyfrujących na nim opartych. Skoro różne narzędzia dają różne wyniki, to znaczy że narzędzia takiego standardu najwyraźniej nie posiadają, nawet jeśli sam algorytm jest standardowy.

Chciałbym wiedzieć, kto w ogóle mówił, że takie rzeczy jak szyfrowanie sobie AESem są przeznaczone dla użytkownika końcowego?

enedil napisał(a):

Chciałbym wiedzieć, kto w ogóle mówił, że takie rzeczy jak szyfrowanie sobie AESem są przeznaczone dla użytkownika końcowego?

A dlaczego miałyby nie być?

Po prostu nie jest. Nikt tego tak nie zaprojektował. Oczywiście, powstały różne metody szyfrowania przyjazne dla użytkowników końcowych, ale większość zastosowań jednak nie ogranicza się do szyfrowania tekstu za pomocą hasła, przeciwnie, chyba najczęściej takie hasło jest zastąpione przez efemeralne klucze sesyjne (tak jak jest w TLS).

enedil napisał(a):

Po prostu nie jest. Nikt tego tak nie zaprojektował. Oczywiście, powstały różne metody szyfrowania przyjazne dla użytkowników końcowych, ale większość zastosowań jednak nie ogranicza się do szyfrowania tekstu za pomocą hasła, przeciwnie, chyba najczęściej takie hasło jest zastąpione przez efemeralne klucze sesyjne (tak jak jest w TLS).

I to mnie dziwi. Skoro jest potrzeba i jest metoda, to powstanie standardu wsrod narzedzi powinno byc rzecza naturalna. Z tego co widze sa co najwyzej przyjete pewne dobre praktyki

Podstawowy problem jest taki, że te przykłady kodu do szyfrowania na tej stronie szyfrują inaczej niż ich szyfrator na górze strony.

Gdy wpiszę tekst "GutekSan", klucz "4p" i wybiorę wersję 128 bit to na stronce dostaję: 53+5GlKGjr5Q31ctbwFA2g== - nie wiem jak do tego doszli.

Natomiast jeśli wezmę przykład Javowy i porównam jego wynik z opensslem to wszystko się zgadza. W Java AES encryption example ustawiłem:

        final String strToEncrypt = "GutekSan";
        final String strPssword = "4p";

i wynik jest taki:

2
16
���w��*��<_��R
String to Encrypt: GutekSan
Encrypted: 7GJv7R7h+TFWBeBl4SNn/w==
String To Decrypt : 7GJv7R7h+TFWBeBl4SNn/w==
Decrypted : GutekSan

Dokładnie taki sam wynik dostaję przy takim wywołaniu:

$ echo -n GutekSan | openssl aes-128-ecb -K $(echo -n 4p | sha1sum | cut -b -32) -e -base64
7GJv7R7h+TFWBeBl4SNn/w==
$ echo "7GJv7R7h+TFWBeBl4SNn/w==" | openssl aes-128-ecb -K $(echo -n 4p | sha1sum | cut -b -32) -d -base64 && echo
GutekSan
$

Może kod w PHPcu jest popsuty albo celowo inaczej działa i używają go do szyfrowania w szyfratorze na górze strony? Nie mam PHPca zainstalowanego i nie chce mi się tego sprawdzać.

Skoro jest potrzeba i jest metoda, to powstanie standardu wsrod narzedzi powinno byc rzecza naturalna.

I masz standardy:

• OpenPGP
• TLS
• JWT
• Paseto

Każdy z nich ma swoje zastosowania i format, bo format danych jest często powiązany z właściwościami jaki chcemy mieć.