W dniu 2023-02-02 o 16:09, Jacek pisze:

> Bo biblioteki pełnia rolę marketingową i poza zastosowania
> eksperymentalne nie powinno się wychodzić.
> Do biznesu zaś, najlepiej trzymać wszystko w czystym kodzie języka
> C i w jak najmniejszym stopniu korzystać ze specyfiki platformy.
> Też stosuję, np. AES128 i mój procesor ma chyba jakieś sprzętowe
> wihajstry do tego ale nie zamierzam korzystać.
>

Kiedyś dawno (trochę dla sportu) na podstawie dokumentów NIST napisałem
(C++) swoje procedury dla DES, AES, SHA, CMAC, HMAC.
Potem jak doszliśmy do szyfrowania komunikacji brat przepisał je na
assembler i na C.
Według tego co wiem od brata (piszę o czymś o czym mam blade pojęcie) w
przypadku AtXmega (nie ma wbudowanego SHA) napisanie w assemblerze daje
kilkukrotną przewagę nad napisaniem w C. Ja to rozumiem tak, że C
blokuje 'dla siebie' ileś rejestrów, a żeby policzyć SHA256 bez ciągłego
przewalania danych między rejestrami a pamięcią trzeba wykorzystać
praktycznie wszystkie rejestry procesora. SHA512 już się tak nie da
napisać i różnica między C a assemblerem będzie mniejsza.

Opis jak się liczy AES-a zrozumiałem na tyle dobrze, że używane tam
tabele wygenerowałem sobie z równań, aby nie ryzykować błędem przy
przepisywaniu, ale dlaczego rozszyfrowywanie nie robione metodą 'do
tyłu' tylko 'inaczej do przodu' daje to samo od czego zaczęliśmy to już
nie całkiem ogarniam.
Chciałbym jeszcze kiedyś na tym samym poziomie zrozumieć wykorzystanie
krzywych eliptycznych w kryptografii niesymetrycznej. Czyli nie
koniecznie jaka matematyka za tym stoi, ale jak to policzyć z
dokładnością do każdego bitu.

Są może gdzieś jakieś przykłady?
P.G.