Zalecana biblioteka szyfrowania .NET

Po przeczytaniu (jeszcze innej) post przez Jeff Atwood mniej więcej stwierdzenie, że nas, deweloperzy śmiertelników, nie powinniśmy zbytnio angażować się w szyfrowanie, zastanawiam się, jakiej biblioteki powinienem używać. Jedyne dwie biblioteki, które uważam za zgodne z prawem, to entlib i Bouncy Castle, ale nie wydają mi się bardziej abstrakcyjne niż interfejsy API kryptografii .NET.Zalecana biblioteka szyfrowania .NET

Domyślam się, że zastanawiam się, czy istnieje "jQuery bibliotek kryptograficznych", która jest prosta, powszechnie zaufana, otwarta i dobrze udokumentowana.

Źródło

2009-07-24 JeremyWeir

Co jest nie tak z 'System.Security.Cryptography'? – Thorarin

@Thorarin - To jest to, co zawsze robiłem, ale myślę, że podstawowym powodem, dla którego ktoś by się nie sprzeciwił, jest to, że jest tak wiele opcji w tym API, że jeśli nie zrozumiesz wszystkiego, skończy się robienie czegoś złego . – JeremyWeir

Drugim, o którym wspomina w artcile, jest Keyczar – ChrisW

edit: Oto niepełna lista popularnych bibliotek kryptograficznych z https://github.com/quozd/awesome-dotnet/blob/master/README.md#cryptography:

BouncyCastle - Wraz z .Net System.Security.Cryptography, implementacja referencyjna dla algorytmów kryptograficznych na CLR.
HashLib - HashLib to zbiór prawie wszystkich algorytmów hash kiedykolwiek widziałem, obsługuje prawie wszystko i jest bardzo łatwy w użyciu
libsodium-net - libsodium NET - Bezpieczna biblioteka kryptograficzna
Pkcs11Interop - Zarządzane NET wrapper dla niezarządzani PKCS # 11 bibliotek, które zapewniają dostęp do sprzętu kryptograficznego
StreamCryptor - szyfrowanie Stream & deszyfrowanie z libsodium i protobuf
SecurityDriven.Inferno - .NET crypto biblioteki. Zawodowo skontrolowany.

Oryginalna odpowiedź jest następująca.

Biblioteka nadmuchiwany zamek jest rzeczywiście dobrze zachowane, a starsze biblioteki szyfrowania, ale co się stało z użyciem wielu fantastycznych funkcji szyfrowania, które są wbudowane w .NET?

System.Security.Cryptography Namespace

Z mojego doświadczenia, te realizacje są solidne, zapewniają liczne opcje (na przykład: masz zwykle dostaliśmy Crypto API, CNG i udało implementacje każdego algorytmu do wyboru), a ty” nie zamierzamy "robić tego źle", ponieważ jesteście tylko przy użyciu implementacji. Jeśli jesteś nieco zaniepokojony, że możesz użyć ich niepoprawnie, zawsze możesz postępować zgodnie z MSDN's own example code.

Źródło

2009-07-24 22:07:33 CraigTP

Myślę, że artykuł (i ich poprzedników), z którym się łączyłem, daje wystarczająco przekonujące powody, dla których większość z nas, deweloperów, prawdopodobnie nie powinna być zbytnio przenoszona za pomocą tej przestrzeni nazw. Sądzę więc, że to wszystko, co mówię, po prostu odchodzę, co brzmi jak dobra rada. http://www.codinghorror.com/blog/archives/001275.html – JeremyWeir

Połączysz się z przykładową implementacją rijndael, ale to decyduje o wyborze między różnymi algorytmami. Wolałbym abstrakcję, która dawałaby mi metody takie jak EncryptStringForBrowser() (przykład podany przez Jeffa), aby ekspert mógł zdecydować się na użycie rijndael lub aes pod maską. – JeremyWeir

@jayrdub - Widzę, co mówisz o abstrakcji, ale nie sądzę, że konieczna jest pełna pełna warstwa dodatkowego kodu (jak w przypadku biblioteki trzeciej strony, np. BC). Nie chcesz go sam wdrożyć z ważnego powodu, a nie chcesz "niewłaściwie używać" implementacji i osłabiać zabezpieczeń. Wszystkie dobre rzeczy, ale myślę, że można to łatwo osiągnąć za pomocą klas wbudowanych frameworka i przykładowego kodu na MSDN. W tym przykładzie podano funkcję stylu "encryptStringToBytes", która sprawia, że jest ona "bezużyteczna" do użycia dla ciągów bez osłabiania bezpieczeństwa. – CraigTP

Bouncy Castle wydaje się być dość powszechnie szanowany

Źródło

2009-07-24 21:54:49

Całkowicie błędnie zrozumiałeś maksymę "nie wdrażaj samodzielnie szyfrowania". Oznacza to, że: nie należy przetaczać własnego RSA/DSA/jakiegokolwiek algorytmu szyfrowania. Nie oznacza to, że nie powinieneś używać tego, który napisał ktoś, kto wie, co robi. W rzeczywistości, jeśli cokolwiek, dodanie większej liczby warstw między tobą a zaufanym algorytmem będzie cię bolało, a nie odwrotnie.

Źródło

2009-07-25 22:48:29

Zgadzam się z tym. –

Oznacza to również "nie twórz własnego algorytmu". Podejście "Nie widzę, jak bym go złamał, więc nie rozumiem, jak ktokolwiek inny" nie zapewnia bezpieczeństwa. –

Nie zgadzam się, po prostu próbuję zrozumieć, czy jest tam jakaś świetna biblioteka, którą przegapiłem, ze względu na sposób, w jaki Jeff omawia próbę uniknięcia używania API .NET na rzecz "sprawdzony, przetestowany przez ekspertów z domeny zestaw kodu, na którym tysiące, jeśli nie miliony programistów, już polegają". Mam wrażenie, że nie ma (oprócz tych dwóch, o których wspomniałem). – JeremyWeir

Blok kryptograficzny EntLib działa dobrze dla większości potrzeb szyfrowania/mieszania.

Źródło

2009-07-26 00:39:47

Zalecana biblioteka szyfrowania .NET

Odpowiedz

Powiązane problemy