Що захищає твої дані й гроші від хакерів? Асиметричне шифрування та цифровий підпис

[@rkiyanchuk]

Дякую за відео, мені здається воно гарно висвітлює чимало криптографічних концептів на інтуїтивному рівні! Зроблю кілька важливих уточнень стосовно криптографії: Про RSA: Не коректно говорити, що ключі RSA є рівнозначними чи що їх можна взаємно заміняти. Це розповсюджене помилкове сприйняття через надмірне спрощення алгоритму RSA. В алгоритмі є відкрита та приватна *експоненти* (не ключі) які зазвичай помічають як `e` та `d`, тоді базове перетворення RSA спрощено можна записати наступним чином:

 C ≡ M^e mod N; M ≡ C^d mod N ≡ M^e^d mod N ≡ M^(e*d) mod N ≡ M (оскільки M^(ϕ(n)) ≡ 1 mod N). І виглядає, як ніби значення e та d можна взаємозаміняти, оскільки операція множення є комутативною. Ці експоненти також часто називають "ключами", хоча це неправильно - вони є лише складовими відкритого та приватного ключа. Відкритий ключ складається зі значень (N, e), тобто модуля та відкритої експоненти, а приватний ключ: мінімум із значень (N, d) (на практиці їх більше). Проте описане вище перетворення є виключно теоретичним і на практиці не використовується в такому виді. Це ще називають "Textbook RSA", бо зазвичай з цього починають пояснення _теорії_ алгоритму RSA в книжках з криптографії. У реальних сучасних системах RSA завжди має доповнення (padding) без якого алгоритм не є надійним, відкрита експонента фіксована наперед і дорівнює 0x10001 (переважно повʼязано з оптимізацією операції шифрування та захисту від різного роду атак), а приватний ключ складається з більшої кількості значень: N, e, d, а також p, q (множники модуля), та ще кілька похідних значень що використовуються для оптимізації обчислень).

У цьому можна переконатись, зберігши згенеровані ключі у форматі PEM, та продивитися їх читабельну репрезентацію через openssl:

 Для відкритого ключа: $ 
openssl rsa -in pub.key -pubin -noout -text Для приватного ключа: $ openssl rsa -in priv.key -noout -text

[@rkiyanchuk]

Про випадкові та псевдовипадкові числа: Числа згенеровані math.random() не можна використовувати для шифрування не тому, що вони псевдовипадкові. В псевдовипадкових числах загалом немає нічого поганого, і більшість криптографічних ключів в сучасних системах згенеровані саме з *псевдовипадкових* чисел. Чому ж їх називають *псевдо*-випадковими? Створення випадкових чисел - насправді дуже глибока тема, але спробуємо спростити. Справді випадкові числа (True Random Numbers) - це числа які жодним чином неможливо передбачити і які не відповідають жодному закону чи алгоритму. Скільки б випадкових бітів ви не отримували, ви ніколи не зможете передбачити наступний біт, або віднайти біти що передували їм. Зазвичай такі числа можна отримати лише шляхом спостереження недетермінованих хаотичних фізичних процесів (як Cloudflare це робить з лавалампами: www.cloudflare.com/learning/ssl/lava-lamp-encryption ). Але по-перше, для генерування таких чисел потрібне спеціалізоване апаратне забезпечення, по-друге - інколи нам *потрібно* мати змогу відновити послідовність або детерміновано згенерувати її (інакше для узгодження ключів нам завжди доводилося б передавати розмір ключів що дорівнює розміру повідомлення!). Для цього використовуються *криптографічно стійкі генератори псевдовипадкових чисел* і їх задача - згенерувати числа детермінованим алгоритмом, проте які б в практичному застосуванні ніяк не відрізнялись би від справді випадкових (indistinguishable from true random). Вони не є справді випадковими (бо згенеровані за певним алгоритмом), але виглядають випадковими за всіма ознаками які ми можемо спостерігати, тому вони "псевдовипадкові". Для якісних псевдовипадкових чисел ми так само не можемо ні передбачити майбутні згенеровані числа, ні відновити попередні, скільки б згенерованих чисел ми не спостерігали (лише в практичному сенсі; теоретично для псевдовипадкових чисел насправді завжди є певна кількість, отримавши яку ми змогли б передбачити наступні, та про це далі). Але є одне "але" - звичайно ж псевдовипадкові числа мають якось відрізнятись від "трушних" випадкових, інакше ми б не називали їх "псевдо"-випадковими. І ця відмінність - наявність скінченного періода. Коли ми спостерігаємо за непередбачуваним фізичним процесом - отримані (true) випадкові числа НІКОЛИ не повторяться. Але генератор *псевдо*-випадкових чисел завжди рано чи пізно почне повторювати згенеровану послідовність. Кожний генератор випадкових чисел починає роботу з якогось початкового значення (seed) і теоретичний максимум періоду напряму залежить від нього: для початкового значення розміром в n біт максимальний період згенерованої послідовності буде 2^n, після цього послідовність гарантовано повториться. Цим і відрізняються псевдовипадкові числа від "справді" випадкових. Звичайно для криптографічних застосувань нам потрібно мати великий період щоб впевнитись, що на практиці згенеровані псевдовипадкові числа не повторювались.
 Але що ж тоді не так з math.random() та іншими генераторами випадкових чисел що не є криптографічно стійкими? Такі генератори зазвичай забезпечують лише одну єдину властивість випадкових чисел - рівномірний розподіл. І цього вистачає для більшості застосувань, як то симуляції чи неазартні ігри. Проте такі генератори часто є лінійними, і отримавши певну кількість згенерованих ними чисел ви зможете передбачити всі майбутні та відновити минулі числа, згенеровані з даного початкового значення. Наприклад у випадку генератора Mersenne Twister достатньо отримати 624 значення щоб зуміти передбачити усі наступні згенеровані числа. Також мушу виправити, що ChaCha20 розробив все ж не Google, а незалежний криптограф Деніел Бернштейн. Можливо малося на увазі що Google його застосовує :) Проте цей шифр один з двох, що підтримується в TLS 1.3, тож користується ним насправді багато хто :) Для розробників яким цікаво більше дізнатися про криптографію рекомендую книгу "Serious Cryptography" " від Жана Аумассона, якраз нещодавно вийшла оновлена друга редакція: nostarch.com/serious-cryptography-2nd-edition

[@AboutProgramming]

Коментар - топ! Дякую! Так, коли вже виклав відео, то спробував реалізувати руками RSA алгоритм на невеликих простих числах. Так, операції комутативні й основна частина публічного ключа це N й цей модуль однаковий для операцій в обидві сторони. Тобто на практиці його не можна зробити приватним. Тобто матиматично операції шифруваня й розшифрування відбувається однаково (тільки в одному випадку e, в другому d), але зробити d публічним не вийде, бо вся складність взлому впирається не в "е" (яка є стандартизованою екпонентою), а в розкладі N на множникі p та q

[@AboutProgramming]

@@rkiyanchuk Коментар про випадкові числа просто краса. Ніколи не думав про скічненність послідовності. Думав, що все впирається в генератор (чи можна по послідовності передбачити наступні числа) й криптографічний сід, що джерелом має бути справжеє випадкове число, що базується на якомусь зовнішньому інпуті (з фізичного світу). Відносно ChaCha20, це я наплутав. Можливо через RFC 7539, який від Гугла, й здається Гугл займався додаванням ChaCha20 в OpenSSL. Запінив коментар, має бути корисно для всіх глядачів цього відео. Круті коментарі! Дуже дякую за виправлення та доповнення!

[@rkiyanchuk]

Саме так, і тут ми логічно підходимо до загрози квантового компʼютера 😉😄

[@yuriimakarov4832]

Віктор інженерний Uncle який всім потрібен, допомагає розібратися з будь яким питанням в цьому складному світі програмування!)

[@TVV14]

Чудове відео, дуже інформативно і корисно! Так тримати, Вікторе!

[@vaysberg_]

що не відос - то скарбниця знань, дякую, було дуже корисно і не менш цікаво

[@olexiy-not-alexey]

Тема супер. Дуже подобається, як розклав все по поличках!)

[@Naikshy]

Дуже круте відео, як завжди все дуже лаконічно, періодично передивляюся ваші відео щоб згадати базу)

[@yyev89]

Дуже цікаво й корисно, взагалі тема безпеки сама по собі крута, хотілось би більше відео про це, якщо можна)

[@v.ilchenko]

Дуже круте відео і максимально зрозуміла подача. Дякую! вже додаю це в наш список must watch для девів 😊

[@genkovi4]

дякую за відос, додам в список для перегляду тіммейтів. Те відчуття коли довго хотів зробити щось подібне, але ви впорались швидше і краще 😊

[@oleksandrpodustov]

ох, часом провалював я співбесіди по цій темі, а тут так лаконічно та доступно пояснено, кайф, дякую!

[@donutWiggum]

Дуже круте відео. Тема складна, не згодний що легка, бо якраз кількістю і якістю нюансів визначається складність. Дякую, що допомогли хоча б частково розібратися

[@yuriitiunov8803]

Дуже цікаво розповідаєте, вам варто читати курси. Лайк на підтримку каналу.

[@Victor_M_D]

Вивчав криптографію два роки... Відео чудове але воно дійсно концептуальне! Для розуміння більшості речей все ж потрібно хоч раз реалізувати ці алгоритми або хоч поглянути як вони працюють (онлайн з візуалізацією) а ще краще знати модульну математику;) в свій час це було для мене цікаво... але для 95% роботи дійсно достатньо 15 рядочків коду з використанням готових рішень;) дякую!

[@lymphbizkit4344]

Це крутяк, ви просто неймовірний, чекаю на нові відео !!!!!

[@Vlad-fz8ny]

давно ж не було нових відео)

[@sashok10s]

Привіт, дякую за чудові відео. Пропоную ідею для наступного: Коли потрібно використовувати jwt а коли звичайні сесії, в чому різниця, також можна розповісти про використання jwt refresh token і refresh token rotation, reuse detection)

[@doomor]

оо, дуже цікава тема, дякую :) буде кльово щось ще на подобну тематику

[@akiruaUazammetra]

дякую за відео, вподобайка та й коментар для популяризації контенту Слава Україні!

[@vladcid3938]

Йой тільки думав де взяти контент з шифрування. Ну це лайк і обов'язково перегляд

[@AboutProgramming]

@@vladcid3938 дякую за лайк. Але в відео по суті база, тому не очікуй якогось хардкора)

[@vladcid3938]

@@AboutProgramming та все одна не р@снявий же контент дивитися

[@serhii-kj6hr]

@@AboutProgramming ми очікуємо хардкора на цю тему в наступному відео)

[@OnenessVoices]

Дякуємо за україномовний контент! Між тим, пан би хоч словом обмовився про веселкови таблиці, про FIDO… і взагалі БІЛЬШ ЗВЕРНУВ УВАГУ СОУЗАЧІВ НА БІЛЬШ СУЧАСНИ (стійки) технології, стандарти. Бо саме тому, що використовують це «лайно мамонта», ми щодня бачімо тисячи зламаних сервісів. А в нас на сході ДУЖЕ фаховий ворог, якій не заспокоїться ще десятками років! ---- ПЕРЕМОГА НЕОДМІННО БУДЕ НА БОЦІ УКРАЇНИ ! ВІРТЕ та НАПРЯМУ ДОПОМОГАЙТЕ ЗСУ, ТерОбороні, Волонтерам та родинам наших Украінськіх Захісників та Захісниць!

[@AboutProgramming]

Дякую! В відео про веселкові таблиці згадував, коли говорив про сіль. Але буде окреме відео про те, як зберігати паролі в базі й там вже в деталях розповім. Дякую за ідею для теми :)

[@redlinenorma1]

Ох ці українці, тільки б критикувати. Зроби своє відео 😂 а для початківців, щоб взагалі зрозуміти основи основ - все впорядку. Перед тим як літати, треба навчитись ходити 🥴🤓

[@МаксимЦимбалюк-и6б]

Віктор, прошу вас записати відео про електронну пошту, дуже подобається ваша подача матеріалу!

[@AboutProgramming]

Гарна ідея для теми. Дякую!

[@ArtemSinkevychus]

Дякую! Було цікаво

[@kos-iddqd]

Дяка. Як завжди, супер.

[@bruteforceglory]

Все дуже зрозуміло, супер!

[@НиколайСтепанец-г7д]

дякую, дуже цікаво!

[@Dnonatello]

Дуууууууже круте і зрозуміле відео. дякс за контент

[@Dnonatello]

особливо шифрування - завжди було дуже цікаво і сама ідея , яка прийшла комусь в голову в минулому просто геніальна(принаймні на сьогоднішній день)

[@Богдан-р4ы1э]

Дякую за контент

[@AndrewShmorgun]

Дякую за огляд цікавої теми!

[@serhii-kj6hr]

Дуже жаль, що в мої студентські роки не було цього каналу. Якби мені 10 років тому так пояснювали програмування як це робить Віктор - я б був зовсім іншою людиною зараз 😅

[@ops_rv]

Дякую, з цим вже можна починати розбиратись в темі)

[@MrZhekaU]

Дякую за твою круту роботу❤

[@Volodymyr-y1c]

Дуже цікава тема, дякую за відео!

[@cyber_scripter]

Дякую!

[@michaelbochkaryov4167]

Класно зроблено. А от пінгвина я ще не бачив :)

[@popel_]

ура новий відос)

[@Virass]

Коли Віктор заговорив про слона в кімнаті і почав розказувати про доставку публічного ключа, я в цей момент - ну нічого собі, невже мій "казанок" варить як треба...

[@maxyablochkin-0505]

Привіт з Кривого Рогу 👋

[@olegekbondar]

ще варто додати, що при асиметричному шифруванні ми маємо ліміт на розмір даних - не можна зашифрувати дані довші за сам ключ. З симетричним шифруванням такого ліміту немає і можна шифрувати теоретично не обмежений розмір даних

[@mmiro]

Шо??)) Що за дурниці ви говорите?

[@StrangerSaret]

симетричні алгоритми теж працюють з блоками даних фіксованої довжини, а не з усіма даними одночасно. Теоретично, по такій схемі (розбиваючи на блоки) можна шифрувати і за допомогою асиметрії, але самі асиметричні алгоритми просто повільні і тому на практиці таке не використовують.

[@liubkkkk0]

Чи можна змінивши час і дату на телефоні згенерувати одноразовий пароль який буде валідним у майбутньому(до прикладу за 2 дні у визначений проміжок часу)?

[@AboutProgramming]

Круте питання) думаю, що має бути можна, але сам ще перевіряв

[@rkiyanchuk]

У випадку TOTP можна, і раніше коли автоматична синхронізація часу на пристрої не була поширена, існувала проблема розсинхронізації часу між сервером та клієнтським пристроєм. Як наслідок код з клієнтського пристрою не співпадав з сервером. Тому часто додається вікно свободи: приймається не лише поточний код, але й кілька минулих та наступних (зазвичай таке вікно роблять від 1 до 5 хв), що компенсує можливу розбіжність між часом серверу (який зазвичай завжди синхронізований) з часом клієнтського пристрою. В нинішній час це рідко є проблемою (лише на пристроях, на яких навмисно вимкнено автоматичну синхронізацію). Також знаючи seed яким ініційовано TOTP алгоритм можна згенерувати код для будь-якого моменту в минулому і майбутньому, і для цього не обовʼязково змінювати час на самому пристрої.

[@onion8661]

Кльове відео в цілому, але як на мене трохи сумбурне для людей, які не дуже в темі)

[@AboutProgramming]

Так, трохи є, взагалі планував його на 5 хв, а вийшло 37 :)

[@b.shpanchuk]

"Якийсь зловмисник, давайте намалюємо чого чорним" 😀

[@AboutProgramming]

То для контрасту 🙈

[@zoryamba]

топчік, дяка

[@riendlyf]

Хотілось би побачити реальний приклад з ХТТПС за таким сценарієм. Є вебсайт хттпс з сертифікатом (можна селф сігнед), аналізуємо дані що прийшли по ваершарку, тобто беремо дату, сертифікати у нас є, й декодимо. Це реально?

[@AboutProgramming]

Тут основна проблема, що приватного ключа недостатньо для розшифровки трафіку, оскільки зараз для обміну симетричним ключем використовується алгоритм діффі хеллмана. Тобто навіть, якщо слухати весь трафік й бачити весь процес конекту, то симетричний ключ не передається. Окрім того на кожну сесію він новий. Подумаю як це правильно зробити, але mitm з подміною сертифікатів точно буде в відео про https

[@Hordaric]

❤❤❤

[@danyaminakov1501]

в прикладі про гугл аутентифікацію з часом. як один сікрет шариться між клієнтом і сервером?

[@AboutProgramming]

Так, той самий сікрет

[@AboutProgramming]

Якщо питання про механізм шарінгу, то це відбувається один раз під час додавання двофакторної аутентифікації. Сайт показує qr код, а з телефона скануєш й в ньому сікрет або можна вручну вести на телефоні сам сікрет, якщо сайт його показує

[@shramko-dev]

А що у вас за камера?

[@AboutProgramming]

Це відео знімав на Fuji X-E4 + об'єктив XC 15-45mm. Всі відео з минулого року робив на iPhone. Фон зробив через зелений екран

[@dmytro9279]

тема корисна, продовжуй будь ласка

[@Techn0man1ac]

Що означає "ксорити"?

[@AboutProgramming]

"xor" це "exclusive or" ("виключне або"). Тобто для умови "A xor B" він повертає true якщо або А true, або B true. Якщо обидва true, то xor повертає false (в цьому відмінність від or, й тому це exclusive or). Й відповідно є побітова версія цього оператора, коли порівнюємо просто біти. Ми можемо взяти дві строки й побітово порівнювати їх через xor й на виході отримати нову строку з результатами побітового xor. Це такий спосіб накласти на строку іншу рандому строку й отримати зашифровану строку. Якщо потім на зашифровану строку знову накласти одну з вихідних строк, то отримаємо другу вихідну строку

[@master.joda987]

Mate Academy дійсно крута школа і раніше це працювало але в наш час є великі сумніви з приводу швидкості знаходження першої роботи

[@AboutProgramming]

Так, декілька місяців на пошук зараз треба

[@master.joda987]

@@AboutProgrammingможе декілька років, як піде 😂 насправді, це добре, тепер курсів буде недостатньо, треба буде вчитись декілька років з постійною практикою і самовдосконаленням щоб зайти в професію відповідно, буде менше "випадкових" людей

[@Techn0man1ac]

Як Ви зробили таке боке?

[@AboutProgramming]

Якійсь ефект в Gimp)

[@Techn0man1ac]

@@AboutProgramming А що Gimp дозволяє працювати з відео? Чи це chroma key у Вас?

[@AboutProgramming]

Так, це chromakey + картинка розмита через Gimp. Gimp для відео не вміє такого

[@kamurashev]

👍🤝

[@bohdandudka4358]

15:31 - це можна трактувати як расизм?😅

[@AboutProgramming]

Помилився з вибором кольору маркера й канал закенселили 😅

[@TentakliUA]

В Mate Academy немає C# 😢

[@AboutProgramming]

Так, на жаль, поки немає

[@riendlyf]

0:55 немає посилання на відео, це інформація для автора.

[@AboutProgramming]

Так поспішав викласти відео, що забув. Дякую! Зараз виправлю

[@ВудиВулдбекер]

Видео хорошее и правильное. Но есть одно но. Это все работает без вмешательства ресурсов государств. Ну не все в видео, но многое. Во время войны всякие проги типа Дія опасны. Например Китай. Он имеет кучу оборудования в Украине. Это значит что возможна подмена трафа как между объектами коммуникации так и между сертификационными центрами. Последствия сами понимаете. Это почему в США полным ходом меняется оборудование провайдеров на отечественное. У них гос программа на это.

[@ВудиВулдбекер]

Все варианты где пользователь не получил приватный ключ физически на флешку или сгенерил у себя на компе и не отдал публичный ключ своему контакту опасны во время войны. Да и в этом случае есть варианты и с течением времени все более опасны. Не буду о них.

[@AboutProgramming]

Дякую. Але не до кінця розумію в якому контексті йде мова про небезпеку програм типу Дія. Відносно підміни трафу, то шифрування якраз й вирішує цю проблему. Щоб заглянути в https трафік треба підмінити сертифікат, а для цього він має бути підписаний кимось, кому браузер буде довіряти, але браузери сьогодні мають власні списки сертифікатів кореневих центрів сертифікації. Тобто, я би сказав, що навпаки, в таких умовах шифрування стає більш критичним

[@ВудиВулдбекер]

Не все так безопасно как кажется. Если нужны сервера, которые ломают хттпс траф в пределах компании то могу дать контакты. Тут объяснять тяжко.

[@AboutProgramming]

@@ВудиВулдбекер Так, якщо приватний ключ хтось передав користувачу, то це проблема. Але якщо візьмемо той самий https, то приватний ключ нікому ніколи не передається, підписується лише сертифікат з публічним ключем. Й якщо хтось кудись передає приватний ключ, то це проблема навіть не під час війни. Але згоден, що певні додаткові ризики виникають

[@ВудиВулдбекер]

Да, приватный передавать нельзя. Это я написал старый метод наших банков. Приходишь с флешкой, они генерят ключи и приватный типа у себя не сохраняют.

[@yogalenovo8262]

Мало щось знати, ще треба вміти донести думку... У автора з цим проблеми.

[@AboutProgramming]

А з розумінням чого саме виникають складнощі? Можливо є конкретно якісь аспекти, де було незрозуміло?