Предимства и недостатъци на симетричните алгоритми за криптиране Основният (и почти единствен) недостатък на симетричните алгоритми е фактът, че и двете страни трябва да имат предварително договорен (pre-shared) ключ. Колкото по-продължителна е сесията (обменът на данни) с използване на един и същи ключ, толкова повече ciphertext може да събере един third-party подслушвач, и съответно толкова по-голяма става вероятността той да успее да намери ключа и да декриптира както това, което е минало "по жицата" до момента, така и бъдещите данни, криптирани със същия ключ. Съвременните симетрични алгоритми за криптиране на данни като IDEA, CAST, AES, Blowfish или Twofish, правят работата на криптоаналитика все по-трудна, но все пак тук освен за вероятности (винаги е възможно ключът да се окаже един от първите 20, които той пробва дори в опита си за пълно изчерпване) говорим и за продължителни сесии, при които криптоаналитикът има допълнителното предимство на правенето на доста вероятни предположения за структурата на предавания пакет от данни. Например, ако подслушваме нещо, за което знаем, че е криптирана връзка, по която се предават HTTP заявки и отговори, и видим известна пауза, след което едната страна предаде малък пакет данни, а другата й отговори с два-три или повече пъти по-голям, има много голяма вероятност малкият пакет да е започвал с нещо от вида на "GET ..... HTTP/1.0\r\n", където GET може да бъде и POST, а HTTP/1.0 може да бъде и HTTP/1.1, а големият пакет да е започвал с нещо като "HTTP/1.1 200 OK\r\n". Това вече отваря прекрасна възможност за т.нар. known-plaintext атаки, т.е. атаки, при които знаем и некриптирания текст, и криптирания отговор, и просто търсим ключ, който ще превърне едното в другото. Имайте предвид, че това, което описвам като "продължителна сесия", съвсем не е задължително да бъде *една* сесия, една connection, или нещо такова. Това с пълна сила важи и за случаи, когато един и същи ключ за симетричен алгоритъм се използва при *повече от една* сесия, повече от една connection - дори тогава е още по-лесно, защото в такъв случай на криптоаналитика му е напълно ясно къде започват отделните connections, и е още по-лесно да се правят предположения за plaintext, защото повечето протоколи имат добре известен формат за първоначалното установяване на връзката (т.нар. handshake) или поне за командите, които могат да бъдат предадени в този момент. Добре, значи това са недостатъците на симетричните алгоритми; но не споменах ли в началото, че ще говоря и за предимствата им? :) Или поне ще обясня защо е удобно и надеждно използването на схема, подобна на тази на SSL: в началото на сесията клиентът и сървърът използват някакъв асиметричен алгоритъм, за да се договорят за сесийни ключове, и в останалата част от сесията използват тези временни сесийни ключове, обикновено именно за някакъв симетричен алгоритъм. Важен момент също е т.нар. rekeying - от време на време някоя от двете страни решава, че този session key е бил използван прекалено дълго, и за да не улеснява допълнително задачите на споменатия горе криптоаналитик, предава на другата страна нов session key, с който да продължи комуникацията. Основната причина да се прави това, и основното предимство на симетричните алгоритми за криптиране на данни по време на тези сесии е фактът, че за кажи-речи всички симетрични алгоритми има реализации, които са много по-бързи от най-бързите реализации на асиметричните алгоритми. Наистина, повечето симетрични алгоритми са базирани на основни математически и логически операции като събиране, изключващо "или" (XOR), разместване на битове и т.н., които могат да бъдат реализирани много, много бързо както с програмен код за general-purpose процесори (т.е. самият централен процесор на компютъра ви може да го прави бързо), така и със специализирани хардуерни ускорители, които дори няма нужда да бъдат истински процесори (макар че обикновено са нещо такова). Асиметричните алгоритми пък обикновено разчитат на тежки операции като повдигане на степен, изчисляване на остатък при деление и какво ли не още, които със сигурност са много, много по-бавни. При това положение, ако можем често да сменяме сесийните ключове *и* самата промяна на сесийни ключове да бъде договаряна чрез пакети, криптирани с *асиметричен* алгоритъм, вече имаме много по-голяма степен на сигурност - макар че криптоаналитикът отново има база за known-plaintext атаки, той разполага с много, много по-малко ciphertext за всяка отделна под-сесия, която използва само един ключ. Още едно предимство на симетричните алгоритми при използването им за криптиране на части от сесията е и това, че при тях няма почти никакви ограничения за самия ключ: той може да бъде почти произволна последователност от битове, т.е. може просто да бъде случайно генерирана последователност от байтове. Разбира се, това не е точно така: за всеки алгоритъм има определени ключове, за които е известно, че или не правят никакво криптиране (в повечето случаи ключ, състоящ се само от нули, ще даде като резултат нещо, което е много близо до plaintext-а), или могат да бъдат разпознати лесно; за алгоритъма DES от много години насам са известни четири тривиални, шест странни и 48 слаби ключа; за повече информация http://google.com/search?q=DES+weak+keys :) За някои от другите алгоритми също са известни слаби ключове, но общо-взето можем да разчитаме на случайно генерирани последователности от битове (Ааааааааааа... за това последното изречение май ще си изкарам боя от доста хора :) - или поне можем да разчитаме на известни алгоритми за проверка за това дали сме успели да си измислим ключ, който всъщност не е добре да ползваме. За повече информация, както споменах, Google - не само за DES, и за доста други алгоритми са известни слаби ключове. С две думи, симетричните алгоритми са *много* лошо standalone решение - никога, ама никога не използвайте симетричен алгоритъм за криптиране на продължителна сесия! В същото време обаче, комбинацията от асиметричен алгоритъм за договаряне на ключове, какъвто е примерно Diffie-Hellman, и симетричен алгоритъм за криптиране на данните в сесията с rekeying на разумен интервал от време, е най-добрият намерен засега компромис между сигурност и ефективност.