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