วีดีโอ

Про випадкові та псевдовипадкові числа: Числа згенеровані 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

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

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

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

Був в NLTK наскільки пам'ятаю для англійської. Для української не пам'ятаю чи є щось (стемери точно є), для російської є mystem, який працює по морфологічним правилам. Але я так давно дивився на них, що й не пам'ятаю. В більшості випадків стемер підходить

@@AboutProgramming а є щось подивитись як для української мови стеммер зробити? Хотілось наш пошук на сайті покращити в рази. Використовуємо базу постгрес. Бо в нас пошук по назві документу і по вмісту документу. Був би дуже вдячний. Або почитати як самому його зробити

@@oleksiymiyskiy4694 знаходив таке github.com/amakukha/stemmers_ukrainian , але щоб конкретне порадити, то складно. Якщо потрібен просто пошук, то ніби є під еластік готове www.elastic.co/guide/en/elasticsearch/plugins/current/analysis-ukrainian.html

Дякую за відгук. Радий, що вийшло корисно)

А що саме деза? Що я не криптограф чи базові концепції криптографії?) Я просто працюю з криптографію зі сторони програмної інженерії й інформаційної безпеки, ніж як криптограф математик. Але уявив собі, як можна було б з бабцями біля під'їзду робити влог для Ютубу)) Відносно мого попереднього досвіду, то трохи тут було th-cam.com/video/JE7mzAVm5bk/w-d-xo.htmlsi=QL9fuJ4bh_NpGktx

@@AboutProgramming добре прийнято,якщо шо,то я вибачаюсь...

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

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

В яку саме?

Публічний ключ шифрує, а приватний разшифровує - в іншу сторону не працює

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

@@AboutProgramming Ага, там трошки інакше, у кожного свій приклад просто в голові з'явився У випадку з цифровим підписом приватний ключ використовується для підпису (шифрування хешу), а публічний ключ - для його розшифрування. У передачі даних (наприклад, через HTTPS) асиметричне шифрування використовується дещо по-іншому: Публічний ключ використовується для шифрування даних, Приватний ключ використовується для розшифрування цих даних

Не зовсім так. В https публічний ключ для шифрування даних не використовується, дані шифруються симетричними ключем AES або Chacha20. Раніше публічним ключем шифрували симетричний ключ, але зараз такого теж не роблять, бо це не дає perfect forward secrecy. Тому зараз DHKE для обміну симетричним ключем це стандарт в HTTPS. А от в PGP симетричний ключ шифрується публічним, але самі дані теж шифруються симетричним

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

Зазвичай на більшості проектів ми використаємо еластік, але тут були дещо специфічні вимоги й необхідність більшого контролю над форматом. В цілому це сотні терабайт даних, сотні різних індексів й аналітичні запити. Зараз elastic краще став й можливо б використовували б його, але не факт. Подобалася ідея, що не треба тримати дорогої інфраструктури - все просто на S3. Наприклад, Hadoop кластер був на S3, а не HDFS, що дозволяло створювати сервера тільки на момент обробки даних. Аналогічно якщо розбити індекс на два файли - в одному просто слово й зміщення в іншому файлі (по ньому робити бінарний пошук), а в іншому файлі тільки індекс (читаємо тільки зміщення), то можна індекс на сотні терабайт тримати на S3 й обробляти запити невеличким сервісом, а не платити за compute

@@AboutProgramming 👍, просто з цікавості спитав. Я працював на одному проекті де треба etl то ми також ранили на on-demand Hadoop (AWS EMR), хоча там такий треш що наврядче це гарний приклад але ідея зрозуміла.

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

Дякую за такий позитивний відгук)

В розподілених системах може бути корисно. Наприклад, при master master реплікації. Ще варіант, це коли айді генерує клієнт. Часом роблять, щоб не світити кількість записів (хоча краще тоді окремою колонкою). Й відповідно, в якійсь момент розробники вирішують, що це гарний підхід по замовчуванню, бо ніби uuid вміє те саме, що й auto increment, але трохи більше

​@@AboutProgramming дякую за відповідь. корисно як і саме відео! master master реплікації - uuid роблять щоб не було загублених чи не вірно оновлених даних через затримку звязку ? завжди думав, що master master реплікації не мають сенсу в реальному часі, а краще - один записує. інші читають і раз в деякий час, копіюють в резервний (як бінарний масив передає файл потоком - частинами.) Хоча я тут не маю досвіду, тому не бачу всієї картини. мене останє дуже часто дивує - коли, особливо коли, на бекенді ігнорують память і швидкість - головне щоб було модерново. Ладно ще фронт може ігнорувати, бо бере конкретні дані і зазвичай вони обмежені кількістю, але чомусь бекенд ігнорує це частіше. Відео про алкоритми мені сподобалось, хоча я б використовував reduce, але алгоритми цікаві, особливо пошук хешем чи сортування Хоара. Не знав як це корисно міняє мислення, поки не почав цікавитись. Тому дійсно гарні теми ви вибрали для відео. про - не світити кількість записів, трохи дивно звучить, особливо коли у відповіді є довжина. та і не зустрічав я в житті коли айді генерує клієнт. Клієнт не повинен працювати настільки з бізнес логікою, хоча - в світі є різні дивовижні створіння. як фейсбук, який не відправляє повідомлення і є соц мережею )

Вже був десь на каналі)

@@AboutProgramming уже нашел) полнотекстовый индекс еще было бы здоро. Низкий тебе поклон

@@AboutProgramming Какие языки программирования вы знаете?

Про інвертовані індекси відео є теж)

12 років писав на Perl й JavaScript. Зараз пишу на Typescript й Java. Робив пару проектів на vb.net колись. Й писав усілякі дрібниці на C та golang

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

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

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

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

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

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

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

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

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