<bgdev />^free

wqweto

code2

Криптирането е хубаво нещо, но да ти се набутва готова схема как да се прави е определено "гнила ябълка". Защо няма технология за разработка на индивидуални криптиращи алгоритми, които ако искаш след това за по-голяма сигурност да ги навържеш след стандартните използвани. Тези нестандартни алгоритми да можеш лесно да ги теглиш примерно от сайта на този, който ги разработва, като разчиташ на сигурността на стандартните алгоритми или да си ги вземеш по друг по-чист начин (физическо закупуване на носител).

wqweto

johnfound

Ами лично моето отношение към TLS е малко двойнствено. Да, когато става въпрос за аутентикация, пароли, чувствителни данни и комуникация между хора е ясно, че е задължително.

Но от друга страна, въвеждането на шифроване, сертификати и др.под. много силно повишава изискванията към хардуера и софтуера. Ако обикновеният HTTP може да се поддържа и от най-слабият контролер, то с намесата на криптирането летвата се вдига много високо. И за клиентите и за сървърите.

Все пак, криптираната връзка е на порядък по-надеждна. Което и накланя везните в крайна сметка.

You mad? Всеки x86 от поне 10 г. може да криптира AES със скорости от GB/s, същото вече могат и ARM с Neon. Колко MB да ти е интернет канала на клиент? 10? Значи хабиш 2% CPU за целия канал всички сайтове едновременно, примерно.

Не си в час. Алгоритъмът AES е симетрична крипто система и точно това е изискването при реализацията й - максимална скорост, добро омазване на криптираните данни и сравнително малко изчисления, за да се извърши това. Но HTTPS не залага САМО на симетрично криптиране, защото преди това трябва да се обмени ключа, който вече се предава с а-симетрична крипто система, което е вече многократно по-сложен алгоритъм базиран на дебела математика. Той е и много по-бавен, но това вече не е фактор в конкретния случай.

Личи си че си книжен плъх без реално да си пипал TLS отдолу. Ключ не се обменя вече а се синтезира (key derivation) на база HKDF в последната версия на TLS, като вече input key material ти е нещо разнообразно вкл. shared secret от ECC-то дето твърдиш, че е бавно. Мерил ли си го колко е бавно? Не говоря за 8192-битов RSA а за secp256r2 примерно нещо като за 128-битово секюрити.

В TLS 1.3 няма DH дори, като всичко е ECC с ephemeral keys. Сертификатите са развързани от traffic криптирането и се ползват само за auth което и трябваше отдавна да се направи.

Добре де, в час се оказа. Да само на теория ги знам нещата, но и ти признаваш, че трябва да се ползват елиптични криви, което си е а-симетрична криптография. Сравнено с AES това е в пъти по-сложен алгоритъм. Той е почти толкова сложен като RSA, но последният просто отдавна е разбит за малки дължини, за разлика от ECC, където не знам и малко предвижване напред да е направено (по отношение на разбиването, но не следя нещата от едно 10-на години). Така че, ECC си остава като едно може би 100-на пъти по-бавен от AES алгоритъм. Това, че не се активира всеки път (а просто ключът се преработва) какво значение има, след като поне първият път ти трябва реализация на ECC, която никак не е елементарна. Дори не знам дали има хардуерна реализация за разлика от AES, който е създаден за да е максимално бърз. Иначе по отношение на скоростта аз и в първия пост казах, че скоростта не е от значение - тя така или иначе е нищожно количество загубено време, но съществено количество софтуер трябва да я тика.

ECC в handshake определено е прогрес спрямо RSA в пъти при по-големи ключове и реално няма как да се избегне освен със стратегии за session resumtion както е в TLS 1.3 с PSK.

Идеята е browser-ът като на първа конекция си направи full handshake да получи няколко pre-shared key-я, които да ползва за втора, трета и т.н. конекции без да прави full handshare със същия сървър.

Друг е въпросът, че за perfect forward secrecy пак ще трябва да се генерира shared key с ECC (което е скъпо), но вече поне има опция това да се спести, но честно не съм гледал дали Chrome ползва 0-RTT към сайтове с TLS 1.3 като тръгне да сваля картинките в background.