Właśnie przeczytałem ten artykuł RSA keys under 1024 bits are blocked, aw moim oprogramowaniu .NET szeroko wykorzystuję klucze 384bit. Czy mój program nadal będzie w stanie generować/przechowywać/odczytywać klucze z MachineKeyStore za pomocą RSACryptoServiceProvider? Czy będę zmuszony wysłać łatkę?.Net: Czy moje klucze RSA będą nadal funkcjonować po sierpniu 2012 roku?
Jest to sugerowana odpowiedź na pytanie, które pojawiło się w komentarzach.
Prawdopodobnie można znaleźć sposób na użycie metody symetrycznej do uwierzytelnienia klientów. Zakładam, że teraz używasz typowego schematu podpisywania RSA, w którym skrót wiadomości jest podpisywany przez klucz prywatny klienta, który następnie można zweryfikować za pomocą klucza publicznego.
Może być możliwe wykonanie wymiany trwałego klucza, a następnie zaszyfrowanie wiadomości za pomocą tego klucza zamiast asymetrycznego. Nadal będziesz mieć gwarancję, że ten, kto wysłał wiadomość, znał tajny klucz, chociaż nie masz możliwości sprawdzenia, czy wiadomość została wysłana przez klienta lub serwer (ponieważ obie znają klucz). Jeśli klient zakwestionował serwer podczas uwierzytelniania, to pomogłoby zapobiec atakowi pośredniczącemu (chociaż klient musiałby mieć klucz publiczny wbudowany lokalnie)
Doceniam twoją sugestię, ale nie ma to nic wspólnego z początkowym pytaniem. Ogromnym zadaniem będzie przekonanie wszystkich moich użytkowników do aktualizacji przed sierpniem 2012 r., Więc raczej nie zmienię kodu ani schematu szyfrowania. Poza tym system jest zdecentralizowany, jak e-mail, więc klienci nie mogą przechowywać stałej listy kluczy publicznych, muszą być przenoszeni wraz z wiadomością. Następnie mogą wybrać białe listy niektórych kluczy, tak aby po otrzymaniu kolejnej wiadomości mogli być pewni, że pochodzą od tego samego nadawcy, co wcześniej. – Muis
Jeśli minimalizacja rozmiaru podpisu ma kluczowe znaczenie, wówczas RSA jest słaby wybór na początek. DSA i ECDSA generują krótsze podpisy o znacznie większej sile niż RSA. Jednak ani DSA, ani ECDSA nie zbliży się do szybkości weryfikacji podpisu dla RSA 384.
Jeśli jednak musisz nadal używać kluczy, które posiadasz, będziesz musiał zmienić kod, aby uniknąć korzystania z funkcji API kryptografii Microsoft. Możesz użyć np. Biblioteki Bouncycastle C#, jeśli używasz C#. Na koniec możesz złożyć skargę do firmy Microsoft w tej sprawie. Wątpię, czy to będzie dobre, ale zawsze możesz spróbować.
Moim głównym zarzutem jest to, że ogłosili to dopiero na 1 miesiąc przed wprowadzeniem tej zmiany. Mam zainstalowaną bazę prawie pół miliona użytkowników i brak funkcji automatycznej aktualizacji, więc nie będzie sposobu, aby upewnić się, że wszyscy zaktualizowali oprogramowanie przed trafieniem poprawki. – Muis
@ Joshuo, słyszę cię. –
Należy zauważyć, że generowanie kluczy i, co ważniejsze, tworzenie sygnatur jest o wiele szybsze, gdy używa się ECDSA w porównaniu z kluczem RSA o podobnej mocy. Zależy więc od protokołu i całego systemu, który jest najbardziej korzystny. –
Dostałem odpowiedź od Microsft (Kurt L Hudson), a ta zmiana powinna dotyczyć tylko chainbuilding, więc wydaje RSACryptoServiceProvider będzie nadal działać z małymi keysizes po sierpniu 2012 roku
Zgodnie z powiązanym artykułem dotyczy to wszystkiego, co wykorzystuje funkcję budowania łańcucha, co obejmuje SSL i S/MIME (inaczej CMS). Inni użytkownicy o małych rozmiarach kluczy powinni sprawdzić, których protokołów i funkcji używają. –
wow dzięki za co mi to zauważyć. – ericosg
Najprawdopodobniej będziesz miał kłopoty (jeśli nie z tą poprawką, a następnie z jedną z następnych), ale twój obecny kod jest wadliwy na pierwszym miejscu: 384-bitowe klucze RSA są SŁABE i musisz rozważyć ich aktualizację do co najmniej 1024 bity ASAP nie czekają na poprawki Microsoftu. –
W ciągu kilku dni możesz złamać klucz 384 bitowy na komputerze stacjonarnym. A może tygodnie? – Wug