Skąd mam wiedzieć, jakiego algorytmu mieszającego SQL Server użył do odszyfrowania zaszyfrowanych danych podczas korzystania z funkcji DECRYPTBYPASSPHRASE?

Moje pytanie dotyczy następującego eksperymentu z dwoma instancjami:

Instancja SQL Server 2017 Express (Microsoft SQL Server 2017 (RTM-CU16)) Instancja
SQL Server 2014 Express (Microsoft SQL Server 2014 (SP2-CU18))

Użyłem funkcji ENCRYPTBYPASSPHRASE do zaszyfrowania tekstu i użyłem wyniku jako @ciphertext dla DECRYPTBYPASSPHRASE . Wyniki moich testów były następujące:

Zgodnie z tym Microsoft Fix ,

[...] SQL Server 2017 używa algorytmu mieszającego SHA2 do mieszania hasła. SQL Server 2016 i wcześniejsze wersje SQL Server używają algorytmu SHA1, który nie jest już uważany za bezpieczny.

Ale skąd ma wiedzieć, jakiego algorytmu użyto do szyfrowania danych, jeśli nie ma argumentu związanego z tym w funkcji DECRYPTBYPASSPHRASE? Czy to część zaszyfrowanych danych?

Według wyników moich testów SQL Server zawsze używa nowszej wersji algorytmu dostępnego w instancji do szyfrowania danych, ale próbuje wszystkich algorytmów w celu odszyfrowania danych, dopóki nie znajdzie takiego, który pasuje lub zwraca NULL, gdy nie zostanie znaleziony odpowiedni algorytm . To tylko przypuszczenie, ponieważ nie mogłem znaleźć żadnego sposobu, aby sprawdzić, jakiego algorytmu haszującego SQL Server użył do odszyfrowania zaszyfrowanych danych.

Ale skąd ma wiedzieć, jakiego algorytmu użyto do szyfrowania danych, jeśli nie ma argumentu związanego z tym w funkcji DECRYPTBYPASSPHRASE? Czy to część zaszyfrowanych danych?

Tak, od razu.

Mam zamiar użyć następujących danych wyjściowych:

DECLARE @Data VARBINARY(MAX)
DECLARE @Text NVARCHAR(MAX) = N'I''ll get you, and your little dog too!'
DECLARE @Phrase NVARCHAR(100) = N'Fly My Pretties!'

SELECT @Data = ENCRYPTBYPASSPHRASE(@Phrase, @Text)

SELECT @Data AS [Encrypted_Data]

SELECT CAST(DECRYPTBYPASSPHRASE(@Phrase, @Data) AS NVARCHAR(MAX))

Jeśli uruchomię to w mojej instancji 2014, otrzymam następujące informacje dla Encrypted_Data: 0x01000000E565142762F62...

Jeśli uruchomię to w moim wystąpieniu w 2017 r., Otrzymam następujące informacje dla Encrypted_Data: 0x020000004D261C666204F...

Powinna pojawić się preambuła, w której widać, że wystąpienie 2014 zaczyna się od, 0x01a wystąpienie 2017 zaczyna się 0x02. Jest to wersja używanego typu szyfrowania. Zauważ, że jest coś więcej niż tylko to, ale nie ma potrzeby wchodzenia w te szczegóły dla celów tej odpowiedzi, ani nie musi to być wiedza publiczna.

SQL Server 2017 rozumie 0x01i 0x02ponieważ jest nowy i zna nowe rzeczy. SQL Server 2014 rozumie tylko 0x01dlatego, że jest starszy i nie zna żadnych nowych rzeczy, ponieważ nowe rzeczy nie zostały przeniesione.

[...] SQL Server 2017 używa algorytmu mieszającego SHA2 do mieszania hasła. SQL Server 2016 i wcześniejsze wersje SQL Server używają algorytmu SHA1, który nie jest już uważany za bezpieczny.

To nie jest to samo, ale ogólnie ma to związek z tworzeniem kluczy symetrycznych z tym samym wektorem inicjującym w obu wersjach. Napisałem o tym na blogu, kiedy pojawiło się 2017, i zostało to naprawione nieco później za pomocą flagi śledzenia, która musi być użyta, podczas gdy w twoim pytaniu nie jest potrzebna flaga śledzenia do 2017, aby odczytać dane z 2014 roku, jak pokazano.