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, който е създаден за да е максимално бърз. Иначе по отношение на скоростта аз и в първия пост казах, че скоростта не е от значение - тя така или иначе е нищожно количество загубено време, но съществено количество софтуер трябва да я тика.