1
00:00:00,000 --> 00:00:01,536
[Translated by Marta-Sofiya Klakovych
(KYBS2004 course assignment at JYU.FI)]
2
00:00:01,608 --> 00:00:10,438
музика
3
00:00:10,521 --> 00:00:14,714
Ласкаво просимо до цього хаотичного
року та заходу
4
00:00:14,714 --> 00:00:17,182
Я Кара і я буду вашим диктором
5
00:00:17,182 --> 00:00:20,520
Мені приємно оголосити доповідь
6
00:00:20,520 --> 00:00:21,930
Пост-квантова криптографія:
7
00:00:21,930 --> 00:00:23,390
обхідні шляхи, затримки та катастрофи,
8
00:00:23,390 --> 00:00:26,280
яку представляють Таня Ланге
та Д. Дж. Бернштейн.
9
00:00:26,280 --> 00:00:30,510
Таня Ланге — криптограф і математик,
10
00:00:30,510 --> 00:00:33,121
яка спеціалізується на пост-квантовій криптографії,
11
00:00:33,121 --> 00:00:35,621
яка замінює ту криптографію,
яку ми використовуємо сьогодні
12
00:00:35,621 --> 00:00:38,993
на варіанти, які є безпечними
проти атак квантових комп’ютерів.
13
00:00:38,993 --> 00:00:42,207
Вона є професоркою технічного
14
00:00:42,207 --> 00:00:43,207
університету Ейндговена
15
00:00:43,207 --> 00:00:46,770
і може пишатися численними
публікаціями та відзнаками.
16
00:00:46,770 --> 00:00:51,250
Вона також була координаторкою PQCrypto,
17
00:00:51,250 --> 00:00:53,130
що є загальноєвропейською ініціативою
18
00:00:53,130 --> 00:00:56,556
для впровадження пост-квантової криптографії.
19
00:00:57,153 --> 00:01:00,830
Д. Дж. Б. є професором університету
20
00:01:00,830 --> 00:01:01,830
Іллінойсу в Чикаго
21
00:01:01,830 --> 00:01:06,559
а також професором Університету Бохума.
Він працює в галузі криптографії
22
00:01:06,559 --> 00:01:09,187
і розробив шифрувальні системи, які використовуються
23
00:01:09,187 --> 00:01:11,833
у криптографії з відкритим кодом,
можливо, ви зараз
24
00:01:11,833 --> 00:01:13,812
використовуєте одну з них,
дивлячись цю доповідь.
25
00:01:13,812 --> 00:01:18,353
Разом вони реалізували вражаючу
кількість проєктів
26
00:01:18,353 --> 00:01:22,594
від спрощення впровадження
безпечної криптографії
27
00:01:22,594 --> 00:01:27,271
до створення безпечних
постквантових типів даних.
28
00:01:27,271 --> 00:01:30,220
Обоє є активістами, які борються
29
00:01:30,220 --> 00:01:33,145
за прозоріший процес
стандартизації криптографії.
30
00:01:34,515 --> 00:01:39,224
А тепер всі, поплескайте своїми лапками
31
00:01:39,224 --> 00:01:44,107
Давайте поаплодуємо
Тані Ланге та Д. Дж. Б.!
32
00:01:48,128 --> 00:01:51,580
Добре, дякуємо за гарне представлення,
33
00:01:51,212 --> 00:01:54,782
давайте одразу перейдемо до справи —
почнемо з HTTPS
34
00:01:54,782 --> 00:01:57,997
Коли ви заходите на сайт із HTTPS
(або захищене з’єднання)
35
00:01:57,997 --> 00:02:00,553
ви використовуєте TLS — протокол безпеки
36
00:02:00,553 --> 00:02:03,143
транспортного рівня —
щоб захистити ваше з’єднання.
37
00:02:03,143 --> 00:02:07,523
TLS використовує два типи криптографії
з кількох причин.
38
00:02:07,553 --> 00:02:10,409
По-перше, він покладається
на криптографію з відкритим ключем.
39
00:02:10,509 --> 00:02:14,406
Вона виконує дві функції:
по-перше, вона забезпечує підписи.
40
00:02:14,406 --> 00:02:18,784
Підписи з відкритим ключем —
вони гарантують, що зловмисник не зможе
41
00:02:18,784 --> 00:02:21,827
підмінити дані сервера
своїми власними
42
00:02:21,827 --> 00:02:23,873
і прикидатися сервером.
43
00:02:23,873 --> 00:02:26,264
Також TLS використовує
шифрування з відкритим ключем
44
00:02:26,264 --> 00:02:31,123
наприклад, NIST P-256 або
RSA-4096 як систему підпису
45
00:02:31,123 --> 00:02:36,318
NIST P-256 також можна використовувати
для шифрування, щоб ваші дані були захищені,
46
00:02:36,590 --> 00:02:39,800
щоб він (зловмисник) не міг їх зрозуміти.
47
00:02:39,800 --> 00:02:43,691
Через причини, пов’язані з продуктивністю,
криптографія складніша, ніж
48
00:02:43,782 --> 00:02:48,820
просто криптографія з відкритим ключем —
вона також включає симетричну криптографію
49
00:02:48,114 --> 00:02:50,704
іноді її називають
криптографією із секретним ключем.
50
00:02:50,704 --> 00:02:55,597
Коли ви збираєте все разом у TLS,
ви отримуєте три основні складові:
51
00:02:55,715 --> 00:02:57,525
це шифрування з відкритим ключем,
52
00:02:57,525 --> 00:03:00,277
яке не шифрує всі ваші дані, а натомість
53
00:03:00,277 --> 00:03:05,121
шифрує лише ключ,
щоб зловмисники не могли його зрозуміти.
54
00:03:05,124 --> 00:03:07,304
Цей ключ надсилається
безпечно і конфіденційно
55
00:03:07,304 --> 00:03:08,983
від однієї сторони до іншої,
56
00:03:08,983 --> 00:03:11,866
а підписи з відкритим ключем
використовуються, щоб переконатися,
57
00:03:11,866 --> 00:03:14,499
що зловмисник не може підмінити
інший ключ
58
00:03:14,499 --> 00:03:17,900
і в кінці цей ключ використовується
59
00:03:17,900 --> 00:03:19,506
для захисту ваших даних
із використанням симетричної криптографії
60
00:03:19,729 --> 00:03:24,269
усі інші протоколи, які ви використовуєте,
61
00:03:24,269 --> 00:03:25,474
можна було б представити
у подібних слайдах
62
00:03:25,474 --> 00:03:28,514
наприклад, SSH, але вони всі працюють
майже однаково
63
00:03:28,517 --> 00:03:30,949
я зараз підкреслю два елементи на цьому слайді
64
00:03:30,949 --> 00:03:33,735
RSA-4096 —
типова система для підпису
65
00:03:33,735 --> 00:03:36,216
і типова система шифрування —
NIST P-256.
66
00:03:36,290 --> 00:03:40,850
Тому що ці дві (системи) будуть зламані
через квантові комп’ютери.
67
00:03:40,930 --> 00:03:43,440
Без квантових комп’ютерів
жодних відомих
68
00:03:43,440 --> 00:03:44,915
загроз не існувало б, але
69
00:03:44,915 --> 00:03:46,960
якщо в атакуючого буде
великий квантовий комп’ютер
70
00:03:46,960 --> 00:03:49,165
а це, найімовірніше, станеться
71
00:03:49,165 --> 00:03:51,696
хоча це не гарантовано —
може, спроби створити квантовий комп’ютер
72
00:03:51,696 --> 00:03:53,150
зазнають невдачі з якихось причин
73
00:03:53,150 --> 00:03:55,720
але зараз виглядає так,
що квантові комп’ютери
74
00:03:55,720 --> 00:03:57,430
стають дедалі успішнішими
75
00:03:57,430 --> 00:03:59,125
і як тільки вони стануть достатньо потужними
76
00:03:59,125 --> 00:04:00,785
можливо, за десять років.
77
00:04:00,785 --> 00:04:04,890
Тоді нападники зможуть запустити
алгоритм атаки,
78
00:04:04,890 --> 00:04:07,578
який називається алгоритмом Шора,
що знаходить ваші секретні RSA-ключі і
79
00:04:07,578 --> 00:04:12,800
секретні ключі NIST P-256,
і тоді зловмисники зможуть
80
00:04:12,800 --> 00:04:14,714
отримати доступ до інформації,
яку вони вже зараз зберігають
81
00:04:14,714 --> 00:04:17,324
це загроза не лише майбутнім даним,
82
00:04:17,324 --> 00:04:21,500
але і конфіденційності ваших поточних даних
83
00:04:21,500 --> 00:04:25,900
бо зловмисники вже зараз
зберігають все, що можуть, з Інтернету
84
00:04:25,900 --> 00:04:27,416
і коли у них буде
великий квантовий комп’ютер
85
00:04:27,416 --> 00:04:33,506
вони зможуть розшифрувати все заднім числом,
бо зламають RSA-4096
86
00:04:33,506 --> 00:04:39,213
і NIST P-256,
а саме NIST P-256 забезпечує шифрування
87
00:04:39,213 --> 00:04:40,487
і вони зможуть повернутися в минуле
88
00:04:40,487 --> 00:04:42,947
і зламати шифрування, яке ви використовуєте сьогодні.
89
00:04:42,947 --> 00:04:45,688
Що ж нам із цим робити?
90
00:04:45,688 --> 00:04:48,270
Стандартний підхід — це те,
що ми називаємо
91
00:04:48,270 --> 00:04:50,562
постквантовою криптографією —
ви вже чули цю назву раніше, вона була
92
00:04:50,562 --> 00:04:53,920
в назві нашої доповіді —
це криптографія, яка створена спеціально
93
00:04:53,920 --> 00:04:57,168
з урахуванням того,
що атакуючий має квантовий комп’ютер.
94
00:04:58,915 --> 00:05:02,405
Тож, як уже казав ведучий,
95
00:05:02,405 --> 00:05:05,438
я була координаторкою проєкту PQCRYPTO
96
00:05:05,438 --> 00:05:09,950
і це означає, що я об’їздила
світ із доповідями про постквантову криптографію.
97
00:05:09,950 --> 00:05:14,470
Ось скріншот із виступу,
який я провела шість з половиною років тому
98
00:05:14,470 --> 00:05:19,852
де я підкреслювала, як сьогодні це зробив Ден,
важливість постквантової криптографії
99
00:05:20,700 --> 00:05:23,507
і наголошувала, що важливо давати рекомендації,
100
00:05:23,507 --> 00:05:26,904
які визначають, які алгоритми
варто використовувати для заміни RSA та
101
00:05:26,904 --> 00:05:31,780
NIST P-256, які
ви бачили на попередніх слайдах
102
00:05:31,275 --> 00:05:36,656
і тоді я поставила питання —
чи варто нам стандартизувати зараз чи пізніше.
103
00:05:37,120 --> 00:05:43,110
Аргументи існують з обох сторін,
і ну… якби ми стандартизували тоді,
104
00:05:43,110 --> 00:05:44,842
шість років тому, здавалося, що
105
00:05:44,842 --> 00:05:46,575
ще занадто багато роботи, і що ми отримаємо
106
00:05:46,575 --> 00:05:49,950
набагато кращу систему,
якщо трохи зачекаємо,
107
00:05:49,950 --> 00:05:57,222
але з іншого боку існує занепокоєння
через дані, які збирають уряди та інші темні сили.
108
00:05:57,256 --> 00:06:03,836
І чим пізніше це буде опубліковано, тим більше даних і безпеки буде втрачено,
109
00:06:03,836 --> 00:06:09,148
тому важливо просуватися вперед,
і тоді нашою відповіддю було таке:
110
00:06:09,148 --> 00:06:13,237
те, що я просувала у 2016 році —
це рекомендації, опубліковані у 2015 році, в яких
111
00:06:13,237 --> 00:06:17,430
йшлося про те, що
стандартизація займає багато часу
112
00:06:17,430 --> 00:06:21,180
ми ще не на тій стадії,
але якщо хтось хоче захистити себе.
113
00:06:21,180 --> 00:06:24,672
Ось що ми… ну, тобто ціла група дослідників,
114
00:06:24,672 --> 00:06:28,872
які підписали цю заяву
як частину проєкту PQCRYPTO.
115
00:06:28,872 --> 00:06:34,682
Що ми рекомендували?
Наша рекомендація була у тому, що ми назвали
116
00:06:34,682 --> 00:06:36,387
«обережною криптографією»
117
00:06:36,387 --> 00:06:38,254
і це не означає
політичний консерватизм
118
00:06:38,254 --> 00:06:42,178
це означає щось нудне,
щось, що вже давно відоме
119
00:06:42,178 --> 00:06:46,730
багато людей його вже проаналізували,
і ми не очікуємо жодних змін.
120
00:06:46,730 --> 00:06:49,971
У сфері симетричних ключів, як уже казав Ден,
121
00:06:50,890 --> 00:06:53,449
квантові комп’ютери на них не впливають
122
00:06:53,449 --> 00:06:56,508
тому якщо використовувати достатньо великі ключі
123
00:06:56,508 --> 00:07:01,474
256-бітові ключі,
то AES або Salsa20 є достатніми.
124
00:07:01,474 --> 00:07:07,148
Те саме стосується аутентифікації —
якщо ви отримали ключ, його не підробити
125
00:07:07,148 --> 00:07:13,139
але для шифрування і підписів
з відкритим ключем, RSA-4096
126
00:07:13,775 --> 00:07:18,665
і ECC NIST P-256 — їх потрібно замінити
і ми маємо альтернативи.
127
00:07:19,494 --> 00:07:21,994
Ось рекомендація з високим рівнем довіри:
128
00:07:22,640 --> 00:07:26,614
використовуйте систему МакЕліса —
назва ще з’явиться пізніше
129
00:07:26,614 --> 00:07:28,862
і використовуйте
сигнатури, засновані на хешах
130
00:07:30,587 --> 00:07:34,607
ми також представили деякі алгоритми
як «перебувають у стадії оцінювання»
131
00:07:34,607 --> 00:07:38,743
що означає — поки не варто їх використовувати
132
00:07:38,743 --> 00:07:41,172
але згодом вони можуть виявитися придатними.
133
00:07:41,172 --> 00:07:43,892
І для нас це нормально — ми вбили кілок у землю,
134
00:07:43,892 --> 00:07:45,360
ми сказали: «Ось, це безпечно»
135
00:07:45,337 --> 00:07:50,327
і люди повинні діяти відповідно,
і всі житимуть довго і щасливо
136
00:07:50,327 --> 00:07:52,271
і наш виступ на цьому завершено.
137
00:07:52,271 --> 00:07:54,876
...чи всі дійсно
житимуть довго і щасливо?
138
00:07:54,876 --> 00:07:55,973
до кінця свого життя?
139
00:07:55,973 --> 00:07:57,900
Давайте подивимось,
що сталося насправді після цього
140
00:07:57,900 --> 00:08:02,292
Організація… ну,
речі, які мали бути оприлюднені
141
00:08:02,292 --> 00:08:04,991
насправді був один експеримент,
який Google проводив.
142
00:08:04,991 --> 00:08:09,666
у 2016 році Google Chrome
додав постквантовий варіант
143
00:08:09,666 --> 00:08:11,440
це не означає, що кожен
144
00:08:11,440 --> 00:08:14,252
вебсервер підтримував його —
це був просто експеримент
145
00:08:14,252 --> 00:08:17,605
Google активував його лише на деяких своїх серверах і сказав:
146
00:08:17,605 --> 00:08:19,411
«Добре, подивимось, як це працює»,
147
00:08:19,411 --> 00:08:21,963
і звучали дуже натхненно у своєму блозі
148
00:08:21,963 --> 00:08:24,545
де вони оголосили,
що допомагають користувачам захиститися
149
00:08:24,545 --> 00:08:26,844
від квантових комп’ютерів —
подивимось, чи спрацює.
150
00:08:26,844 --> 00:08:30,191
Система, яку вони використовували,
називалася New Hope (NH).
151
00:08:30,191 --> 00:08:32,729
Вони шифрували не лише за допомогою NH
152
00:08:32,729 --> 00:08:35,235
NH є постквантовою шифрувальною системою
153
00:08:35,235 --> 00:08:39,562
Вони також шифрували традиційною криптографією
154
00:08:39,562 --> 00:08:41,600
— еліптичними кривими ECC.
155
00:08:41,600 --> 00:08:44,679
Як уже згадувала Таня —
NIST P-256 — приклад ECC
156
00:08:44,679 --> 00:08:49,116
іншим прикладом ECC є x25519 —
ви, ймовірно, використовуєте це сьогодні
157
00:08:49,116 --> 00:08:51,453
щоб шифрувати свої дані.
І ось що зробив Google:
158
00:08:51,453 --> 00:08:55,241
Він шифрував NH для
постквантового захисту
159
00:08:55,241 --> 00:08:58,855
і одночасно шифрував
x25519, як вони роблять
160
00:08:58,855 --> 00:09:02,254
зазвичай і сьогодні —
ідея була в тому, що якщо щось
161
00:09:02,254 --> 00:09:07,829
піде не так із NH,
то ми все одно маємо звичайний захист.
162
00:09:07,829 --> 00:09:09,773
Тобто, щонайменше,
немає негайної загрози
163
00:09:09,773 --> 00:09:11,653
безпеці — вони не погіршують ситуацію
164
00:09:11,848 --> 00:09:14,888
звісно, якщо NH зламано,
то й не покращують
165
00:09:14,888 --> 00:09:17,540
але основна ідея —
спробувати зробити краще і
166
00:09:17,900 --> 00:09:20,450
в той же час переконатися,
що не стане гірше — шифруючи обома:
167
00:09:20,450 --> 00:09:22,977
традиційним і постквантовим методом
168
00:09:22,977 --> 00:09:28,321
План «Б» дуже важливий,
бо NH — нова шифрувальна система,
169
00:09:28,496 --> 00:09:32,436
тобто у 2016 вона була новою.
Ключові елементи NH були створені
170
00:09:32,596 --> 00:09:37,676
у 2010, 2014 і 2015 роках —
а це не так багато часу для перевірки
171
00:09:37,836 --> 00:09:43,216
в криптографії іноді минають роки,
поки знаходять вразливості
172
00:09:43,271 --> 00:09:47,591
тому дуже важливо, щоб новим шифрувальним системам дали час дозріти.
173
00:09:47,914 --> 00:09:51,940
Інша проблема з новими шифрувальними системами
174
00:09:51,940 --> 00:09:55,487
— їх можуть запатентувати.
Патенти діють 20 років, і це сталося
175
00:09:55,487 --> 00:10:01,164
з NH. Власник патенту звернувся
до Google і сказав: «Я хочу гроші за ваше
176
00:10:01,164 --> 00:10:05,164
використання NH». Google
ніколи публічно не коментував цю
177
00:10:05,164 --> 00:10:08,123
патентну загрозу, але з якихось причин
178
00:10:08,123 --> 00:10:11,643
у листопаді 2016 року вони прибрали NH
179
00:10:11,643 --> 00:10:16,233
з Chrome і своїх серверів.
У 2016 році також сталися інші події:
180
00:10:16,590 --> 00:10:22,550
в уряді США є установа — NIST,
яка має довгу історію співпраці
181
00:10:22,692 --> 00:10:29,246
з Агентством нацбезпеки США (NSA).
NIST оголосив, що наприкінці 2017 року
182
00:10:30,260 --> 00:10:33,546
вони хочуть, щоб криптографи подали
пропозиції
183
00:10:33,546 --> 00:10:37,910
щодо постквантових алгоритмів —
для шифрування й підпису,
184
00:10:37,910 --> 00:10:46,750
які згодом можна було б стандартизувати.
Цікавий момент з їхньої заявки:
185
00:10:46,290 --> 00:10:50,790
не дозволено надсилати гібриди — тобто
системи, які шифрують і
186
00:10:50,790 --> 00:10:55,453
за допомогою постквантових алгоритмів, і ECC,
або підписують чимось, що ви вже використовуєте, разом із
187
00:10:55,453 --> 00:10:59,334
постквантовим рішенням.
Вони сказали, що алгоритми не повинні
188
00:10:59,541 --> 00:11:01,854
включати ECC чи будь-який інший алгоритм,
189
00:11:01,854 --> 00:11:03,688
який може бути зламаний квантовими комп’ютерами.
190
00:11:03,688 --> 00:11:07,467
З точки зору розробника додатків,
зручно мати ECC-шар окремо
191
00:11:07,529 --> 00:11:10,749
і сказати: що б ви не робили
з постквантовим алгоритмом,
192
00:11:10,749 --> 00:11:16,120
все одно поєднуєте його з x25519, наприклад.
Але вони не сказали, що треба
193
00:11:16,120 --> 00:11:20,928
поєднувати все з ECC — наприклад,
x25519 як окремий шар. Вони сказали:
194
00:11:20,928 --> 00:11:23,991
не подавайте нічого,
що поєднується з ECC
195
00:11:27,907 --> 00:11:33,917
Провівши цей конкурс на постквантові системи,
NIST надіслав сигнал компаніям:
196
00:11:33,917 --> 00:11:36,457
почекайте, не впроваджуйте
постквантову криптографію поки що
197
00:11:36,457 --> 00:11:43,233
і тут був і батіг, і пряник.
Батіг — це патенти: Google щойно
198
00:11:43,233 --> 00:11:47,950
втрапив у халепу через використання
чогось, на що раптом знайшовся патент
199
00:11:47,136 --> 00:11:50,515
що ще може бути запатентоване?
А NIST сказав: у нас є процес,
200
00:11:50,515 --> 00:11:54,186
який веде до криптографічних стандартів,
які можна реалізовувати вільно,
201
00:11:54,186 --> 00:11:57,043
тобто патенти не завадять вам це використовувати.
202
00:11:57,043 --> 00:11:59,123
І вони також сказали, що виберуть щось,
203
00:11:59,123 --> 00:12:04,939
що буде досить надійним —
безпека буде головним критерієм у відборі.
204
00:12:05,561 --> 00:12:10,481
І отже, галузь сказала: «Добре,
чекаємо від NIST рішення», а інші
205
00:12:10,636 --> 00:12:16,166
органи стандартизації — також.
У IETF є свій дослідницький підрозділ,
206
00:12:16,312 --> 00:12:21,632
IRTF, який створює стандарти для Інтернету.
І криптографічна група в IRTF сказала:
207
00:12:21,700 --> 00:12:28,744
ми стандартизуємо те, що вже є в роботі,
наприклад, геш-функції,
208
00:12:28,744 --> 00:12:34,898
але для всього іншого —
чекаємо NIST. ISO теж сказала, що чекає
209
00:12:34,898 --> 00:12:40,833
NIST. Не всі організації сказали це —
наприклад, уряд Китаю
210
00:12:40,833 --> 00:12:45,565
заявив, що проведе свій власний конкурс.
Але, ну… кого це цікавить?
211
00:12:46,205 --> 00:12:53,195
Тож повертаємося до конкурсу NIST:
ось усі заявки. Наприкінці 2017 року
212
00:12:53,302 --> 00:12:59,700
було 69 заявок від 260 криптографів.
Я не буду зачитувати всі імена, але це була
213
00:12:59,700 --> 00:13:01,738
величезна кількість роботи
для аналітиків у криптографії.
214
00:13:03,459 --> 00:13:08,979
Ми весело проводили час на початку 2017-го,
а ті, хто бачив нас на сцені у 2018-му,
215
00:13:08,979 --> 00:13:12,857
знають, що ми розповідали про те,
як весело нам було зламувати ці пропозиції
216
00:13:12,857 --> 00:13:16,558
але це була справжня купа роботи.
Подивимось, що зробив NIST з конкурсом.
217
00:13:16,558 --> 00:13:21,803
У 2019-му, тобто через два роки —
ну, рік із чимось — вони почали
218
00:13:21,803 --> 00:13:26,153
скорочувати кількість кандидатів
до 26. А в липні 2020-го
219
00:13:26,153 --> 00:13:32,576
їх ще скоротили — до 15.
Мета була зосередитись на тому,
220
00:13:32,576 --> 00:13:39,850
що має сенс, і пріоритет давали
найбезпечнішим кандидатам, за винятком
221
00:13:39,850 --> 00:13:42,469
випадків, де застосування вимагало
більшої ефективності
222
00:13:43,254 --> 00:13:48,924
Насправді ні — вони зовсім так не робили.
Якщо почитати звіт і подивитись,
223
00:13:48,924 --> 00:13:51,623
яких кандидатів вони обрали —
щоразу, коли був вибір
224
00:13:51,623 --> 00:13:54,966
між швидкістю і безпекою,
звісно, вони відсікали
225
00:13:54,966 --> 00:13:59,683
алгоритми, які були повністю зламані,
і ті, що були дуже неефективні
226
00:13:59,683 --> 00:14:04,105
але от вам приклад — SPHINCS,
який згадувала Таня раніше,
227
00:14:04,414 --> 00:14:08,724
дуже обережний, усі погоджуються, що це — найбезпечніша система підпису
228
00:14:09,588 --> 00:14:19,317
Але NIST не сказав: «Використовуйте SPHINCS»,
229
00:14:19,317 --> 00:14:21,858
а: «Ми зачекаємо стандартизації SPHINCS+,
230
00:14:21,858 --> 00:14:27,194
хіба що стільки всього виявиться зламаним,
що доведеться взяти SPHINCS+»
231
00:14:27,566 --> 00:14:36,526
І от у липні цього року NIST
оголосив, що обирає чотири стандарти
232
00:14:36,526 --> 00:14:41,357
один із них — SPHINCS+, а ще чотири
кандидати залишаються під розглядом
233
00:14:41,559 --> 00:14:45,500
виглядає так, ніби впевненість трохи похитнулась.
234
00:14:45,500 --> 00:14:47,570
Тож що ж сталося?
235
00:14:47,570 --> 00:14:55,102
Картинка з 69 заявками змінилася,
якщо перемотати час на 5,5 років вперед
236
00:14:55,962 --> 00:14:57,276
Ось кольорове кодування:
237
00:14:57,276 --> 00:15:00,953
сині — це ті, що залишаються в конкурсі NIST,
238
00:15:00,953 --> 00:15:04,082
тобто чотири алгоритми, які
мають стати стандартами,
239
00:15:04,082 --> 00:15:06,474
і ще чотири кандидати четвертого раунду.
240
00:15:07,257 --> 00:15:12,764
Сірі не пройшли далі —
це не означає, що вони були зламані,
241
00:15:12,764 --> 00:15:17,550
але їх відсіяли настільки рано,
що ніхто вже не мав інтересу їх ламати.
242
00:15:18,214 --> 00:15:21,140
Коричневий означає менш захищений,
ніж було заявлено;
243
00:15:21,140 --> 00:15:24,525
червоний — означає справді зламаний,
а підкреслений червоний — це
244
00:15:24,525 --> 00:15:29,774
повністю-повністю зламаний.
245
00:15:29,774 --> 00:15:33,832
Як бачите, зламаних систем багато.
246
00:15:34,902 --> 00:15:39,532
Є також цікавий фіолетовий у
нижньому правому куті
247
00:15:40,502 --> 00:15:46,802
якщо пам’ятаєте уроки малювання —
фіолетовий — це суміш червоного і синього.
248
00:15:46,825 --> 00:15:49,095
SIKE було обраноу липні,
249
00:15:49,095 --> 00:15:56,384
а вже в липні і зламано —
після 5 років аналізу,
250
00:15:56,384 --> 00:15:59,661
його зламали за лічені секунди.
251
00:15:59,661 --> 00:16:02,581
Це приклад того, коли щось справді пішло не так
252
00:16:02,581 --> 00:16:06,760
і низка дрібних подій
похитнула впевненість
253
00:16:08,263 --> 00:16:13,173
тому NIST хоча б обрав SPHINCS,
але це не призвело до обрання
254
00:16:13,173 --> 00:16:16,415
інших обережних варіантів —
деякі з них ще «дозрівають»,
255
00:16:16,696 --> 00:16:21,736
але ця сфера поки що не зріла.
256
00:16:21,827 --> 00:16:24,994
А що відбувалося тим часом
із боку впровадження?
257
00:16:24,994 --> 00:16:28,226
Згадайте: було два моменти на слайдах Тані
ще з 2016 року. Вона сказала:
258
00:16:28,226 --> 00:16:31,894
було б добре вже впровадити щось,
щоб захистити користувачів, бо
259
00:16:31,894 --> 00:16:33,929
у нас є проблема з безпекою вже зараз —
зловмисники
260
00:16:33,929 --> 00:16:37,249
вже записують все, і ми повинні
намагатися захиститися від цього, і
261
00:16:37,249 --> 00:16:40,184
зробити це швидше, ніж
триває процес стандартизації.
262
00:16:40,184 --> 00:16:45,371
Google почав це у 2016-му,
але злякався патентної загрози.
263
00:16:46,333 --> 00:16:52,893
До 2019-го галузі й багато проєктів з
відкритим кодом
264
00:16:52,893 --> 00:16:56,950
подумали: можливо, вже час впроваджувати нові рішення.
265
00:16:56,950 --> 00:16:59,840
Щось пішло не так у 2016-му,
266
00:16:59,840 --> 00:17:04,643
але на той момент NIST уже зібрав
підтвердження від усіх учасників конкурсу
267
00:17:04,643 --> 00:17:07,363
і з’ясував, які пропозиції
є запатентованими. Це дало нам
268
00:17:07,363 --> 00:17:12,249
багато інформації, коли 260 криптографів
вказали, що саме захищено патентами
269
00:17:12,486 --> 00:17:18,714
І вже у 2019-му стало ще очевидніше,
що квантові комп’ютери — на горизонті.
270
00:17:18,714 --> 00:17:23,679
Тож приклади того, що сталося у 2019-му: OpenSSH версії 8, надихаючись TinySSH,
271
00:17:23,682 --> 00:17:26,842
оголосив, що додасть гібридний варіант — поєднання алгоритму
272
00:17:26,842 --> 00:17:33,328
на еліптичних кривих
і одного з постквантових кандидатів.
273
00:17:33,328 --> 00:17:37,013
Він не активований за замовчуванням,
але якщо ви додасте рядок у налаштування.
274
00:17:37,013 --> 00:17:40,680
І на сервері, і на клієнті —
використовуватиметься постквантове шифрування.
275
00:17:40,680 --> 00:17:45,759
А якщо постквантова частина буде зламана,
ви все одно маєте ECC як захист.
276
00:17:46,655 --> 00:17:50,547
У липні 2019 року Google і Cloudflare
запустили експеримент
277
00:17:50,547 --> 00:17:51,547
із постквантовим шифруванням.
278
00:17:51,547 --> 00:17:59,567
У ньому були дві версії:
деякі користувачі шифрували з NTRU-HRSS
279
00:17:59,567 --> 00:18:02,833
у поєднанні з ECC, звісно —
завжди використовуйте гібриди. Інша версія:
280
00:18:02,833 --> 00:18:07,576
використовувала SIKE-p і ECC.
Так, Таня сказала: «Ой».
281
00:18:07,729 --> 00:18:14,534
Це приклад того, наскільки важливо
поєднувати все з ECC, щоб не втратити
282
00:18:14,689 --> 00:18:19,790
поточний рівень безпеки —
усі ми зараз користуємось ECC.
283
00:18:19,790 --> 00:18:23,317
Тож використовуйте і постквантові системи, і ECC,
284
00:18:23,317 --> 00:18:26,207
щоб у гіршому випадку втратити лише час,
285
00:18:26,207 --> 00:18:28,447
а в кращому — щось виграти.
286
00:18:28,447 --> 00:18:34,372
Принаймні користувачі SIKE-p мають захист ECC.
287
00:18:34,372 --> 00:18:38,742
Також у жовтні 2019 року Google оголосив
про досягнення квантової переваги —
288
00:18:38,910 --> 00:18:42,443
мається на увазі, що квантовий комп’ютер
виконав задачу швидше,
289
00:18:42,443 --> 00:18:45,512
ніж будь-який суперкомп’ютер.
290
00:18:45,512 --> 00:18:49,612
Це було не щось практичне,
і мине ще багато років, перш ніж
291
00:18:49,612 --> 00:18:52,462
з’являться реальні задачі, які
квантові комп’ютери вирішуватимуть
292
00:18:52,462 --> 00:18:54,135
швидше за класичні комп’ютери.
293
00:18:54,135 --> 00:18:56,431
Але навіть сама назва — «квантова перевага» —
294
00:18:56,431 --> 00:19:01,940
вже вводить в оману, хоч і є цікавим
кроком уперед у квантових обчисленнях.
295
00:19:01,940 --> 00:19:05,768
Ця назва, ймовірно, привернула багато
уваги та викликала тривогу.
296
00:19:07,842 --> 00:19:18,172
У 2021–2022 роках OpenSSH, OpenBSD і Google
почали раптово оновлювати свої системи.
297
00:19:18,172 --> 00:19:27,118
OpenSSH версії 9.0 уже включає sntrup
і ECC за замовчуванням.
298
00:19:27,118 --> 00:19:32,733
Отже, якщо у вас встановлено OpenSSH 9
на сервері та на клієнті
299
00:19:32,733 --> 00:19:36,877
використовується постквантовий
алгоритм автоматично.
300
00:19:36,877 --> 00:19:42,276
Насправді, ще версії OpenSSH до 8.5
теж це підтримують, але тоді
301
00:19:42,276 --> 00:19:46,943
вам потрібно вручну його активувати,
щоб сервер і клієнт це використовували.
302
00:19:46,943 --> 00:19:49,681
А в OpenSSH 9 це вже увімкнено за замовчуванням.
303
00:19:49,681 --> 00:19:51,481
Так само і в Google:
304
00:19:51,481 --> 00:19:56,110
з листопада, тобто з минулого місяця,
вони шифрують свою внутрішню
305
00:19:56,110 --> 00:20:03,506
комунікацію за допомогою ntruhrss і ECC.
Тож сподіваємось, ntruhrss працює і
306
00:20:03,506 --> 00:20:07,272
буде безпечним проти квантових
комп’ютерів у майбутньому.
307
00:20:07,272 --> 00:20:12,362
Це також добре відповідає ідеї
так званого "cleansing code" — чистого коду.
308
00:20:12,362 --> 00:20:16,629
Як уже згадувалося, чистий код
ще не стандартизований у криптографії,
309
00:20:16,629 --> 00:20:22,250
але він заохочує дослідження
і адаптацію користувачів.
310
00:20:22,250 --> 00:20:27,963
Наприклад, американський банківський стандарт
US ANSI NTX9 заявив, що
311
00:20:27,963 --> 00:20:31,957
у майбутньому вони перейдуть
на постквантові стандарти.
312
00:20:32,360 --> 00:20:35,426
Тобто вони очікують на спільне використання
класичної криптографії
313
00:20:35,426 --> 00:20:38,997
яку ще називають передквантовою —
і постквантової одночасно.
314
00:20:38,997 --> 00:20:48,908
Одна — стандартизована і перевірена,
інша — ще нова і трохи незручна, але
315
00:20:48,908 --> 00:20:52,030
нам вона потрібна для довготривалої безпеки.
316
00:20:52,030 --> 00:20:53,690
І, можливо, в довгій перспективі
317
00:20:53,690 --> 00:20:57,379
нам справді потрібна буде ця
гібридна комбінація.
318
00:20:57,379 --> 00:20:59,989
Далі — зі США до Франції:
319
00:20:59,989 --> 00:21:06,030
від ANSI до ANSSI —
французьке агентство з кібербезпеки.
320
00:21:06,030 --> 00:21:09,055
Вони теж кажуть: не використовуйте постквантові
321
00:21:09,055 --> 00:21:14,315
алгоритми окремо, бо вони ще не дозріли.
322
00:21:14,315 --> 00:21:18,755
Але ця незрілість — не привід
відкладати перші кроки впровадження.
323
00:21:19,000 --> 00:21:29,562
ANSSI заохочує впроваджувати гібриди —
поєднуючи надійний класичний метод
324
00:21:29,562 --> 00:21:32,146
із постквантовим алгоритмом.
325
00:21:32,906 --> 00:21:37,736
Отже, все чудово йде за планом,
який Таня описувала на слайдах у 2016 році.
326
00:21:37,736 --> 00:21:42,384
Стандартизація йде повільно,
але впровадження відбувається паралельно:
327
00:21:42,516 --> 00:21:46,996
ми почали використовувати постквантове
шифрування разом з ECC — на випадок,
328
00:21:46,996 --> 00:21:51,686
якщо щось піде не так —
і щоб захистити користувачів якомога раніше.
329
00:21:51,686 --> 00:21:58,793
Що ж сказала на це влада США?
Починаючи з 2021 року уряд США
330
00:21:58,923 --> 00:22:02,673
дуже чітко дав зрозуміти, чого він хоче.
Ви, мабуть, думаєте — вони хочуть,
331
00:22:03,170 --> 00:22:07,707
щоб ви захищались від квантових атак?
Ні-ні — вони якраз НЕ хочуть, щоб ви
332
00:22:07,707 --> 00:22:14,154
захищались від квантових комп’ютерів.
Ось, наприклад, цитата від NIST —
333
00:22:14,154 --> 00:22:18,411
голови відділу кібербезпеки
Інформаційної лабораторії,
334
00:22:18,411 --> 00:22:21,550
яка і запустила конкурс
на постквантові алгоритми.
335
00:22:21,550 --> 00:22:27,119
У липні 2021 року, невдовзі після того,
як OpenBSD і OpenSSH почали впровадження.
336
00:22:27,119 --> 00:22:32,409
Він сказав: не дозволяйте людям купувати
і впроваджувати нестандартизовану постквантову
337
00:22:32,409 --> 00:22:40,100
криптографію. І ще один приклад — NSA,
яке тісно співпрацює з NIST, заявило:
338
00:22:40,444 --> 00:22:45,940
не реалізовуйте й не використовуйте
нестандартизовану постквантову криптографію.
339
00:22:45,544 --> 00:22:48,904
І щоб, бува, хтось не проігнорував це послання,
агентство безпеки
340
00:22:48,904 --> 00:22:52,168
(ти думаєш, ці агентства між
собою координуються?)
341
00:22:52,168 --> 00:22:57,690
агентство безпеки заявило: не використовуйте
постквантові криптопродукти, доки
342
00:22:57,251 --> 00:23:01,471
не завершено стандартизацію, впровадження
та тестування замінювальних програм
343
00:23:01,494 --> 00:23:04,914
на основі затверджених алгоритмів від NIST.
344
00:23:06,837 --> 00:23:13,061
Оце вже звучить як тривожний дзвіночок.
345
00:23:13,061 --> 00:23:15,371
А ще дивно те, що вони кажуть:
346
00:23:15,371 --> 00:23:17,551
якщо ви вже впроваджуєте
постквантову криптографію —
347
00:23:17,551 --> 00:23:20,441
не використовуйте гібриди.
348
00:23:20,441 --> 00:23:25,642
І ти можеш подумати: я щось не так зрозумів?
Чи вони справді це сказали?
349
00:23:26,010 --> 00:23:30,257
Ось слайд із конференції — фото
Маркку Саарінена.
350
00:23:30,257 --> 00:23:31,257
Я була там і можу підтвердити:
351
00:23:31,257 --> 00:23:36,717
виступаючий чітко сказав: не варто
використовувати гібридні підходи.
352
00:23:36,717 --> 00:23:42,256
Він неодноразово повторив:
не використовуйте нічого вже зараз.
353
00:23:42,256 --> 00:23:47,318
Вони також не очікували затвердження
постквантових алгоритмів
354
00:23:47,318 --> 00:23:51,445
на основі логіки "на всяк випадок поєднуй усе".
355
00:23:51,445 --> 00:23:58,890
Пізніше вони опублікували нові інструкції,
де сказано: буде однозначна заміна —
356
00:23:58,890 --> 00:24:03,487
вимикаємо ECC і RSA,
вмикаємо постквантову криптографію.
357
00:24:04,130 --> 00:24:08,450
І їхній аргумент був:
у ECC можуть бути помилки реалізації,
358
00:24:08,450 --> 00:24:15,256
тож вимикай ECC. Погана ідея —
хіба що ти хакер, тоді це ідеально.
359
00:24:15,518 --> 00:24:20,320
Тепер ти, можливо, думаєш:
"Ну ми ж усе одно будемо використовувати
360
00:24:20,320 --> 00:24:23,250
гібриди", навіть якщо NSA каже "не треба".
361
00:24:23,250 --> 00:24:29,370
І ось це речення —
"не використовуйте нестандартизоване"
362
00:24:29,370 --> 00:24:33,266
мабуть, уже неактуальне, правда?
363
00:24:33,266 --> 00:24:36,536
Адже NIST оголосив у липні:
ми стандартизуємо Kyber.
364
00:24:36,536 --> 00:24:40,677
Тобто: використовуйте Kyber.
365
00:24:40,677 --> 00:24:43,827
Але ні. Насправді вони так не сказали.
366
00:24:43,827 --> 00:24:46,240
Подивімося в деталі.
367
00:24:46,240 --> 00:24:49,870
Пам’ятаєш, як Google
мав проблеми з патентами для NH?
368
00:24:49,870 --> 00:24:54,530
Ну так от, Kyber — це як син New Hope.
369
00:24:54,530 --> 00:24:58,803
І вони, здається, переплутали Star Wars
зі Star Trek:
370
00:24:58,803 --> 00:25:04,388
ходили чутки, що Kyber внутрішньо
називали "New Hope: The Next Generation".
371
00:25:04,994 --> 00:25:09,784
Пізніше знайшли кращу назву,
але по суті — Kyber дуже схожий на NH.
372
00:25:09,784 --> 00:25:15,280
І має ті ж проблеми з патентами.
Це єдиний алгоритм шифрування, який обрав NIST.
373
00:25:15,627 --> 00:25:19,327
Вони обрали SPHINCS+
і ще дві схеми підпису,
374
00:25:19,566 --> 00:25:23,716
і лише одну схему шифрування — Kyber.
Це єдиний варіант захисту ваших даних
375
00:25:23,842 --> 00:25:28,752
відповідно до стандартів NIST.
А Kyber, як і NH, перебуває
376
00:25:28,917 --> 00:25:33,617
у полі з мін із семи патентів.
377
00:25:33,801 --> 00:25:37,331
Це не означає, що всі сім — чинні.
Але це складна справа. Щоб оцінити патент,
378
00:25:37,331 --> 00:25:43,639
треба розуміти патентне право,
і знати, як інтерпретувати пріоритети,
379
00:25:43,666 --> 00:25:47,226
перекриття, розширення.
Все дуже заплутано.
380
00:25:47,226 --> 00:25:51,511
Один із простих способів позбутись патентів —
викупити їх і зробити публічними.
381
00:25:51,565 --> 00:25:57,175
І NIST у липні заявив: ми ведемо
переговори з третіми сторонами,
382
00:25:57,175 --> 00:26:01,130
аби підписати угоди і уникнути
потенційних патентних проблем.
383
00:26:01,130 --> 00:26:04,650
Чудово! Отже, можна використовувати Kyber?
384
00:26:04,650 --> 00:26:06,771
Але компанії кажуть:
385
00:26:06,771 --> 00:26:11,721
«Покажіть нам самі угоди, будь ласка».
386
00:26:12,154 --> 00:26:14,504
Наприклад, Скотт Флюрер із Cisco заявив:
387
00:26:14,627 --> 00:26:17,627
Cisco не зможе впровадити Kyber,
поки ми не побачимо текст ліцензій.
388
00:26:18,647 --> 00:26:26,217
А потім виявилось: NIST узагалі
нічого не підписував у липні.
389
00:26:26,217 --> 00:26:32,841
Але в листопаді вони нарешті сказали:
так, ми підписали дві ліцензійні угоди.
390
00:26:33,661 --> 00:26:35,648
І ось трохи з їхнього змісту.
391
00:26:35,648 --> 00:26:37,908
Ура, супер, можна використовувати Kyber
392
00:26:37,908 --> 00:26:42,107
Але якщо уважно прочитати,
ліцензії стосуються лише стандарту,
393
00:26:42,107 --> 00:26:43,527
який описав NIST.
394
00:26:43,527 --> 00:26:50,359
І будь-яке модифікування або використання
чогось, що не є цим стандартом, — заборонено.
395
00:26:50,781 --> 00:26:54,621
Тобто, Kyber не можна змінювати або
використовувати поза стандартом NIST.
396
00:26:54,864 --> 00:27:00,874
Можливо, ти думаєш: ну, вони ж уже обрали Kyber,
вони ж його стандартизували в липні?
397
00:27:00,874 --> 00:27:06,192
Ні. Насправді в липні
вони лише заявили про наміри.
398
00:27:06,192 --> 00:27:12,035
Вони планують стандартизувати Kyber —
а це не те саме, що «він уже стандартизований».
399
00:27:12,035 --> 00:27:18,421
Планується, що стандартизацію Kyber
завершать у 2024 році.
400
00:27:18,631 --> 00:27:24,571
І проблема в тому, що ми досі не знаємо,
яким саме буде фінальний Kyber у 2024.
401
00:27:24,571 --> 00:27:32,629
Бо досі пропонують зміни.
Тобто навіть якщо вийде стандарт у 2024
402
00:27:32,814 --> 00:27:38,465
і якщо ліцензія дозволяє використовувати Kyber,
403
00:27:38,465 --> 00:27:42,985
то, можливо, у 2023 вони
вже визначили Kyber,
404
00:27:43,386 --> 00:27:47,895
І можливо інші 5 сімей патернів
не зачеплять Kyber.
405
00:27:48,640 --> 00:27:52,994
Буває, що люди проходять мінне
поле — і не вибухають.
406
00:27:53,995 --> 00:27:57,285
Отже, ми дійшли до кінця доповіді.
407
00:27:57,285 --> 00:28:00,525
Ми вже достатньо розповіли про
затримки та обхідні шляхи.
408
00:28:00,525 --> 00:28:01,970
А тепер — що ми мали на увазі під словом «катастрофа»?
409
00:28:01,970 --> 00:28:05,269
Звісно, якщо зламається те, що
410
00:28:05,269 --> 00:28:10,442
було використано у тестах Google
або Cloudflare, це — катастрофа.
411
00:28:10,442 --> 00:28:13,569
Але вони використовували резервний варіант —
використовували гібриди.
412
00:28:13,569 --> 00:28:15,247
Тому це ще нормально.
413
00:28:15,247 --> 00:28:19,170
Справжня катастрофа — це те,
що ми у 2022 році, а у нас
414
00:28:19,170 --> 00:28:24,770
досі нема постквантової криптографії
на телефонах чи комп’ютерах.
415
00:28:24,770 --> 00:28:28,374
Ми можемо вказати на
приклади впровадження,
416
00:28:28,374 --> 00:28:30,594
але загалом — це не масово.
417
00:28:30,594 --> 00:28:34,216
Твої дані все ще зашифровані
алгоритмами,
418
00:28:34,216 --> 00:28:37,430
що можна зламати квантовим комп’ютером.
419
00:28:37,430 --> 00:28:38,923
І це — справжня катастрофа.
420
00:28:38,923 --> 00:28:42,761
Дякуємо за увагу!
421
00:28:45,844 --> 00:28:47,114
Дякую, дякую!
422
00:28:47,114 --> 00:28:53,395
Нерозбірливо
423
00:28:53,395 --> 00:28:57,444
...або технології, які я використовую
у фоновому режимі,
424
00:28:57,444 --> 00:28:58,444
можливо, вже постквантові.
425
00:28:58,444 --> 00:29:01,750
Я думаю, що моє SSH-з'єднання
вже використовує щось таке,
426
00:29:01,750 --> 00:29:02,750
тож, можливо, все не так погано.
427
00:29:02,750 --> 00:29:05,868
Ми завжди можемо покладатися
на OpenBSD.
428
00:29:06,593 --> 00:29:07,833
Однозначно
429
00:29:10,769 --> 00:29:15,182
Подивимось, чи є запитання.
430
00:29:15,182 --> 00:29:21,182
Ось одне: я розробник, створюю додаток.
431
00:29:21,182 --> 00:29:22,958
не обов'язково криптографічний —
432
00:29:22,958 --> 00:29:26,936
як мені впевнитись, що алгоритм стійкий
у постквантову еру?
433
00:29:26,936 --> 00:29:28,652
Чи можу я вже зараз використовувати
гібридний підхід,
434
00:29:28,652 --> 00:29:31,947
щоб захистити своїх користувачів?
435
00:29:32,293 --> 00:29:35,753
О! У нас є слайд саме для цього!
Покажи слайд!
436
00:29:36,154 --> 00:29:39,494
Ми передбачили це питання.
437
00:29:39,494 --> 00:29:41,964
Так, це все виглядає депресивно —
але ось що робити:
438
00:29:41,964 --> 00:29:45,954
Ми маємо слайд з практичними діями,
які ти можеш зробити вже зараз.
439
00:29:45,954 --> 00:29:53,748
І наша порада: використовуй гібриди.
Мені здається, я вже казала це у 2016-му.
440
00:29:53,748 --> 00:29:57,720
Я тоді казала: «Ось, дивись, що ти можеш зробити
вже зараз, ось наші пропозиції».
441
00:29:57,721 --> 00:30:02,241
Ми вважаємо ці варіанти дуже безпечними.
І ось я знову тут — у грудні 2022-го.
442
00:30:02,241 --> 00:30:07,958
і я кажу: McEliece — це дуже обережна система.
І вона не має тих патентних проблем, які має Kyber.
443
00:30:08,665 --> 00:30:13,595
Що ж таке гібрид?
444
00:30:13,595 --> 00:30:17,305
Це комбінація передквантової та
постквантової криптографії.
445
00:30:17,305 --> 00:30:21,232
У шифруванні обидва мають брати
участь у генерації ключа.
446
00:30:21,970 --> 00:30:26,590
У цифровому підписі —
обидва підписи мають бути чинними окремо.
447
00:30:26,590 --> 00:30:30,259
Тільки тоді гібридний підпис — справжній підпис.
448
00:30:32,764 --> 00:30:39,684
Є багато бібліотек, які можна подивитись,
щоб отримати уявлення про різні системи.
449
00:30:39,684 --> 00:30:45,306
Ти можеш спробувати реалізувати їх.
Якість бібліотек зараз вже набагато краща,
450
00:30:45,306 --> 00:30:50,890
ніж кілька років тому.
Постквантові реалізації стають зрілими.
451
00:30:50,890 --> 00:30:55,844
Люди вкладають багато зусиль
у їх вдосконалення. Але ризики залишаються.
452
00:30:55,844 --> 00:31:01,738
Проте ризик нічого не робити —
набагато більший.
453
00:31:01,738 --> 00:31:03,887
Бо якщо ти нічого не зробиш,
твоя інформація залишиться вразливою
454
00:31:03,887 --> 00:31:05,914
для майбутніх атак
з боку квантових комп’ютерів, які вже
455
00:31:05,914 --> 00:31:08,731
сьогодні записують ці дані.
Тож краще експериментуй.
456
00:31:08,731 --> 00:31:13,104
Ось приклад бібліотеки,
яка реалізує кілька різних алгоритмів
457
00:31:13,104 --> 00:31:15,805
називається Quantum Safe OQS.
458
00:31:15,805 --> 00:31:19,314
Є й інші бібліотеки, які працюють
із певними криптосистемами.
459
00:31:19,314 --> 00:31:26,352
Тож у більшості розробників є якийсь застосунок,
але знову ж таки: потрібно оцінювати якість.
460
00:31:26,352 --> 00:31:31,798
Нова бібліотека, яка з’являється — lib.js.
461
00:31:31,798 --> 00:31:35,822
У неї вже є кілька перевірок, і я би
сказав, що вона надійна.
462
00:31:35,822 --> 00:31:42,109
Але, на жаль, єдиний постквантовий
алгоритм у ній — це Kyber.
463
00:31:42,532 --> 00:31:47,272
І якщо ви плануєте на 2024 — добре.
Але на зараз — це ще не варіант.
464
00:31:47,272 --> 00:31:48,874
Він ще не підходить для повноцінного використання прямо зараз.
465
00:31:48,874 --> 00:31:56,830
Якщо хочете щось швидке — подивіться,
466
00:31:56,830 --> 00:32:00,900
що використовують OpenSSH чи
Google з NTRU-HRSS.
467
00:32:00,900 --> 00:32:03,790
Ця система хоча б частково протестована.
468
00:32:03,790 --> 00:32:08,336
Можна спробувати. Але завжди —
використовуйте гібриди з ECC.
469
00:32:08,338 --> 00:32:13,448
На всяк випадок —якщо постквантовий
компонент раптом зламається.
470
00:32:14,120 --> 00:32:18,621
Але ж складно створити власну
систему об’єднання?
471
00:32:18,621 --> 00:32:21,551
Має бути правильний спосіб поєднання.
472
00:32:21,551 --> 00:32:24,851
Мені ж потрібно якось об’єднати класичний
і постквантовий метод.
473
00:32:25,295 --> 00:32:28,590
Так, це можливо.
474
00:32:28,590 --> 00:32:32,860
Іноді достатньо просто: підписати
першим алгоритмом,
475
00:32:32,860 --> 00:32:34,824
підписати другим,
а потім перевірити обидва підписи.
476
00:32:35,314 --> 00:32:42,884
Але ми бачили приклади, де все пішло не так.
Треба бути дуже обережними.
477
00:32:43,375 --> 00:32:48,873
Для шифрування зазвичай використовують
ECC для обміну ключем,
478
00:32:48,873 --> 00:32:52,405
а потім постквантову систему для другого обміну.
479
00:32:52,405 --> 00:32:57,350
І далі об’єднуєш два ключі
через улюблену хеш-функцію.
480
00:32:57,217 --> 00:32:59,670
Стандартна криптографічна хеш-функція —
це завжди добре.
481
00:32:59,670 --> 00:33:01,960
Але ти казав про поєднання —
482
00:33:01,960 --> 00:33:04,833
є чимало досліджень на цю тему...
483
00:33:06,936 --> 00:33:10,916
Йдеться про криптографічну хеш-функцію.
Не використовуй просто якусь xx hash-функцію.
484
00:33:10,916 --> 00:33:13,699
Використовуй ту, яка справді є криптографічною.
485
00:33:13,699 --> 00:33:20,316
Наприклад, SHA-512 —
так, її створили в NSA, але
486
00:33:20,316 --> 00:33:23,700
вона витримала безліч спроб зламати її
і все ще тримається.
487
00:33:23,700 --> 00:33:28,633
Є ще SHA-3, який теж пройшов
публічне оцінювання.
488
00:33:28,633 --> 00:33:35,580
І в більшості випадків немає проблем з тим,
щоб взяти два 32-байтові рядки, з’єднати їх
489
00:33:35,580 --> 00:33:40,345
та пропустити через хеш-функцію.
І це буде ваш симетричний ключ.
490
00:33:42,526 --> 00:33:45,960
Є навіть пропозиції,
як саме це правильно зробити.
491
00:33:45,980 --> 00:33:50,188
Наприклад, IRTF або точніше — CFRG RFC.
А також деякі рекомендації від NIST.
492
00:33:50,278 --> 00:33:54,658
Щодо використання гібридів
у стандартних сценаріях.
493
00:33:54,658 --> 00:34:00,360
І трохи самореклами —
у нас є слайд із попередніми дослідженнями.
494
00:34:00,366 --> 00:34:05,646
Там ми детально описали
підходи до впровадження та об'єднання гібридів.
495
00:34:06,268 --> 00:34:15,518
Як робити це правильно.
Звісно, є ще етап вибору системи.
496
00:34:15,706 --> 00:34:22,868
Потрібно обрати свою систему.
І як бачиш — є багато ризиків у реальному світі.
497
00:34:22,868 --> 00:34:27,096
Можу згадати Skype як приклад для експериментів
498
00:34:27,096 --> 00:34:30,346
але проблема в тому, якщо хочеш
запустити продакшн.
499
00:34:30,346 --> 00:34:36,697
Але якщо це лише для досліджень чи хобі —
то це не страшно.
500
00:34:36,697 --> 00:34:37,398
Якщо ти просто граєшся з цим,
або хочеш написати статтю — все ок.
501
00:34:37,398 --> 00:34:41,268
але для продакшену — треба бути обережним.
502
00:34:41,268 --> 00:34:47,380
І от вам вибір: або як Google — спробувати
щось нове і перевірити, чи не вибухне.
503
00:34:47,380 --> 00:34:52,890
І нам пощастило — воно не вибухнуло.
Тож Google міг далі використовувати
504
00:34:52,890 --> 00:34:57,637
NH або потім NTRU разом із ECC.
Або можна піти іншим шляхом:
505
00:34:57,637 --> 00:35:02,013
Пріоритет безпеці.
506
00:35:02,013 --> 00:35:05,773
Готовність втратити трохи швидкості та пропускної здатності.
507
00:35:05,773 --> 00:35:10,433
Взяти найобережніші постквантові системи
і поєднати їх із ECC або RSA.
508
00:35:10,656 --> 00:35:15,866
Це — вибір, який доведеться зробити,
якщо ви плануєте реалізацію.
509
00:35:18,750 --> 00:35:26,899
То чи нормально використовувати алгоритм,
який ще бере участь у конкурсі?
510
00:35:26,899 --> 00:35:29,948
Який ще не стандартизований
або можливо ніколи не буде?
511
00:35:29,948 --> 00:35:33,636
Навіть якщо для нього ще немає
відомих атак?
512
00:35:34,242 --> 00:35:45,292
Коли бачиш так багато червоних міток —
починаєш думати:
513
00:35:45,292 --> 00:35:47,502
ми, криптографи, взагалі щось тямимо?
514
00:35:47,502 --> 00:35:52,533
Як може бути стільки поламаного?
Це реально ризиковано.
515
00:35:52,533 --> 00:36:00,725
Але факт вибору NIST не додає
дуже багато впевненості.
516
00:36:00,866 --> 00:36:03,526
Окей, хочеш прокоментувати?
517
00:36:03,730 --> 00:36:08,910
Хочу сказати, що ті системи, які відкинули
на першому етапі, ніхто більше не досліджував.
518
00:36:08,910 --> 00:36:15,973
Люди втратили інтерес.
Але ті, що пройшли далі — досліджувалися більше.
519
00:36:15,973 --> 00:36:26,669
Наприклад, NTRU Prime і HRSS-KEM
вийшли в третій раунд.
520
00:36:26,669 --> 00:36:29,579
Але не перемогли у «конкурсі краси»,
який влаштував NIST.
521
00:36:29,579 --> 00:36:32,696
Я вважаю, вони не гірші за ті,
що залишилися в фіналі.
522
00:36:32,762 --> 00:36:42,932
І взагалі всі тут — лякають.
Але Google і OpenSSH таки щось вибрали.
523
00:36:44,410 --> 00:36:48,811
Але більшість із 69 пропозицій —
вже не мають
524
00:36:48,811 --> 00:36:52,990
того рівня безпеки,
який вони мали п’ять років тому.
525
00:36:54,605 --> 00:37:02,715
Атаки стали сильнішими,
а деякі системи не мали запасу міцності.
526
00:37:02,715 --> 00:37:12,424
Щоб зробити обґрунтоване рішення,
треба розуміти історію кожної з них і подумати:
527
00:37:12,424 --> 00:37:17,344
Як довго їх досліджували?
Наскільки вони вистояли?
528
00:37:17,965 --> 00:37:22,665
Деякі досліджені мало,
деякі — трохи більше.
529
00:37:22,665 --> 00:37:28,514
Це і формує ризик.
530
00:37:29,865 --> 00:37:34,565
Three Bears — гарна система.
Але після другого етапу її покинули.
531
00:37:34,565 --> 00:37:38,665
І відтоді її майже ніхто не досліджував.
532
00:37:39,731 --> 00:37:44,351
Вона може бути хорошою —
але ми цього точно не знаємо.
533
00:37:45,820 --> 00:37:54,770
Ті, що пройшли в третій тур —
чорні та сірі на слайді — переважно ок.
534
00:37:56,460 --> 00:37:59,474
І, звісно, сині.
535
00:38:00,302 --> 00:38:05,492
Отже, вибирай ті, що сині або чорні.
Можна вважати, вони найкращі.
536
00:38:05,541 --> 00:38:08,910
І наостанок — швидке питання:
537
00:38:08,910 --> 00:38:10,984
якщо я параноїк у фользяному капелюсі
538
00:38:10,984 --> 00:38:13,830
що я можу зробити,
щоб захистити своє спілкування?
539
00:38:16,718 --> 00:38:18,878
Пропускай усе через OpenSSH.
540
00:38:18,878 --> 00:38:20,703
Це вже непоганий старт.
541
00:38:20,703 --> 00:38:23,409
Але, звісно, треба мати
542
00:38:23,409 --> 00:38:27,787
клієнта і сервер, які це підтримують.
543
00:38:27,787 --> 00:38:31,464
І хоча є деякі експериментальні реалізації —
544
00:38:32,143 --> 00:38:35,603
масового впровадження майже нема.
545
00:38:35,808 --> 00:38:40,258
VPN — ще один приклад.
Так, є постквантові VPN-рішення.
546
00:38:40,258 --> 00:38:43,390
У Movad є постквантова альтернатива —
547
00:38:43,390 --> 00:38:46,530
вони використовують McEliece, вони використовують
548
00:38:46,530 --> 00:38:54,230
WireGuard для VPN, і у WireGuard є
опція додавання додаткового ключа
549
00:38:54,230 --> 00:38:57,042
попередньо узгодженого ключа, який
Movad використовує разом із McEliece,
550
00:38:57,042 --> 00:39:00,662
тобто ви завантажуєте це через McEliece, щоб
забезпечити постквантовий захист у Movad
551
00:39:00,662 --> 00:39:06,940
Тобто це VPN, який не просто між
двома точками — зазвичай ви хочете повністю
552
00:39:06,940 --> 00:39:11,296
з'єднатися з сайтом, до якого підключаєтеся, і
якщо у вас наскрізний захист,
553
00:39:11,296 --> 00:39:14,744
це означає, що і клієнт, і сервер повинні
підтримувати постквантову криптографію
554
00:39:14,802 --> 00:39:19,162
а оскільки впровадження затягнулося,
то наразі вона не настільки поширена, як
555
00:39:19,540 --> 00:39:23,220
я очікував кілька років тому, коли
навколо неї було багато
556
00:39:23,420 --> 00:39:24,410
ентузіазму
557
00:39:24,410 --> 00:39:28,176
нерозбірливо
558
00:39:28,176 --> 00:39:33,879
Добре, Таня хоче, щоб я розповів про PQ Connect,
він незабаром вийде і, сподіваюся, спростить
559
00:39:33,879 --> 00:39:38,109
впровадження постквантової криптографії
для захисту вашого з'єднання
560
00:39:38,164 --> 00:39:43,440
від початку до кінця, але його ще не
випустили, тож я не можу сказати багато
561
00:39:44,903 --> 00:39:50,673
Я з нетерпінням чекаю PQ Connect. Думаю,
це все, дякуємо, що були з нами
562
00:39:50,690 --> 00:39:55,380
і ділилися своїми знаннями, оновленнями,
пов’язаними з постквантовою криптографією
563
00:39:56,278 --> 00:39:59,868
Велике спасибі Тані Ланге
та D.J.B!
564
00:40:00,412 --> 00:40:02,188
Дякуємо!
565
00:40:02,188 --> 00:40:12,595
[Translated by Marta-Sofiya Klakovych
(KYBS2004 course assignment at JYU.FI)]