On Wednesday, January 15, 2020 at 2:00:40 PM UTC+1, Borneq wrote:
> W dniu 2020-01-15 o 09:48, Maciej Sobczak pisze:
> >> A po prostu openssl?
> >
> > Nie kojarzy mi się z określeniem "lekka". :-)
> > To ma chodzić na mikrokontrolerze i ma tam nie dominować nad właściwą aplikacją.
O ile w ogóle da się ją tak użyć.
> >
> > Bo w szczególności to, co autor (jakiejkolwiek) biblioteki wyobrażał sobie na
temat środowiska kompilacji to jest ogólnie nieprawda. Dlatego zależy mi na tym, żeby
była "hackowalna", czyli jak najprostsza w rozszarpywaniu jej na kawałki i
przeszczepianiu w inne miejsce. W tej kategorii najfajniej wyglądają BeeCrypt (ale ma
trudną licencję) i właśnie Andrzejowe DCPCryptCpp (ale nie ma asymetrycznych
algorytmów).
> >
> Trzeba by jeszcze sprawdzić dokładnie licencje:
> Tłumaczyłem z https://wiki.freepascal.org/DCPcrypt które ma właśnie
> licencję MIT, do tego włączyłem fajną obsługę sha3 (kiedyś miałem inną,
> powolną i mniej czytelną) z innego projektu i Argon2.
> Może kiedyś jeszcze wezmę się aby napisać inną część biblioteki
> rozbudowaną o podpisy, ale tu:
> - potrzeba źródła entropii
> - musi być random bezpieczne kryptograficznie
> - operacje na dużych liczbach, wykonuje to Boost, ale może dla prędkości
> trzeba by włączyć trochę kodu GMP, zarówno dla random jak i dla kluczy.
> Dla RSA trzeba by sporo mieć kodu działąjącego na dużych liczbach, bo tu
> byłoby wiele typów operacji gdy szukamy liczb pierwszych.
> Nie wiem za bardzo czy kryptografia krzywych eliptycznych nie powoduje,
> że kryptografia liczb pierwszych przestaje być potrzebna? Dla krzywych
> eliptycznych możemy działać na o wiele krótszych liczbach i chyba ma
> wszystkie właściwości asymetryczne?

I nie mogą to być byle jakie liczby pierwsze, poza oczywistym faktem że
muszą być duże, musi być  też miedzy nimi duży odstęp (są metody łamania
gdy między liczbami jest mały odstęp) i jeszcze kilka wymogów. Jakaś
pomyłka w tych szczegółach i algorytm szyfrujący jest podatny na łamanie.

Pozdrawiam