WEBVTT
00:00:00.000 --> 00:00:01.536
[Translated by Marta-Sofiya Klakovych
(KYBS2004 course assignment at JYU.FI)]
00:00:01.608 --> 00:00:10.438
музика
00:00:10.521 --> 00:00:14.714
Ласкаво просимо до цього хаотичного
року та заходу
00:00:14.714 --> 00:00:17.182
Я Кара і я буду вашим диктором
00:00:17.182 --> 00:00:20.520
Мені приємно оголосити доповідь
00:00:20.520 --> 00:00:21.930
Пост-квантова криптографія:
00:00:21.930 --> 00:00:23.390
обхідні шляхи, затримки та катастрофи,
00:00:23.390 --> 00:00:26.280
яку представляють Таня Ланге
та Д. Дж. Бернштейн.
00:00:26.280 --> 00:00:30.510
Таня Ланге — криптограф і математик,
00:00:30.510 --> 00:00:33.121
яка спеціалізується на пост-квантовій криптографії,
00:00:33.121 --> 00:00:35.621
яка замінює ту криптографію,
яку ми використовуємо сьогодні
00:00:35.621 --> 00:00:38.993
на варіанти, які є безпечними
проти атак квантових комп’ютерів.
00:00:38.993 --> 00:00:42.207
Вона є професоркою технічного
00:00:42.207 --> 00:00:43.207
університету Ейндговена
00:00:43.207 --> 00:00:46.770
і може пишатися численними
публікаціями та відзнаками.
00:00:46.770 --> 00:00:51.250
Вона також була координаторкою PQCrypto,
00:00:51.250 --> 00:00:53.130
що є загальноєвропейською ініціативою
00:00:53.130 --> 00:00:56.556
для впровадження пост-квантової криптографії.
00:00:57.153 --> 00:01:00.830
Д. Дж. Б. є професором університету
00:01:00.830 --> 00:01:01.830
Іллінойсу в Чикаго
00:01:01.830 --> 00:01:06.559
а також професором Університету Бохума.
Він працює в галузі криптографії
00:01:06.559 --> 00:01:09.187
і розробив шифрувальні системи, які використовуються
00:01:09.187 --> 00:01:11.833
у криптографії з відкритим кодом,
можливо, ви зараз
00:01:11.833 --> 00:01:13.812
використовуєте одну з них,
дивлячись цю доповідь.
00:01:13.812 --> 00:01:18.353
Разом вони реалізували вражаючу
кількість проєктів
00:01:18.353 --> 00:01:22.594
від спрощення впровадження
безпечної криптографії
00:01:22.594 --> 00:01:27.271
до створення безпечних
постквантових типів даних.
00:01:27.271 --> 00:01:30.220
Обоє є активістами, які борються
00:01:30.220 --> 00:01:33.145
за прозоріший процес
стандартизації криптографії.
00:01:34.515 --> 00:01:39.224
А тепер всі, поплескайте своїми лапками
00:01:39.224 --> 00:01:44.107
Давайте поаплодуємо
Тані Ланге та Д. Дж. Б.!
00:01:48.128 --> 00:01:51.580
Добре, дякуємо за гарне представлення,
00:01:51.212 --> 00:01:54.782
давайте одразу перейдемо до справи —
почнемо з HTTPS
00:01:54.782 --> 00:01:57.997
Коли ви заходите на сайт із HTTPS
(або захищене з’єднання)
00:01:57.997 --> 00:02:00.553
ви використовуєте TLS — протокол безпеки
00:02:00.553 --> 00:02:03.143
транспортного рівня —
щоб захистити ваше з’єднання.
00:02:03.143 --> 00:02:07.523
TLS використовує два типи криптографії
з кількох причин.
00:02:07.553 --> 00:02:10.409
По-перше, він покладається
на криптографію з відкритим ключем.
00:02:10.509 --> 00:02:14.406
Вона виконує дві функції:
по-перше, вона забезпечує підписи.
00:02:14.406 --> 00:02:18.784
Підписи з відкритим ключем —
вони гарантують, що зловмисник не зможе
00:02:18.784 --> 00:02:21.827
підмінити дані сервера
своїми власними
00:02:21.827 --> 00:02:23.873
і прикидатися сервером.
00:02:23.873 --> 00:02:26.264
Також TLS використовує
шифрування з відкритим ключем
00:02:26.264 --> 00:02:31.123
наприклад, NIST P-256 або
RSA-4096 як систему підпису
00:02:31.123 --> 00:02:36.318
NIST P-256 також можна використовувати
для шифрування, щоб ваші дані були захищені,
00:02:36.590 --> 00:02:39.800
щоб він (зловмисник) не міг їх зрозуміти.
00:02:39.800 --> 00:02:43.691
Через причини, пов’язані з продуктивністю,
криптографія складніша, ніж
00:02:43.782 --> 00:02:48.820
просто криптографія з відкритим ключем —
вона також включає симетричну криптографію
00:02:48.114 --> 00:02:50.704
іноді її називають
криптографією із секретним ключем.
00:02:50.704 --> 00:02:55.597
Коли ви збираєте все разом у TLS,
ви отримуєте три основні складові:
00:02:55.715 --> 00:02:57.525
це шифрування з відкритим ключем,
00:02:57.525 --> 00:03:00.277
яке не шифрує всі ваші дані, а натомість
00:03:00.277 --> 00:03:05.121
шифрує лише ключ,
щоб зловмисники не могли його зрозуміти.
00:03:05.124 --> 00:03:07.304
Цей ключ надсилається
безпечно і конфіденційно
00:03:07.304 --> 00:03:08.983
від однієї сторони до іншої,
00:03:08.983 --> 00:03:11.866
а підписи з відкритим ключем
використовуються, щоб переконатися,
00:03:11.866 --> 00:03:14.499
що зловмисник не може підмінити
інший ключ
00:03:14.499 --> 00:03:17.900
і в кінці цей ключ використовується
00:03:17.900 --> 00:03:19.506
для захисту ваших даних
із використанням симетричної криптографії
00:03:19.729 --> 00:03:24.269
усі інші протоколи, які ви використовуєте,
00:03:24.269 --> 00:03:25.474
можна було б представити
у подібних слайдах
00:03:25.474 --> 00:03:28.514
наприклад, SSH, але вони всі працюють
майже однаково
00:03:28.517 --> 00:03:30.949
я зараз підкреслю два елементи на цьому слайді
00:03:30.949 --> 00:03:33.735
RSA-4096 —
типова система для підпису
00:03:33.735 --> 00:03:36.216
і типова система шифрування —
NIST P-256.
00:03:36.290 --> 00:03:40.850
Тому що ці дві (системи) будуть зламані
через квантові комп’ютери.
00:03:40.930 --> 00:03:43.440
Без квантових комп’ютерів
жодних відомих
00:03:43.440 --> 00:03:44.915
загроз не існувало б, але
00:03:44.915 --> 00:03:46.960
якщо в атакуючого буде
великий квантовий комп’ютер
00:03:46.960 --> 00:03:49.165
а це, найімовірніше, станеться
00:03:49.165 --> 00:03:51.696
хоча це не гарантовано —
може, спроби створити квантовий комп’ютер
00:03:51.696 --> 00:03:53.150
зазнають невдачі з якихось причин
00:03:53.150 --> 00:03:55.720
але зараз виглядає так,
що квантові комп’ютери
00:03:55.720 --> 00:03:57.430
стають дедалі успішнішими
00:03:57.430 --> 00:03:59.125
і як тільки вони стануть достатньо потужними
00:03:59.125 --> 00:04:00.785
можливо, за десять років.
00:04:00.785 --> 00:04:04.890
Тоді нападники зможуть запустити
алгоритм атаки,
00:04:04.890 --> 00:04:07.578
який називається алгоритмом Шора,
що знаходить ваші секретні RSA-ключі і
00:04:07.578 --> 00:04:12.800
секретні ключі NIST P-256,
і тоді зловмисники зможуть
00:04:12.800 --> 00:04:14.714
отримати доступ до інформації,
яку вони вже зараз зберігають
00:04:14.714 --> 00:04:17.324
це загроза не лише майбутнім даним,
00:04:17.324 --> 00:04:21.500
але і конфіденційності ваших поточних даних
00:04:21.500 --> 00:04:25.900
бо зловмисники вже зараз
зберігають все, що можуть, з Інтернету
00:04:25.900 --> 00:04:27.416
і коли у них буде
великий квантовий комп’ютер
00:04:27.416 --> 00:04:33.506
вони зможуть розшифрувати все заднім числом,
бо зламають RSA-4096
00:04:33.506 --> 00:04:39.213
і NIST P-256,
а саме NIST P-256 забезпечує шифрування
00:04:39.213 --> 00:04:40.487
і вони зможуть повернутися в минуле
00:04:40.487 --> 00:04:42.947
і зламати шифрування, яке ви використовуєте сьогодні.
00:04:42.947 --> 00:04:45.688
Що ж нам із цим робити?
00:04:45.688 --> 00:04:48.270
Стандартний підхід — це те,
що ми називаємо
00:04:48.270 --> 00:04:50.562
постквантовою криптографією —
ви вже чули цю назву раніше, вона була
00:04:50.562 --> 00:04:53.920
в назві нашої доповіді —
це криптографія, яка створена спеціально
00:04:53.920 --> 00:04:57.168
з урахуванням того,
що атакуючий має квантовий комп’ютер.
00:04:58.915 --> 00:05:02.405
Тож, як уже казав ведучий,
00:05:02.405 --> 00:05:05.438
я була координаторкою проєкту PQCRYPTO
00:05:05.438 --> 00:05:09.950
і це означає, що я об’їздила
світ із доповідями про постквантову криптографію.
00:05:09.950 --> 00:05:14.470
Ось скріншот із виступу,
який я провела шість з половиною років тому
00:05:14.470 --> 00:05:19.852
де я підкреслювала, як сьогодні це зробив Ден,
важливість постквантової криптографії
00:05:20.700 --> 00:05:23.507
і наголошувала, що важливо давати рекомендації,
00:05:23.507 --> 00:05:26.904
які визначають, які алгоритми
варто використовувати для заміни RSA та
00:05:26.904 --> 00:05:31.780
NIST P-256, які
ви бачили на попередніх слайдах
00:05:31.275 --> 00:05:36.656
і тоді я поставила питання —
чи варто нам стандартизувати зараз чи пізніше.
00:05:37.120 --> 00:05:43.110
Аргументи існують з обох сторін,
і ну… якби ми стандартизували тоді,
00:05:43.110 --> 00:05:44.842
шість років тому, здавалося, що
00:05:44.842 --> 00:05:46.575
ще занадто багато роботи, і що ми отримаємо
00:05:46.575 --> 00:05:49.950
набагато кращу систему,
якщо трохи зачекаємо,
00:05:49.950 --> 00:05:57.222
але з іншого боку існує занепокоєння
через дані, які збирають уряди та інші темні сили.
00:05:57.256 --> 00:06:03.836
І чим пізніше це буде опубліковано, тим більше даних і безпеки буде втрачено,
00:06:03.836 --> 00:06:09.148
тому важливо просуватися вперед,
і тоді нашою відповіддю було таке:
00:06:09.148 --> 00:06:13.237
те, що я просувала у 2016 році —
це рекомендації, опубліковані у 2015 році, в яких
00:06:13.237 --> 00:06:17.430
йшлося про те, що
стандартизація займає багато часу
00:06:17.430 --> 00:06:21.180
ми ще не на тій стадії,
але якщо хтось хоче захистити себе.
00:06:21.180 --> 00:06:24.672
Ось що ми… ну, тобто ціла група дослідників,
00:06:24.672 --> 00:06:28.872
які підписали цю заяву
як частину проєкту PQCRYPTO.
00:06:28.872 --> 00:06:34.682
Що ми рекомендували?
Наша рекомендація була у тому, що ми назвали
00:06:34.682 --> 00:06:36.387
«обережною криптографією»
00:06:36.387 --> 00:06:38.254
і це не означає
політичний консерватизм
00:06:38.254 --> 00:06:42.178
це означає щось нудне,
щось, що вже давно відоме
00:06:42.178 --> 00:06:46.730
багато людей його вже проаналізували,
і ми не очікуємо жодних змін.
00:06:46.730 --> 00:06:49.971
У сфері симетричних ключів, як уже казав Ден,
00:06:50.890 --> 00:06:53.449
квантові комп’ютери на них не впливають
00:06:53.449 --> 00:06:56.508
тому якщо використовувати достатньо великі ключі
00:06:56.508 --> 00:07:01.474
256-бітові ключі,
то AES або Salsa20 є достатніми.
00:07:01.474 --> 00:07:07.148
Те саме стосується аутентифікації —
якщо ви отримали ключ, його не підробити
00:07:07.148 --> 00:07:13.139
але для шифрування і підписів
з відкритим ключем, RSA-4096
00:07:13.775 --> 00:07:18.665
і ECC NIST P-256 — їх потрібно замінити
і ми маємо альтернативи.
00:07:19.494 --> 00:07:21.994
Ось рекомендація з високим рівнем довіри:
00:07:22.640 --> 00:07:26.614
використовуйте систему МакЕліса —
назва ще з’явиться пізніше
00:07:26.614 --> 00:07:28.862
і використовуйте
сигнатури, засновані на хешах
00:07:30.587 --> 00:07:34.607
ми також представили деякі алгоритми
як «перебувають у стадії оцінювання»
00:07:34.607 --> 00:07:38.743
що означає — поки не варто їх використовувати
00:07:38.743 --> 00:07:41.172
але згодом вони можуть виявитися придатними.
00:07:41.172 --> 00:07:43.892
І для нас це нормально — ми вбили кілок у землю,
00:07:43.892 --> 00:07:45.360
ми сказали: «Ось, це безпечно»
00:07:45.337 --> 00:07:50.327
і люди повинні діяти відповідно,
і всі житимуть довго і щасливо
00:07:50.327 --> 00:07:52.271
і наш виступ на цьому завершено.
00:07:52.271 --> 00:07:54.876
...чи всі дійсно
житимуть довго і щасливо?
00:07:54.876 --> 00:07:55.973
до кінця свого життя?
00:07:55.973 --> 00:07:57.900
Давайте подивимось,
що сталося насправді після цього
00:07:57.900 --> 00:08:02.292
Організація… ну,
речі, які мали бути оприлюднені
00:08:02.292 --> 00:08:04.991
насправді був один експеримент,
який Google проводив.
00:08:04.991 --> 00:08:09.666
у 2016 році Google Chrome
додав постквантовий варіант
00:08:09.666 --> 00:08:11.440
це не означає, що кожен
00:08:11.440 --> 00:08:14.252
вебсервер підтримував його —
це був просто експеримент
00:08:14.252 --> 00:08:17.605
Google активував його лише на деяких своїх серверах і сказав:
00:08:17.605 --> 00:08:19.411
«Добре, подивимось, як це працює»,
00:08:19.411 --> 00:08:21.963
і звучали дуже натхненно у своєму блозі
00:08:21.963 --> 00:08:24.545
де вони оголосили,
що допомагають користувачам захиститися
00:08:24.545 --> 00:08:26.844
від квантових комп’ютерів —
подивимось, чи спрацює.
00:08:26.844 --> 00:08:30.191
Система, яку вони використовували,
називалася New Hope (NH).
00:08:30.191 --> 00:08:32.729
Вони шифрували не лише за допомогою NH
00:08:32.729 --> 00:08:35.235
NH є постквантовою шифрувальною системою
00:08:35.235 --> 00:08:39.562
Вони також шифрували традиційною криптографією
00:08:39.562 --> 00:08:41.600
— еліптичними кривими ECC.
00:08:41.600 --> 00:08:44.679
Як уже згадувала Таня —
NIST P-256 — приклад ECC
00:08:44.679 --> 00:08:49.116
іншим прикладом ECC є x25519 —
ви, ймовірно, використовуєте це сьогодні
00:08:49.116 --> 00:08:51.453
щоб шифрувати свої дані.
І ось що зробив Google:
00:08:51.453 --> 00:08:55.241
Він шифрував NH для
постквантового захисту
00:08:55.241 --> 00:08:58.855
і одночасно шифрував
x25519, як вони роблять
00:08:58.855 --> 00:09:02.254
зазвичай і сьогодні —
ідея була в тому, що якщо щось
00:09:02.254 --> 00:09:07.829
піде не так із NH,
то ми все одно маємо звичайний захист.
00:09:07.829 --> 00:09:09.773
Тобто, щонайменше,
немає негайної загрози
00:09:09.773 --> 00:09:11.653
безпеці — вони не погіршують ситуацію
00:09:11.848 --> 00:09:14.888
звісно, якщо NH зламано,
то й не покращують
00:09:14.888 --> 00:09:17.540
але основна ідея —
спробувати зробити краще і
00:09:17.900 --> 00:09:20.450
в той же час переконатися,
що не стане гірше — шифруючи обома:
00:09:20.450 --> 00:09:22.977
традиційним і постквантовим методом
00:09:22.977 --> 00:09:28.321
План «Б» дуже важливий,
бо NH — нова шифрувальна система,
00:09:28.496 --> 00:09:32.436
тобто у 2016 вона була новою.
Ключові елементи NH були створені
00:09:32.596 --> 00:09:37.676
у 2010, 2014 і 2015 роках —
а це не так багато часу для перевірки
00:09:37.836 --> 00:09:43.216
в криптографії іноді минають роки,
поки знаходять вразливості
00:09:43.271 --> 00:09:47.591
тому дуже важливо, щоб новим шифрувальним системам дали час дозріти.
00:09:47.914 --> 00:09:51.940
Інша проблема з новими шифрувальними системами
00:09:51.940 --> 00:09:55.487
— їх можуть запатентувати.
Патенти діють 20 років, і це сталося
00:09:55.487 --> 00:10:01.164
з NH. Власник патенту звернувся
до Google і сказав: «Я хочу гроші за ваше
00:10:01.164 --> 00:10:05.164
використання NH». Google
ніколи публічно не коментував цю
00:10:05.164 --> 00:10:08.123
патентну загрозу, але з якихось причин
00:10:08.123 --> 00:10:11.643
у листопаді 2016 року вони прибрали NH
00:10:11.643 --> 00:10:16.233
з Chrome і своїх серверів.
У 2016 році також сталися інші події:
00:10:16.590 --> 00:10:22.550
в уряді США є установа — NIST,
яка має довгу історію співпраці
00:10:22.692 --> 00:10:29.246
з Агентством нацбезпеки США (NSA).
NIST оголосив, що наприкінці 2017 року
00:10:30.260 --> 00:10:33.546
вони хочуть, щоб криптографи подали
пропозиції
00:10:33.546 --> 00:10:37.910
щодо постквантових алгоритмів —
для шифрування й підпису,
00:10:37.910 --> 00:10:46.750
які згодом можна було б стандартизувати.
Цікавий момент з їхньої заявки:
00:10:46.290 --> 00:10:50.790
не дозволено надсилати гібриди — тобто
системи, які шифрують і
00:10:50.790 --> 00:10:55.453
за допомогою постквантових алгоритмів, і ECC,
або підписують чимось, що ви вже використовуєте, разом із
00:10:55.453 --> 00:10:59.334
постквантовим рішенням.
Вони сказали, що алгоритми не повинні
00:10:59.541 --> 00:11:01.854
включати ECC чи будь-який інший алгоритм,
00:11:01.854 --> 00:11:03.688
який може бути зламаний квантовими комп’ютерами.
00:11:03.688 --> 00:11:07.467
З точки зору розробника додатків,
зручно мати ECC-шар окремо
00:11:07.529 --> 00:11:10.749
і сказати: що б ви не робили
з постквантовим алгоритмом,
00:11:10.749 --> 00:11:16.120
все одно поєднуєте його з x25519, наприклад.
Але вони не сказали, що треба
00:11:16.120 --> 00:11:20.928
поєднувати все з ECC — наприклад,
x25519 як окремий шар. Вони сказали:
00:11:20.928 --> 00:11:23.991
не подавайте нічого,
що поєднується з ECC
00:11:27.907 --> 00:11:33.917
Провівши цей конкурс на постквантові системи,
NIST надіслав сигнал компаніям:
00:11:33.917 --> 00:11:36.457
почекайте, не впроваджуйте
постквантову криптографію поки що
00:11:36.457 --> 00:11:43.233
і тут був і батіг, і пряник.
Батіг — це патенти: Google щойно
00:11:43.233 --> 00:11:47.950
втрапив у халепу через використання
чогось, на що раптом знайшовся патент
00:11:47.136 --> 00:11:50.515
що ще може бути запатентоване?
А NIST сказав: у нас є процес,
00:11:50.515 --> 00:11:54.186
який веде до криптографічних стандартів,
які можна реалізовувати вільно,
00:11:54.186 --> 00:11:57.043
тобто патенти не завадять вам це використовувати.
00:11:57.043 --> 00:11:59.123
І вони також сказали, що виберуть щось,
00:11:59.123 --> 00:12:04.939
що буде досить надійним —
безпека буде головним критерієм у відборі.
00:12:05.561 --> 00:12:10.481
І отже, галузь сказала: «Добре,
чекаємо від NIST рішення», а інші
00:12:10.636 --> 00:12:16.166
органи стандартизації — також.
У IETF є свій дослідницький підрозділ,
00:12:16.312 --> 00:12:21.632
IRTF, який створює стандарти для Інтернету.
І криптографічна група в IRTF сказала:
00:12:21.700 --> 00:12:28.744
ми стандартизуємо те, що вже є в роботі,
наприклад, геш-функції,
00:12:28.744 --> 00:12:34.898
але для всього іншого —
чекаємо NIST. ISO теж сказала, що чекає
00:12:34.898 --> 00:12:40.833
NIST. Не всі організації сказали це —
наприклад, уряд Китаю
00:12:40.833 --> 00:12:45.565
заявив, що проведе свій власний конкурс.
Але, ну… кого це цікавить?
00:12:46.205 --> 00:12:53.195
Тож повертаємося до конкурсу NIST:
ось усі заявки. Наприкінці 2017 року
00:12:53.302 --> 00:12:59.700
було 69 заявок від 260 криптографів.
Я не буду зачитувати всі імена, але це була
00:12:59.700 --> 00:13:01.738
величезна кількість роботи
для аналітиків у криптографії.
00:13:03.459 --> 00:13:08.979
Ми весело проводили час на початку 2017-го,
а ті, хто бачив нас на сцені у 2018-му,
00:13:08.979 --> 00:13:12.857
знають, що ми розповідали про те,
як весело нам було зламувати ці пропозиції
00:13:12.857 --> 00:13:16.558
але це була справжня купа роботи.
Подивимось, що зробив NIST з конкурсом.
00:13:16.558 --> 00:13:21.803
У 2019-му, тобто через два роки —
ну, рік із чимось — вони почали
00:13:21.803 --> 00:13:26.153
скорочувати кількість кандидатів
до 26. А в липні 2020-го
00:13:26.153 --> 00:13:32.576
їх ще скоротили — до 15.
Мета була зосередитись на тому,
00:13:32.576 --> 00:13:39.850
що має сенс, і пріоритет давали
найбезпечнішим кандидатам, за винятком
00:13:39.850 --> 00:13:42.469
випадків, де застосування вимагало
більшої ефективності
00:13:43.254 --> 00:13:48.924
Насправді ні — вони зовсім так не робили.
Якщо почитати звіт і подивитись,
00:13:48.924 --> 00:13:51.623
яких кандидатів вони обрали —
щоразу, коли був вибір
00:13:51.623 --> 00:13:54.966
між швидкістю і безпекою,
звісно, вони відсікали
00:13:54.966 --> 00:13:59.683
алгоритми, які були повністю зламані,
і ті, що були дуже неефективні
00:13:59.683 --> 00:14:04.105
але от вам приклад — SPHINCS,
який згадувала Таня раніше,
00:14:04.414 --> 00:14:08.724
дуже обережний, усі погоджуються, що це — найбезпечніша система підпису
00:14:09.588 --> 00:14:19.317
Але NIST не сказав: «Використовуйте SPHINCS»,
00:14:19.317 --> 00:14:21.858
а: «Ми зачекаємо стандартизації SPHINCS+,
00:14:21.858 --> 00:14:27.194
хіба що стільки всього виявиться зламаним,
що доведеться взяти SPHINCS+»
00:14:27.566 --> 00:14:36.526
І от у липні цього року NIST
оголосив, що обирає чотири стандарти
00:14:36.526 --> 00:14:41.357
один із них — SPHINCS+, а ще чотири
кандидати залишаються під розглядом
00:14:41.559 --> 00:14:45.500
виглядає так, ніби впевненість трохи похитнулась.
00:14:45.500 --> 00:14:47.570
Тож що ж сталося?
00:14:47.570 --> 00:14:55.102
Картинка з 69 заявками змінилася,
якщо перемотати час на 5,5 років вперед
00:14:55.962 --> 00:14:57.276
Ось кольорове кодування:
00:14:57.276 --> 00:15:00.953
сині — це ті, що залишаються в конкурсі NIST,
00:15:00.953 --> 00:15:04.082
тобто чотири алгоритми, які
мають стати стандартами,
00:15:04.082 --> 00:15:06.474
і ще чотири кандидати четвертого раунду.
00:15:07.257 --> 00:15:12.764
Сірі не пройшли далі —
це не означає, що вони були зламані,
00:15:12.764 --> 00:15:17.550
але їх відсіяли настільки рано,
що ніхто вже не мав інтересу їх ламати.
00:15:18.214 --> 00:15:21.140
Коричневий означає менш захищений,
ніж було заявлено;
00:15:21.140 --> 00:15:24.525
червоний — означає справді зламаний,
а підкреслений червоний — це
00:15:24.525 --> 00:15:29.774
повністю-повністю зламаний.
00:15:29.774 --> 00:15:33.832
Як бачите, зламаних систем багато.
00:15:34.902 --> 00:15:39.532
Є також цікавий фіолетовий у
нижньому правому куті
00:15:40.502 --> 00:15:46.802
якщо пам’ятаєте уроки малювання —
фіолетовий — це суміш червоного і синього.
00:15:46.825 --> 00:15:49.095
SIKE було обраноу липні,
00:15:49.095 --> 00:15:56.384
а вже в липні і зламано —
після 5 років аналізу,
00:15:56.384 --> 00:15:59.661
його зламали за лічені секунди.
00:15:59.661 --> 00:16:02.581
Це приклад того, коли щось справді пішло не так
00:16:02.581 --> 00:16:06.760
і низка дрібних подій
похитнула впевненість
00:16:08.263 --> 00:16:13.173
тому NIST хоча б обрав SPHINCS,
але це не призвело до обрання
00:16:13.173 --> 00:16:16.415
інших обережних варіантів —
деякі з них ще «дозрівають»,
00:16:16.696 --> 00:16:21.736
але ця сфера поки що не зріла.
00:16:21.827 --> 00:16:24.994
А що відбувалося тим часом
із боку впровадження?
00:16:24.994 --> 00:16:28.226
Згадайте: було два моменти на слайдах Тані
ще з 2016 року. Вона сказала:
00:16:28.226 --> 00:16:31.894
було б добре вже впровадити щось,
щоб захистити користувачів, бо
00:16:31.894 --> 00:16:33.929
у нас є проблема з безпекою вже зараз —
зловмисники
00:16:33.929 --> 00:16:37.249
вже записують все, і ми повинні
намагатися захиститися від цього, і
00:16:37.249 --> 00:16:40.184
зробити це швидше, ніж
триває процес стандартизації.
00:16:40.184 --> 00:16:45.371
Google почав це у 2016-му,
але злякався патентної загрози.
00:16:46.333 --> 00:16:52.893
До 2019-го галузі й багато проєктів з
відкритим кодом
00:16:52.893 --> 00:16:56.950
подумали: можливо, вже час впроваджувати нові рішення.
00:16:56.950 --> 00:16:59.840
Щось пішло не так у 2016-му,
00:16:59.840 --> 00:17:04.643
але на той момент NIST уже зібрав
підтвердження від усіх учасників конкурсу
00:17:04.643 --> 00:17:07.363
і з’ясував, які пропозиції
є запатентованими. Це дало нам
00:17:07.363 --> 00:17:12.249
багато інформації, коли 260 криптографів
вказали, що саме захищено патентами
00:17:12.486 --> 00:17:18.714
І вже у 2019-му стало ще очевидніше,
що квантові комп’ютери — на горизонті.
00:17:18.714 --> 00:17:23.679
Тож приклади того, що сталося у 2019-му: OpenSSH версії 8, надихаючись TinySSH,
00:17:23.682 --> 00:17:26.842
оголосив, що додасть гібридний варіант — поєднання алгоритму
00:17:26.842 --> 00:17:33.328
на еліптичних кривих
і одного з постквантових кандидатів.
00:17:33.328 --> 00:17:37.013
Він не активований за замовчуванням,
але якщо ви додасте рядок у налаштування.
00:17:37.013 --> 00:17:40.680
І на сервері, і на клієнті —
використовуватиметься постквантове шифрування.
00:17:40.680 --> 00:17:45.759
А якщо постквантова частина буде зламана,
ви все одно маєте ECC як захист.
00:17:46.655 --> 00:17:50.547
У липні 2019 року Google і Cloudflare
запустили експеримент
00:17:50.547 --> 00:17:51.547
із постквантовим шифруванням.
00:17:51.547 --> 00:17:59.567
У ньому були дві версії:
деякі користувачі шифрували з NTRU-HRSS
00:17:59.567 --> 00:18:02.833
у поєднанні з ECC, звісно —
завжди використовуйте гібриди. Інша версія:
00:18:02.833 --> 00:18:07.576
використовувала SIKE-p і ECC.
Так, Таня сказала: «Ой».
00:18:07.729 --> 00:18:14.534
Це приклад того, наскільки важливо
поєднувати все з ECC, щоб не втратити
00:18:14.689 --> 00:18:19.790
поточний рівень безпеки —
усі ми зараз користуємось ECC.
00:18:19.790 --> 00:18:23.317
Тож використовуйте і постквантові системи, і ECC,
00:18:23.317 --> 00:18:26.207
щоб у гіршому випадку втратити лише час,
00:18:26.207 --> 00:18:28.447
а в кращому — щось виграти.
00:18:28.447 --> 00:18:34.372
Принаймні користувачі SIKE-p мають захист ECC.
00:18:34.372 --> 00:18:38.742
Також у жовтні 2019 року Google оголосив
про досягнення квантової переваги —
00:18:38.910 --> 00:18:42.443
мається на увазі, що квантовий комп’ютер
виконав задачу швидше,
00:18:42.443 --> 00:18:45.512
ніж будь-який суперкомп’ютер.
00:18:45.512 --> 00:18:49.612
Це було не щось практичне,
і мине ще багато років, перш ніж
00:18:49.612 --> 00:18:52.462
з’являться реальні задачі, які
квантові комп’ютери вирішуватимуть
00:18:52.462 --> 00:18:54.135
швидше за класичні комп’ютери.
00:18:54.135 --> 00:18:56.431
Але навіть сама назва — «квантова перевага» —
00:18:56.431 --> 00:19:01.940
вже вводить в оману, хоч і є цікавим
кроком уперед у квантових обчисленнях.
00:19:01.940 --> 00:19:05.768
Ця назва, ймовірно, привернула багато
уваги та викликала тривогу.
00:19:07.842 --> 00:19:18.172
У 2021–2022 роках OpenSSH, OpenBSD і Google
почали раптово оновлювати свої системи.
00:19:18.172 --> 00:19:27.118
OpenSSH версії 9.0 уже включає sntrup
і ECC за замовчуванням.
00:19:27.118 --> 00:19:32.733
Отже, якщо у вас встановлено OpenSSH 9
на сервері та на клієнті
00:19:32.733 --> 00:19:36.877
використовується постквантовий
алгоритм автоматично.
00:19:36.877 --> 00:19:42.276
Насправді, ще версії OpenSSH до 8.5
теж це підтримують, але тоді
00:19:42.276 --> 00:19:46.943
вам потрібно вручну його активувати,
щоб сервер і клієнт це використовували.
00:19:46.943 --> 00:19:49.681
А в OpenSSH 9 це вже увімкнено за замовчуванням.
00:19:49.681 --> 00:19:51.481
Так само і в Google:
00:19:51.481 --> 00:19:56.110
з листопада, тобто з минулого місяця,
вони шифрують свою внутрішню
00:19:56.110 --> 00:20:03.506
комунікацію за допомогою ntruhrss і ECC.
Тож сподіваємось, ntruhrss працює і
00:20:03.506 --> 00:20:07.272
буде безпечним проти квантових
комп’ютерів у майбутньому.
00:20:07.272 --> 00:20:12.362
Це також добре відповідає ідеї
так званого "cleansing code" — чистого коду.
00:20:12.362 --> 00:20:16.629
Як уже згадувалося, чистий код
ще не стандартизований у криптографії,
00:20:16.629 --> 00:20:22.250
але він заохочує дослідження
і адаптацію користувачів.
00:20:22.250 --> 00:20:27.963
Наприклад, американський банківський стандарт
US ANSI NTX9 заявив, що
00:20:27.963 --> 00:20:31.957
у майбутньому вони перейдуть
на постквантові стандарти.
00:20:32.360 --> 00:20:35.426
Тобто вони очікують на спільне використання
класичної криптографії
00:20:35.426 --> 00:20:38.997
яку ще називають передквантовою —
і постквантової одночасно.
00:20:38.997 --> 00:20:48.908
Одна — стандартизована і перевірена,
інша — ще нова і трохи незручна, але
00:20:48.908 --> 00:20:52.030
нам вона потрібна для довготривалої безпеки.
00:20:52.030 --> 00:20:53.690
І, можливо, в довгій перспективі
00:20:53.690 --> 00:20:57.379
нам справді потрібна буде ця
гібридна комбінація.
00:20:57.379 --> 00:20:59.989
Далі — зі США до Франції:
00:20:59.989 --> 00:21:06.030
від ANSI до ANSSI —
французьке агентство з кібербезпеки.
00:21:06.030 --> 00:21:09.055
Вони теж кажуть: не використовуйте постквантові
00:21:09.055 --> 00:21:14.315
алгоритми окремо, бо вони ще не дозріли.
00:21:14.315 --> 00:21:18.755
Але ця незрілість — не привід
відкладати перші кроки впровадження.
00:21:19.000 --> 00:21:29.562
ANSSI заохочує впроваджувати гібриди —
поєднуючи надійний класичний метод
00:21:29.562 --> 00:21:32.146
із постквантовим алгоритмом.
00:21:32.906 --> 00:21:37.736
Отже, все чудово йде за планом,
який Таня описувала на слайдах у 2016 році.
00:21:37.736 --> 00:21:42.384
Стандартизація йде повільно,
але впровадження відбувається паралельно:
00:21:42.516 --> 00:21:46.996
ми почали використовувати постквантове
шифрування разом з ECC — на випадок,
00:21:46.996 --> 00:21:51.686
якщо щось піде не так —
і щоб захистити користувачів якомога раніше.
00:21:51.686 --> 00:21:58.793
Що ж сказала на це влада США?
Починаючи з 2021 року уряд США
00:21:58.923 --> 00:22:02.673
дуже чітко дав зрозуміти, чого він хоче.
Ви, мабуть, думаєте — вони хочуть,
00:22:03.170 --> 00:22:07.707
щоб ви захищались від квантових атак?
Ні-ні — вони якраз НЕ хочуть, щоб ви
00:22:07.707 --> 00:22:14.154
захищались від квантових комп’ютерів.
Ось, наприклад, цитата від NIST —
00:22:14.154 --> 00:22:18.411
голови відділу кібербезпеки
Інформаційної лабораторії,
00:22:18.411 --> 00:22:21.550
яка і запустила конкурс
на постквантові алгоритми.
00:22:21.550 --> 00:22:27.119
У липні 2021 року, невдовзі після того,
як OpenBSD і OpenSSH почали впровадження.
00:22:27.119 --> 00:22:32.409
Він сказав: не дозволяйте людям купувати
і впроваджувати нестандартизовану постквантову
00:22:32.409 --> 00:22:40.100
криптографію. І ще один приклад — NSA,
яке тісно співпрацює з NIST, заявило:
00:22:40.444 --> 00:22:45.940
не реалізовуйте й не використовуйте
нестандартизовану постквантову криптографію.
00:22:45.544 --> 00:22:48.904
І щоб, бува, хтось не проігнорував це послання,
агентство безпеки
00:22:48.904 --> 00:22:52.168
(ти думаєш, ці агентства між
собою координуються?)
00:22:52.168 --> 00:22:57.690
агентство безпеки заявило: не використовуйте
постквантові криптопродукти, доки
00:22:57.251 --> 00:23:01.471
не завершено стандартизацію, впровадження
та тестування замінювальних програм
00:23:01.494 --> 00:23:04.914
на основі затверджених алгоритмів від NIST.
00:23:06.837 --> 00:23:13.061
Оце вже звучить як тривожний дзвіночок.
00:23:13.061 --> 00:23:15.371
А ще дивно те, що вони кажуть:
00:23:15.371 --> 00:23:17.551
якщо ви вже впроваджуєте
постквантову криптографію —
00:23:17.551 --> 00:23:20.441
не використовуйте гібриди.
00:23:20.441 --> 00:23:25.642
І ти можеш подумати: я щось не так зрозумів?
Чи вони справді це сказали?
00:23:26.010 --> 00:23:30.257
Ось слайд із конференції — фото
Маркку Саарінена.
00:23:30.257 --> 00:23:31.257
Я була там і можу підтвердити:
00:23:31.257 --> 00:23:36.717
виступаючий чітко сказав: не варто
використовувати гібридні підходи.
00:23:36.717 --> 00:23:42.256
Він неодноразово повторив:
не використовуйте нічого вже зараз.
00:23:42.256 --> 00:23:47.318
Вони також не очікували затвердження
постквантових алгоритмів
00:23:47.318 --> 00:23:51.445
на основі логіки "на всяк випадок поєднуй усе".
00:23:51.445 --> 00:23:58.890
Пізніше вони опублікували нові інструкції,
де сказано: буде однозначна заміна —
00:23:58.890 --> 00:24:03.487
вимикаємо ECC і RSA,
вмикаємо постквантову криптографію.
00:24:04.130 --> 00:24:08.450
І їхній аргумент був:
у ECC можуть бути помилки реалізації,
00:24:08.450 --> 00:24:15.256
тож вимикай ECC. Погана ідея —
хіба що ти хакер, тоді це ідеально.
00:24:15.518 --> 00:24:20.320
Тепер ти, можливо, думаєш:
"Ну ми ж усе одно будемо використовувати
00:24:20.320 --> 00:24:23.250
гібриди", навіть якщо NSA каже "не треба".
00:24:23.250 --> 00:24:29.370
І ось це речення —
"не використовуйте нестандартизоване"
00:24:29.370 --> 00:24:33.266
мабуть, уже неактуальне, правда?
00:24:33.266 --> 00:24:36.536
Адже NIST оголосив у липні:
ми стандартизуємо Kyber.
00:24:36.536 --> 00:24:40.677
Тобто: використовуйте Kyber.
00:24:40.677 --> 00:24:43.827
Але ні. Насправді вони так не сказали.
00:24:43.827 --> 00:24:46.240
Подивімося в деталі.
00:24:46.240 --> 00:24:49.870
Пам’ятаєш, як Google
мав проблеми з патентами для NH?
00:24:49.870 --> 00:24:54.530
Ну так от, Kyber — це як син New Hope.
00:24:54.530 --> 00:24:58.803
І вони, здається, переплутали Star Wars
зі Star Trek:
00:24:58.803 --> 00:25:04.388
ходили чутки, що Kyber внутрішньо
називали "New Hope: The Next Generation".
00:25:04.994 --> 00:25:09.784
Пізніше знайшли кращу назву,
але по суті — Kyber дуже схожий на NH.
00:25:09.784 --> 00:25:15.280
І має ті ж проблеми з патентами.
Це єдиний алгоритм шифрування, який обрав NIST.
00:25:15.627 --> 00:25:19.327
Вони обрали SPHINCS+
і ще дві схеми підпису,
00:25:19.566 --> 00:25:23.716
і лише одну схему шифрування — Kyber.
Це єдиний варіант захисту ваших даних
00:25:23.842 --> 00:25:28.752
відповідно до стандартів NIST.
А Kyber, як і NH, перебуває
00:25:28.917 --> 00:25:33.617
у полі з мін із семи патентів.
00:25:33.801 --> 00:25:37.331
Це не означає, що всі сім — чинні.
Але це складна справа. Щоб оцінити патент,
00:25:37.331 --> 00:25:43.639
треба розуміти патентне право,
і знати, як інтерпретувати пріоритети,
00:25:43.666 --> 00:25:47.226
перекриття, розширення.
Все дуже заплутано.
00:25:47.226 --> 00:25:51.511
Один із простих способів позбутись патентів —
викупити їх і зробити публічними.
00:25:51.565 --> 00:25:57.175
І NIST у липні заявив: ми ведемо
переговори з третіми сторонами,
00:25:57.175 --> 00:26:01.130
аби підписати угоди і уникнути
потенційних патентних проблем.
00:26:01.130 --> 00:26:04.650
Чудово! Отже, можна використовувати Kyber?
00:26:04.650 --> 00:26:06.771
Але компанії кажуть:
00:26:06.771 --> 00:26:11.721
«Покажіть нам самі угоди, будь ласка».
00:26:12.154 --> 00:26:14.504
Наприклад, Скотт Флюрер із Cisco заявив:
00:26:14.627 --> 00:26:17.627
Cisco не зможе впровадити Kyber,
поки ми не побачимо текст ліцензій.
00:26:18.647 --> 00:26:26.217
А потім виявилось: NIST узагалі
нічого не підписував у липні.
00:26:26.217 --> 00:26:32.841
Але в листопаді вони нарешті сказали:
так, ми підписали дві ліцензійні угоди.
00:26:33.661 --> 00:26:35.648
І ось трохи з їхнього змісту.
00:26:35.648 --> 00:26:37.908
Ура, супер, можна використовувати Kyber
00:26:37.908 --> 00:26:42.107
Але якщо уважно прочитати,
ліцензії стосуються лише стандарту,
00:26:42.107 --> 00:26:43.527
який описав NIST.
00:26:43.527 --> 00:26:50.359
І будь-яке модифікування або використання
чогось, що не є цим стандартом, — заборонено.
00:26:50.781 --> 00:26:54.621
Тобто, Kyber не можна змінювати або
використовувати поза стандартом NIST.
00:26:54.864 --> 00:27:00.874
Можливо, ти думаєш: ну, вони ж уже обрали Kyber,
вони ж його стандартизували в липні?
00:27:00.874 --> 00:27:06.192
Ні. Насправді в липні
вони лише заявили про наміри.
00:27:06.192 --> 00:27:12.035
Вони планують стандартизувати Kyber —
а це не те саме, що «він уже стандартизований».
00:27:12.035 --> 00:27:18.421
Планується, що стандартизацію Kyber
завершать у 2024 році.
00:27:18.631 --> 00:27:24.571
І проблема в тому, що ми досі не знаємо,
яким саме буде фінальний Kyber у 2024.
00:27:24.571 --> 00:27:32.629
Бо досі пропонують зміни.
Тобто навіть якщо вийде стандарт у 2024
00:27:32.814 --> 00:27:38.465
і якщо ліцензія дозволяє використовувати Kyber,
00:27:38.465 --> 00:27:42.985
то, можливо, у 2023 вони
вже визначили Kyber,
00:27:43.386 --> 00:27:47.895
І можливо інші 5 сімей патернів
не зачеплять Kyber.
00:27:48.640 --> 00:27:52.994
Буває, що люди проходять мінне
поле — і не вибухають.
00:27:53.995 --> 00:27:57.285
Отже, ми дійшли до кінця доповіді.
00:27:57.285 --> 00:28:00.525
Ми вже достатньо розповіли про
затримки та обхідні шляхи.
00:28:00.525 --> 00:28:01.970
А тепер — що ми мали на увазі під словом «катастрофа»?
00:28:01.970 --> 00:28:05.269
Звісно, якщо зламається те, що
00:28:05.269 --> 00:28:10.442
було використано у тестах Google
або Cloudflare, це — катастрофа.
00:28:10.442 --> 00:28:13.569
Але вони використовували резервний варіант —
використовували гібриди.
00:28:13.569 --> 00:28:15.247
Тому це ще нормально.
00:28:15.247 --> 00:28:19.170
Справжня катастрофа — це те,
що ми у 2022 році, а у нас
00:28:19.170 --> 00:28:24.770
досі нема постквантової криптографії
на телефонах чи комп’ютерах.
00:28:24.770 --> 00:28:28.374
Ми можемо вказати на
приклади впровадження,
00:28:28.374 --> 00:28:30.594
але загалом — це не масово.
00:28:30.594 --> 00:28:34.216
Твої дані все ще зашифровані
алгоритмами,
00:28:34.216 --> 00:28:37.430
що можна зламати квантовим комп’ютером.
00:28:37.430 --> 00:28:38.923
І це — справжня катастрофа.
00:28:38.923 --> 00:28:42.761
Дякуємо за увагу!
00:28:45.844 --> 00:28:47.114
Дякую, дякую!
00:28:47.114 --> 00:28:53.395
Нерозбірливо
00:28:53.395 --> 00:28:57.444
...або технології, які я використовую
у фоновому режимі,
00:28:57.444 --> 00:28:58.444
можливо, вже постквантові.
00:28:58.444 --> 00:29:01.750
Я думаю, що моє SSH-з'єднання
вже використовує щось таке,
00:29:01.750 --> 00:29:02.750
тож, можливо, все не так погано.
00:29:02.750 --> 00:29:05.868
Ми завжди можемо покладатися
на OpenBSD.
00:29:06.593 --> 00:29:07.833
Однозначно
00:29:10.769 --> 00:29:15.182
Подивимось, чи є запитання.
00:29:15.182 --> 00:29:21.182
Ось одне: я розробник, створюю додаток.
00:29:21.182 --> 00:29:22.958
не обов'язково криптографічний —
00:29:22.958 --> 00:29:26.936
як мені впевнитись, що алгоритм стійкий
у постквантову еру?
00:29:26.936 --> 00:29:28.652
Чи можу я вже зараз використовувати
гібридний підхід,
00:29:28.652 --> 00:29:31.947
щоб захистити своїх користувачів?
00:29:32.293 --> 00:29:35.753
О! У нас є слайд саме для цього!
Покажи слайд!
00:29:36.154 --> 00:29:39.494
Ми передбачили це питання.
00:29:39.494 --> 00:29:41.964
Так, це все виглядає депресивно —
але ось що робити:
00:29:41.964 --> 00:29:45.954
Ми маємо слайд з практичними діями,
які ти можеш зробити вже зараз.
00:29:45.954 --> 00:29:53.748
І наша порада: використовуй гібриди.
Мені здається, я вже казала це у 2016-му.
00:29:53.748 --> 00:29:57.720
Я тоді казала: «Ось, дивись, що ти можеш зробити
вже зараз, ось наші пропозиції».
00:29:57.721 --> 00:30:02.241
Ми вважаємо ці варіанти дуже безпечними.
І ось я знову тут — у грудні 2022-го.
00:30:02.241 --> 00:30:07.958
і я кажу: McEliece — це дуже обережна система.
І вона не має тих патентних проблем, які має Kyber.
00:30:08.665 --> 00:30:13.595
Що ж таке гібрид?
00:30:13.595 --> 00:30:17.305
Це комбінація передквантової та
постквантової криптографії.
00:30:17.305 --> 00:30:21.232
У шифруванні обидва мають брати
участь у генерації ключа.
00:30:21.970 --> 00:30:26.590
У цифровому підписі —
обидва підписи мають бути чинними окремо.
00:30:26.590 --> 00:30:30.259
Тільки тоді гібридний підпис — справжній підпис.
00:30:32.764 --> 00:30:39.684
Є багато бібліотек, які можна подивитись,
щоб отримати уявлення про різні системи.
00:30:39.684 --> 00:30:45.306
Ти можеш спробувати реалізувати їх.
Якість бібліотек зараз вже набагато краща,
00:30:45.306 --> 00:30:50.890
ніж кілька років тому.
Постквантові реалізації стають зрілими.
00:30:50.890 --> 00:30:55.844
Люди вкладають багато зусиль
у їх вдосконалення. Але ризики залишаються.
00:30:55.844 --> 00:31:01.738
Проте ризик нічого не робити —
набагато більший.
00:31:01.738 --> 00:31:03.887
Бо якщо ти нічого не зробиш,
твоя інформація залишиться вразливою
00:31:03.887 --> 00:31:05.914
для майбутніх атак
з боку квантових комп’ютерів, які вже
00:31:05.914 --> 00:31:08.731
сьогодні записують ці дані.
Тож краще експериментуй.
00:31:08.731 --> 00:31:13.104
Ось приклад бібліотеки,
яка реалізує кілька різних алгоритмів
00:31:13.104 --> 00:31:15.805
називається Quantum Safe OQS.
00:31:15.805 --> 00:31:19.314
Є й інші бібліотеки, які працюють
із певними криптосистемами.
00:31:19.314 --> 00:31:26.352
Тож у більшості розробників є якийсь застосунок,
але знову ж таки: потрібно оцінювати якість.
00:31:26.352 --> 00:31:31.798
Нова бібліотека, яка з’являється — lib.js.
00:31:31.798 --> 00:31:35.822
У неї вже є кілька перевірок, і я би
сказав, що вона надійна.
00:31:35.822 --> 00:31:42.109
Але, на жаль, єдиний постквантовий
алгоритм у ній — це Kyber.
00:31:42.532 --> 00:31:47.272
І якщо ви плануєте на 2024 — добре.
Але на зараз — це ще не варіант.
00:31:47.272 --> 00:31:48.874
Він ще не підходить для повноцінного використання прямо зараз.
00:31:48.874 --> 00:31:56.830
Якщо хочете щось швидке — подивіться,
00:31:56.830 --> 00:32:00.900
що використовують OpenSSH чи
Google з NTRU-HRSS.
00:32:00.900 --> 00:32:03.790
Ця система хоча б частково протестована.
00:32:03.790 --> 00:32:08.336
Можна спробувати. Але завжди —
використовуйте гібриди з ECC.
00:32:08.338 --> 00:32:13.448
На всяк випадок —якщо постквантовий
компонент раптом зламається.
00:32:14.120 --> 00:32:18.621
Але ж складно створити власну
систему об’єднання?
00:32:18.621 --> 00:32:21.551
Має бути правильний спосіб поєднання.
00:32:21.551 --> 00:32:24.851
Мені ж потрібно якось об’єднати класичний
і постквантовий метод.
00:32:25.295 --> 00:32:28.590
Так, це можливо.
00:32:28.590 --> 00:32:32.860
Іноді достатньо просто: підписати
першим алгоритмом,
00:32:32.860 --> 00:32:34.824
підписати другим,
а потім перевірити обидва підписи.
00:32:35.314 --> 00:32:42.884
Але ми бачили приклади, де все пішло не так.
Треба бути дуже обережними.
00:32:43.375 --> 00:32:48.873
Для шифрування зазвичай використовують
ECC для обміну ключем,
00:32:48.873 --> 00:32:52.405
а потім постквантову систему для другого обміну.
00:32:52.405 --> 00:32:57.350
І далі об’єднуєш два ключі
через улюблену хеш-функцію.
00:32:57.217 --> 00:32:59.670
Стандартна криптографічна хеш-функція —
це завжди добре.
00:32:59.670 --> 00:33:01.960
Але ти казав про поєднання —
00:33:01.960 --> 00:33:04.833
є чимало досліджень на цю тему...
00:33:06.936 --> 00:33:10.916
Йдеться про криптографічну хеш-функцію.
Не використовуй просто якусь xx hash-функцію.
00:33:10.916 --> 00:33:13.699
Використовуй ту, яка справді є криптографічною.
00:33:13.699 --> 00:33:20.316
Наприклад, SHA-512 —
так, її створили в NSA, але
00:33:20.316 --> 00:33:23.700
вона витримала безліч спроб зламати її
і все ще тримається.
00:33:23.700 --> 00:33:28.633
Є ще SHA-3, який теж пройшов
публічне оцінювання.
00:33:28.633 --> 00:33:35.580
І в більшості випадків немає проблем з тим,
щоб взяти два 32-байтові рядки, з’єднати їх
00:33:35.580 --> 00:33:40.345
та пропустити через хеш-функцію.
І це буде ваш симетричний ключ.
00:33:42.526 --> 00:33:45.960
Є навіть пропозиції,
як саме це правильно зробити.
00:33:45.980 --> 00:33:50.188
Наприклад, IRTF або точніше — CFRG RFC.
А також деякі рекомендації від NIST.
00:33:50.278 --> 00:33:54.658
Щодо використання гібридів
у стандартних сценаріях.
00:33:54.658 --> 00:34:00.360
І трохи самореклами —
у нас є слайд із попередніми дослідженнями.
00:34:00.366 --> 00:34:05.646
Там ми детально описали
підходи до впровадження та об'єднання гібридів.
00:34:06.268 --> 00:34:15.518
Як робити це правильно.
Звісно, є ще етап вибору системи.
00:34:15.706 --> 00:34:22.868
Потрібно обрати свою систему.
І як бачиш — є багато ризиків у реальному світі.
00:34:22.868 --> 00:34:27.096
Можу згадати Skype як приклад для експериментів
00:34:27.096 --> 00:34:30.346
але проблема в тому, якщо хочеш
запустити продакшн.
00:34:30.346 --> 00:34:36.697
Але якщо це лише для досліджень чи хобі —
то це не страшно.
00:34:36.697 --> 00:34:37.398
Якщо ти просто граєшся з цим,
або хочеш написати статтю — все ок.
00:34:37.398 --> 00:34:41.268
але для продакшену — треба бути обережним.
00:34:41.268 --> 00:34:47.380
І от вам вибір: або як Google — спробувати
щось нове і перевірити, чи не вибухне.
00:34:47.380 --> 00:34:52.890
І нам пощастило — воно не вибухнуло.
Тож Google міг далі використовувати
00:34:52.890 --> 00:34:57.637
NH або потім NTRU разом із ECC.
Або можна піти іншим шляхом:
00:34:57.637 --> 00:35:02.013
Пріоритет безпеці.
00:35:02.013 --> 00:35:05.773
Готовність втратити трохи швидкості та пропускної здатності.
00:35:05.773 --> 00:35:10.433
Взяти найобережніші постквантові системи
і поєднати їх із ECC або RSA.
00:35:10.656 --> 00:35:15.866
Це — вибір, який доведеться зробити,
якщо ви плануєте реалізацію.
00:35:18.750 --> 00:35:26.899
То чи нормально використовувати алгоритм,
який ще бере участь у конкурсі?
00:35:26.899 --> 00:35:29.948
Який ще не стандартизований
або можливо ніколи не буде?
00:35:29.948 --> 00:35:33.636
Навіть якщо для нього ще немає
відомих атак?
00:35:34.242 --> 00:35:45.292
Коли бачиш так багато червоних міток —
починаєш думати:
00:35:45.292 --> 00:35:47.502
ми, криптографи, взагалі щось тямимо?
00:35:47.502 --> 00:35:52.533
Як може бути стільки поламаного?
Це реально ризиковано.
00:35:52.533 --> 00:36:00.725
Але факт вибору NIST не додає
дуже багато впевненості.
00:36:00.866 --> 00:36:03.526
Окей, хочеш прокоментувати?
00:36:03.730 --> 00:36:08.910
Хочу сказати, що ті системи, які відкинули
на першому етапі, ніхто більше не досліджував.
00:36:08.910 --> 00:36:15.973
Люди втратили інтерес.
Але ті, що пройшли далі — досліджувалися більше.
00:36:15.973 --> 00:36:26.669
Наприклад, NTRU Prime і HRSS-KEM
вийшли в третій раунд.
00:36:26.669 --> 00:36:29.579
Але не перемогли у «конкурсі краси»,
який влаштував NIST.
00:36:29.579 --> 00:36:32.696
Я вважаю, вони не гірші за ті,
що залишилися в фіналі.
00:36:32.762 --> 00:36:42.932
І взагалі всі тут — лякають.
Але Google і OpenSSH таки щось вибрали.
00:36:44.410 --> 00:36:48.811
Але більшість із 69 пропозицій —
вже не мають
00:36:48.811 --> 00:36:52.990
того рівня безпеки,
який вони мали п’ять років тому.
00:36:54.605 --> 00:37:02.715
Атаки стали сильнішими,
а деякі системи не мали запасу міцності.
00:37:02.715 --> 00:37:12.424
Щоб зробити обґрунтоване рішення,
треба розуміти історію кожної з них і подумати:
00:37:12.424 --> 00:37:17.344
Як довго їх досліджували?
Наскільки вони вистояли?
00:37:17.965 --> 00:37:22.665
Деякі досліджені мало,
деякі — трохи більше.
00:37:22.665 --> 00:37:28.514
Це і формує ризик.
00:37:29.865 --> 00:37:34.565
Three Bears — гарна система.
Але після другого етапу її покинули.
00:37:34.565 --> 00:37:38.665
І відтоді її майже ніхто не досліджував.
00:37:39.731 --> 00:37:44.351
Вона може бути хорошою —
але ми цього точно не знаємо.
00:37:45.820 --> 00:37:54.770
Ті, що пройшли в третій тур —
чорні та сірі на слайді — переважно ок.
00:37:56.460 --> 00:37:59.474
І, звісно, сині.
00:38:00.302 --> 00:38:05.492
Отже, вибирай ті, що сині або чорні.
Можна вважати, вони найкращі.
00:38:05.541 --> 00:38:08.910
І наостанок — швидке питання:
00:38:08.910 --> 00:38:10.984
якщо я параноїк у фользяному капелюсі
00:38:10.984 --> 00:38:13.830
що я можу зробити,
щоб захистити своє спілкування?
00:38:16.718 --> 00:38:18.878
Пропускай усе через OpenSSH.
00:38:18.878 --> 00:38:20.703
Це вже непоганий старт.
00:38:20.703 --> 00:38:23.409
Але, звісно, треба мати
00:38:23.409 --> 00:38:27.787
клієнта і сервер, які це підтримують.
00:38:27.787 --> 00:38:31.464
І хоча є деякі експериментальні реалізації —
00:38:32.143 --> 00:38:35.603
масового впровадження майже нема.
00:38:35.808 --> 00:38:40.258
VPN — ще один приклад.
Так, є постквантові VPN-рішення.
00:38:40.258 --> 00:38:43.390
У Movad є постквантова альтернатива —
00:38:43.390 --> 00:38:46.530
вони використовують McEliece, вони використовують
00:38:46.530 --> 00:38:54.230
WireGuard для VPN, і у WireGuard є
опція додавання додаткового ключа
00:38:54.230 --> 00:38:57.042
попередньо узгодженого ключа, який
Movad використовує разом із McEliece,
00:38:57.042 --> 00:39:00.662
тобто ви завантажуєте це через McEliece, щоб
забезпечити постквантовий захист у Movad
00:39:00.662 --> 00:39:06.940
Тобто це VPN, який не просто між
двома точками — зазвичай ви хочете повністю
00:39:06.940 --> 00:39:11.296
з'єднатися з сайтом, до якого підключаєтеся, і
якщо у вас наскрізний захист,
00:39:11.296 --> 00:39:14.744
це означає, що і клієнт, і сервер повинні
підтримувати постквантову криптографію
00:39:14.802 --> 00:39:19.162
а оскільки впровадження затягнулося,
то наразі вона не настільки поширена, як
00:39:19.540 --> 00:39:23.220
я очікував кілька років тому, коли
навколо неї було багато
00:39:23.420 --> 00:39:24.410
ентузіазму
00:39:24.410 --> 00:39:28.176
нерозбірливо
00:39:28.176 --> 00:39:33.879
Добре, Таня хоче, щоб я розповів про PQ Connect,
він незабаром вийде і, сподіваюся, спростить
00:39:33.879 --> 00:39:38.109
впровадження постквантової криптографії
для захисту вашого з'єднання
00:39:38.164 --> 00:39:43.440
від початку до кінця, але його ще не
випустили, тож я не можу сказати багато
00:39:44.903 --> 00:39:50.673
Я з нетерпінням чекаю PQ Connect. Думаю,
це все, дякуємо, що були з нами
00:39:50.690 --> 00:39:55.380
і ділилися своїми знаннями, оновленнями,
пов’язаними з постквантовою криптографією
00:39:56.278 --> 00:39:59.868
Велике спасибі Тані Ланге
та D.J.B!
00:40:00.412 --> 00:40:02.188
Дякуємо!
00:40:02.188 --> 00:40:12.595
[Translated by Marta-Sofiya Klakovych
(KYBS2004 course assignment at JYU.FI)]