Użytkownik "J.F." <j...@p...onet.pl> napisał w wiadomości
news:1icuael7xhem8$.128hw8dep8au9.dlg@40tude.net...
>> Ja mam komputer sprzed może 5 lat i jeszcze nigdy nie zauważyłem aby był
>> wolniejszy ode mnie (AESa czy SHA256 przelicza w 1us).
>
> Jestes pewien ? AES to chyba dosc skomplikowany szyfr i 1us moze byc
> malo.
W konkursie na AES wybrali jeden z 3 czy 5 finalistów. Wcale nie wybrali
tego najbezpieczniejszego tylko ten najefektywniejszy w implementacji.
Nie mogę teraz znaleźć, gdzie mam zanotowane wyniki różnych prób. Według
mojej najlepszej pamięci:
DES - około 0,45us (64 bitowy algorytm z kluczem 56bitów - dostosowany
bardziej do realizacji sprzętowej niż programowej)
AES128 - około 1,2us (128 bitowy z kluczem 128 bitowym)
SHA256 stosuję do wydłużenia hasła - 1 000 000 wykonań (dane mieszczą się w
jednym bloku) trwa poniżej 2s.

Wszystkie algorytmy nie w jakiejś absolutnie nieczytelnej super optymalnej
formie, która różnymi #define i #ifdef dopasowuje się do systemu i maszyny i
najlepiej robi wszystko jako jeden wielki ciąg instrukcji bez pętli i
wywoływania podprocedur tylko zapisane przeze mnie tak, aby były według mnie
jak najczytelniejsze.

>
> W dodatku czesto szyfry zawieraja operacje "nieprocesorowe",
> tzn np "wybierz bity 5, 13, 21 i 27" jest upierdliwa.

Tak było w DESie - sprzętowo banalne - odpowiednie druciki lecą w
odpowiednie miejsca, programowo koszmarek.

Największą wadą AES (według pewnych ekspertów) jest to, że jest pięknie
zapisany matematycznie (w jakiejś tam algebrze czy jak to się zwie) bez
żadnych takich kombinacji. Nie można wykluczyć, że kiedyś jakiś student
matematyki wpadnie na jakieś analityczne rozwiązanie i swój referat zakończy
słowami: "stosując tę metodę na moim PC złamanie AES zajmuje ..... minut."

byte AES::SBox[256]={0x63,0x7C,0x77,..........,0x54,0xBB,
0x16};

void __fastcall AES::Encode(byte d[16])
{
static byte M2[256]={0x00,0x02,0x04,........,0xE1,0xE7,0xE5};
static byte M3[256]={0x00,0x03,0x06,.........0x1C,0x19,0x1A};

int i,j;
byte b[16];
byte *k=Key;
for(j=0;j<16;j+=4){*(dword*)(d+j)^=*(dword*)(k);k+=4
;}

for(i=Nr;i--;) // kolejne rundy
{
for(j=0;j<16;++j)b[j]=SBox[d[(j+((j&3)<<2))&0xF]]; // ShiftRows i
SubBytes

if(i)for(j=0;j<16;j+=4) // MixColumns i AddRoundKey
{
d[j] = M2[b[j]] ^ M3[b[j+1]] ^ b[j+2] ^ b[j+3] ^ *(k++);
d[j+1]= b[j] ^ M2[b[j+1]] ^ M3[b[j+2]] ^ b[j+3] ^ *(k++);
d[j+2]= b[j] ^ b[j+1] ^ M2[b[j+2]] ^ M3[b[j+3]] ^ *(k++);
d[j+3]= M3[b[j]] ^ b[j+1] ^ b[j+2] ^ M2[b[j+3]] ^ *(k++);
}
else
for(j=0;j<16;j+=4){*(dword*)(d+j)=*(dword*)(b+j)^*(d
word*)(k);k+=4;}
}
}

Skróciłem tabele M2 i M3 (to nie są tabele "z sufitu" tylko ztabelaryzowane
policzalne funkcje (chyba druga i trzecia potęga ale w jakimś dziwnym
matematycznym świecie). Z komentarza // ShiftRows i SubBytes wnioskuję, że
SBox to tylko jakieś przesunięcia (nie to co SBox w DES). Nie pamiętam -
pisałem to 5 lat temu.

> Tak czy inaczej - liczy tego AES wielokrotnie szybciej niz czlowiek
> :-)
>
> Ale inne rzeczy juz niekoniecznie sa takie szybkie, ja blyskawicznie
> zaplanuje trase z Wroclawia do Olsztyna, wystarczy rzut oka na mape.
> A nawigacja liczy i liczy ... fakt ze czasem obliczy lepsza :-)
Albo wyprowadzi w totalne maliny.....
Jechałem Zakopane-Białystok. Zaplanowałem poprzedniego dnia. Sprawdziłem jak
przejeżdża przez Kraków - było OK. Ale w Krakowie zjechałem na stację
benzynową i przeliczył od nowa. Już po chwili jechaliśmy uliczkami
osiedlowymi, potem koło jakiegoś cmentarza i na działki na polną drogę na
środku której była wysoka na 1m sterta gruzu nie do przejechania (znaczy
czołgiem by się dało).
P.G.