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?