Piotr Gałka wrote:
> 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.
Jak dobry kompilator to sobie jakoś radzi, jak gorszy to gorzej.
Czasami w asemblerze można coś bardziej zwarcie napisać.

Jednak w dłuższej perspektywie, pisanie w asm to strata czasu i proszenie
się o kłopoty; zmienia się platforma i musisz
pisać/testować/poprawiać/testować itd, od nowa.

Jeśli procesor już nie radzi sobie z zagadnieniem to trzeba wziąć większy
procesor zamiast schodzić do asemblera.

jp





>
> 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.

--
jp

www.flowservice.pl
www.flowsystem.pl