WEBVTT

00:00:00.000 --> 00:00:04.010
В этой лекции я хочу показать несколько примеров потоковых шифров, которые используются на практике.

00:00:04.010 --> 00:00:07.072
Я хочу начать с двух старых примеров, которые фактически не

00:00:07.072 --> 00:00:11.017
должны использоваться в новых системах.
Но тем не менее, они все еще довольно

00:00:11.017 --> 00:00:14.164
широко распространены и поэтому я просто хочу упомянуть их названия, чтобы вы познакомились с

00:00:14.164 --> 00:00:19.087
этими концепциями. Первый потоковый шифр, о котором я хочу поговорить называется RC4, придуманный

00:00:19.087 --> 00:00:23.429
в 1987 году. Я просто дам вам его общее описание, затем

00:00:23.429 --> 00:00:27.818
мы поговорим о некоторых недостатках RC4 и на этом закончим. Итак RC4 занимает

00:00:27.818 --> 00:00:32.702
переменный размер источника, для примера я взял 128

00:00:32.702 --> 00:00:36.980
бит как размер источника, который будет затем использоваться в качестве ключа для шифрования потока.

00:00:36.980 --> 00:00:41.738
Первое, что она делает это расширяет 128-битный секретный ключ в 2048 бит, который

00:00:41.738 --> 00:00:46.382
будет использоваться как внутреннее состояние для генератора. И затем, после завершения

00:00:46.382 --> 00:00:51.197
этого расширения, он в основном выполняет очень простой цикл, где на каждой итерации

00:00:51.197 --> 00:00:55.898
этот цикл выводит один байт вывода. Так по сути, можно запускать генератор

00:00:55.898 --> 00:01:00.653
очень долго и генерировать один байт все время. Сейчас RC4 , как я уже сказал, довольно

00:01:00.653 --> 00:01:05.205
популярен. Он часто используется в протоколе HTTPS .

00:01:05.205 --> 00:01:11.888
Сейчас, например, RC4 использует Google в своем HTTPS. А также он используется в WEP который мы

00:01:11.888 --> 00:01:15.686
обсуждали на прошлой лекции, конечно, в WEP, он используется неправильно и

00:01:15.686 --> 00:01:18.861
Это совершенно небезопасный путь использования его внутри WEP. Так с годами

00:01:18.861 --> 00:01:23.886
некоторые недостатки были обнаружены в RC4, и в результате, реккомендуется, чтобы новые проекты

00:01:23.886 --> 00:01:28.793
не использовали RC4, а использовали более современные псевдослучайные генараторы, о которых мы будем

00:01:28.793 --> 00:01:34.059
говорить ближе к концу лекции. Итак, позвольте мне упомянуть два недостатка.

00:01:34.059 --> 00:01:39.561
Первый из них, покажется довольно странным, если вы посмотрите на второй байт

00:01:39.561 --> 00:01:44.630
вывода RC4. Оказывается, второй байт немного ассиметричный(??). Если RC4 был

00:01:44.630 --> 00:01:49.780
случайным то вероятность того, что второй байт будет нулем

00:01:49.780 --> 00:01:54.744
одна к 256. Есть 256 возможных байтов, вероятность

00:01:54.744 --> 00:01:59.646
нуля одна к 256. Случилось так, что для RC4 вероятность

00:01:59.646 --> 00:02:04.486
два к 256, это означает, что если вы используете RC4 вывод для шифрования

00:02:04.486 --> 00:02:09.574
сообщения второй байт, скорее всего, не будут зашифрован. Другими словами

00:02:09.574 --> 00:02:14.575
этот ноль будет проXORен дважды

00:02:14.575 --> 00:02:19.436
Поэтому два к 256, а не 1 к 256.
И кстати, я должен сказать, что нет

00:02:19.436 --> 00:02:22.849
ничего особенного во втором байте. Оказывается, первый и третий байт

00:02:22.849 --> 00:02:27.818
также ассиметричны. В настоящее время рекомендуется, если вы собираетесь использовать RC4,

00:02:27.818 --> 00:02:32.800
игнорировать в основном первые 256 байт вывода и просто

00:02:32.800 --> 00:02:37.246
начинать использовать выходные данные генератора, начиная с байта 257. Первая пара

00:02:37.246 --> 00:02:41.241
байт оказалась ассиметричной, так что вы просто игнорируете ее. При второй аттаке

00:02:41.241 --> 00:02:48.482
было обнаружено, что на самом деле, если вы посмотрите на очень длинный вывод из RC4, получается

00:02:48.482 --> 00:02:53.863
что у вас больше шансов получить последовательность 00. Другими словами вы

00:02:53.863 --> 00:02:58.970
скорее всего, получите шестнадцать битов по два байта ноль, ноль. Опять же если RC4

00:02:58.970 --> 00:03:03.948
была совершенно случайная, вероятность получения ноль, ноль будет ровно 1/256

00:03:03.948 --> 00:03:08.556
в квадрате. Оказывается, RC4 является немного ассиметричной и ассиметрия эта 1/256 в кубе. Этот

00:03:08.556 --> 00:03:13.718
уклон фактически начинается после нескольких гигабайт данных и производятся

00:03:13.718 --> 00:03:18.634
RC4. Но тем не менее, это как раз то, что может использоваться для прогнозирования генератора

00:03:18.634 --> 00:03:23.120
и определенно может использоваться для различения вывода генератора

00:03:23.120 --> 00:03:28.097
из действительно случайных последовательностей. В принципе тот факт, что ноль, ноль появляется чаще

00:03:28.097 --> 00:03:32.414
чем он должен это и есть отличительный признак. И затем в последней лекции мы говорили о

00:03:32.414 --> 00:03:36.313
связанных с ключом атаках, которые были использованы для атаки WEP, и которые в основном говорят, что

00:03:36.313 --> 00:03:41.078
Если один использует ключи, которые тесно связаны друг с другом, то это на самом деле дает возможность

00:03:41.078 --> 00:03:45.732
восстановления ключа корня. Вот такие недостатки присутствуют в RC4 и, как

00:03:45.732 --> 00:03:50.217
результат, рекомендуется, не использовать RC4 в новых системах, а вместо нее использовать

00:03:50.217 --> 00:03:54.421
современный псевдослучайный генератор. Ладно, второй пример, который я хочу вам показать это

00:03:54.421 --> 00:03:59.131
взломанный потоковый шифр. Он используется для шифрования DVD фильмов. Когда вы покупаете DVD

00:03:59.131 --> 00:04:03.504
в магазине, фактически фильм шифруется с использованием шифров под названием

00:04:03.504 --> 00:04:07.933
content scrambling system, CSS. CSS оказывается взломанным потоковым шифром,

00:04:07.933 --> 00:04:12.523
и мы очень легко можем взломать его, и я хочу показать вам, как работает алгоритм атаки.

00:04:12.523 --> 00:04:16.894
Вы можете увидеть пример алгоритма нападения на слайде, но по

00:04:16.894 --> 00:04:21.435
факту, существует множество других систем, которые в основном используют это нападение для расшифровки

00:04:21.435 --> 00:04:25.749
зашифрованных DVD. Таким образом, CSS потоковый шифр основанный на том, что любят разработчики

00:04:25.749 --> 00:04:30.291
аппаратной части. Он соответствует аппаратному потоковому шифру, который должен

00:04:30.291 --> 00:04:34.491
быть легко осуществлен в аппаратной части и основывается на механизме с названием линейные

00:04:34.491 --> 00:04:38.749
регистры сдвига с обратной связью . Таким образом линейные регистры сдвига с обратной связью - это в основном регистры

00:04:38.749 --> 00:04:43.801
которые состоят из ячеек, где каждая ячейка содержит один бит. Что затем

00:04:43.801 --> 00:04:49.046
происходит? В определенных ячейках есть отводы, не во всех, а на определенных

00:04:49.046 --> 00:04:54.134
позициях. Затем эти отводы XORят и на

00:04:54.134 --> 00:04:59.053
каждом тактовом цикле, сдвиг происходит влево. Последний бит уходит

00:04:59.053 --> 00:05:04.345
и затем первый бит становится результатом этого XOR. Так что вы можете видеть, что

00:05:04.345 --> 00:05:08.703
этот механизм очень простой для реализации и в оборудовании занимает немного

00:05:08.703 --> 00:05:13.622
транзисторов. Простой сдвиг вправо, последний бит уходит и первый бит просто

00:05:13.622 --> 00:05:18.541
становится XORом предыдущих битов. Так что источник для этого LFSR

00:05:18.541 --> 00:05:23.460
в основном является начальным состоянием LFSR.

00:05:23.650 --> 00:05:28.538
И это является основой целого ряда потоковых шифров. Так вот несколько примеров. Как

00:05:28.538 --> 00:05:33.362
я сказал, DVD шифрования использует два LFSRs.
Я покажу вам как это работает через

00:05:33.362 --> 00:05:38.060
минуту. Шифрование GSM, а именно алгоритмы с названием A51 и A52. Они

00:05:38.060 --> 00:05:43.456
используют три LFSRs. Bluetooth Шифрование — алгоритм шифрования с названием E ноль. Это все

00:05:43.456 --> 00:05:48.534
потоковые шифры, которые используют четыре LFSRs. получается, все это - взломанные шифры,

00:05:48.534 --> 00:05:53.245
и действительно, не следует доверять для шифрованию трафика, так как они все

00:05:53.245 --> 00:05:56.705
реализованы аппаратно, поэтому довольно сложно сейчас изменить то, что заложено в оборудование.

00:05:56.705 --> 00:06:01.047
Но самый простой из них, CSS, очень мило взламывается, поэтому позвольте

00:06:01.047 --> 00:06:05.459
мне показать вам, как работает эта атака. Итак рассмотрим как фактически CSS работает.

00:06:05.459 --> 00:06:11.073
Ключ для CSS состоит их пяти байтов, а именно 40 бит, пять раз по восемь это 40 бит.

00:06:11.073 --> 00:06:15.587
Причина, по которой стоит ограничение 40 бит состоит в том, что DVD шифрование было

00:06:15.587 --> 00:06:19.941
разработано тогда, когда экспорт США был разрешен только для

00:06:19.941 --> 00:06:25.086
крипто алгоритмы с ключем в 40 бит. Поэтому разработчики CSS

00:06:25.086 --> 00:06:30.206
были ограничены очень очень короткими ключами.
Ключ всего из 40 бит. Таким образом их проект был

00:06:30.206 --> 00:06:35.398
следующим. В основном CSS использует два LFSR. Один является 17-битным LFSR. Другими словами,

00:06:35.398 --> 00:06:40.806
Регистр содержит 17 бит. И второй — 25-битный LFSR,

00:06:40.806 --> 00:06:46.647
Он немного больше - 25-бит. Исследованием LFSRs

00:06:46.647 --> 00:06:51.870
является следующим. Ключ для шифрования, в основном выглядит таким следующим образом.

00:06:51.870 --> 00:06:57.669
Вы начинаете с одного и объединяете первые два байта

00:06:57.669 --> 00:07:02.947
ключа. Это и есть начальное состояние LFSR.

00:07:02.947 --> 00:07:08.256
И тогда второй LFSR инициализируется таким же образом.

00:07:08.256 --> 00:07:14.012
Один соединен с последним тремя байтами ключа. Это

00:07:14.012 --> 00:07:19.889
загружается в начальное состояние LFSR.
Вы можете увидеть что первые два байта

00:07:19.889 --> 00:07:25.411
состоят из шестнадцати битов, плюс один главный, что составляет семнадцать бит в целом, тогда как второй

00:07:25.411 --> 00:07:31.217
LFSR — 24 бита, плюс один, в итоге 25 бит.
Заметьте, что мы использовали все пять бит

00:07:31.217 --> 00:07:36.881
ключа. Дажее эти LFSRs в основном запускаются для восьми циклов, так что они генерируют

00:07:36.881 --> 00:07:42.333
восемь бит вывода. И затем они идут через сумматор, который в основном производит

00:07:42.333 --> 00:07:48.197
сложение по модулю 256.Да, это блок сложения по модулю 256. Существует еще одна

00:07:48.197 --> 00:07:54.325
техническая вещь. В самом деле давайте добавим это к информации из

00:07:54.325 --> 00:07:59.723
предыдущего блока. Но это не так важно. Это деталь не столь

00:07:59.723 --> 00:08:04.761
так уместна. Хорошо, итак в каждом блоке, заметьте что мы делаем сложение по модулю 256 и

00:08:04.761 --> 00:08:09.982
игнорируем транспортировку, но она в основном добавляет ноль или единицу

00:08:09.982 --> 00:08:15.147
в следующий блок. Понятно? И затем выводим один байт за раунд.

00:08:15.147 --> 00:08:20.411
Затем этот байт тогда конечно используется, проXORенный с соответствующим

00:08:20.411 --> 00:08:25.167
байтом из фильма, который был зашифрован.
Итак, это очень простой потоковый

00:08:25.167 --> 00:08:29.986
шифр, который занимает очень мало аппаратных средств для реализации. Он будет работать быстро, даже на очень

00:08:29.986 --> 00:08:35.830
дешевом оборудовании, шифруя фильмы.
Поэтому его легко взломать

00:08:35.830 --> 00:08:41.222
в промежутке времени от 2 до 17 переборов. Теперь позвольте мне показать вам это.

00:08:41.222 --> 00:08:45.734
Предположим, что вы перехватили фильм, поэтому десь мы имеем

00:08:45.734 --> 00:08:50.647
зашифрованный фильм, который вы хотите расшифровать.
Давайте скажем, что вы не имеете понятия о том

00:08:50.647 --> 00:08:55.279
что находится здесь внутри. Такое случается потому что

00:08:55.279 --> 00:08:59.970
DVD шифрование использует MPEG файлы, так случилось, что вы знаете префикс

00:08:59.970 --> 00:09:04.250
открытого текста, давайте просто скажем что он равен 20 байт. Мы знаем, что если вы

00:09:04.250 --> 00:09:08.589
проXORите эти две вещи вместе, другими словами, вы делаете здесь XOR

00:09:08.589 --> 00:09:13.523
в итоге получаете первоначальный сегмент PRG. Таким образом, вы получите

00:09:13.523 --> 00:09:18.472
первые 20 байт вывода CSS, используя вывод PRG. Ладно, теперь

00:09:18.472 --> 00:09:23.986
вот что мы собираемся делать. У нас первые 20 байт выходных данных. Теперь

00:09:23.986 --> 00:09:31.405
мы делаем следующее. Мы пробуем все от двух до семнадцати возможных значений первого

00:09:31.405 --> 00:09:37.088
LFSR. Хорошо? От двух до семнадцати возможных значений. Таким образом, для каждого значения, и для каждого из

00:09:37.088 --> 00:09:42.622
этих двух до семнадцати начальных значений LFSR, мы запускаем

00:09:42.622 --> 00:09:47.953
LFSR для 20 байт, понятно? Поэтому мы будем генерировать 20 байт выходов из

00:09:47.953 --> 00:09:53.284
Первого LFSR, предполагая — для каждого от двух семнадцати возможных параметров.

00:09:53.284 --> 00:09:58.615
Теперь вспомните, что у нас есть полный вывод CSS системы. Все что мы можем сделать это

00:09:58.615 --> 00:10:03.814
взять этот вывод и вычесть его из двадцати байтов, которые у нас есть

00:10:03.814 --> 00:10:08.928
из первого LFSR и, если на самом деле наша догадка для начального состояния первого

00:10:08.928 --> 00:10:14.042
LFSR является верной, все что мы должны получить - это первый двадцатибайтовый вывод

00:10:14.042 --> 00:10:19.222
второго LFSR. Правильно? Потому что это по определению вывод CSS

00:10:19.222 --> 00:10:24.501
системы. Теперь получается, что глядя на 20-байтную последовательность, очень легко

00:10:24.501 --> 00:10:29.763
сказать является ли эта 20-байтная последовательность 25-разрядным LFSR или нет. Если нет

00:10:29.763 --> 00:10:33.561
тогда мы знаем, что наша догадка для 17-разрядного LFSR

00:10:33.561 --> 00:10:37.416
неправильна и затем мы перейдем к следующему предположению для 17-разрядного LFSR и

00:10:37.416 --> 00:10:41.904
затем следующей догадке и так далее и так далее.
До тех пор, пока в конце концов мы не попадем в верное первоначальное

00:10:41.904 --> 00:10:46.937
состояние для 17-битных LFSR и тогда мы увидим, что

00:10:46.937 --> 00:10:51.969
20 байт, которые мы получаем на выходе для 25-разрядного LFSR

00:10:51.969 --> 00:10:56.936
в самом деле возможны на выходе для 25-разрядного LFSR. И тогда, мы не только

00:10:56.936 --> 00:11:02.164
научимся правильно определять начальное состояние для 17-битных LFSR, мы также

00:11:02.164 --> 00:11:07.523
узнаем верное начальное состояние 25-разрядного LFSR. И затем мы сможем предсказать

00:11:07.523 --> 00:11:12.796
оставшиеся выводы CSS и, используя это, мы сможем расшифровать остальную часть

00:11:12.796 --> 00:11:17.565
фильма. На самом деле мы можем восстановить оставшуюся часть открытым текстом. Отлично. Это

00:11:17.565 --> 00:11:22.335
вещи, о который мы уже говорили. Я рассказал это довольно быстро, но надеюсь,

00:11:22.335 --> 00:11:27.331
было ясно. Также на этот тип потового шифра есть домашнее задание

00:11:27.331 --> 00:11:31.444
и вы получите своего рода понятие о том, как эти атакующие алгоритмы

00:11:31.444 --> 00:11:36.018
работают. И я должен отметить, что сейчас существует множество открытых систем, которые

00:11:36.018 --> 00:11:41.453
Используют этот метод для расшифровки данных, зашифрованных с помощью CSS. Хорошо. Итак мы уже рассмотрели два

00:11:41.453 --> 00:11:45.888
простенький примера, давайте перейдем на более серьезные примеры, в частности лучшие

00:11:45.888 --> 00:11:49.370
псевдослучайные генераторы приходят из так называемого eStream проекта. Этот

00:11:49.370 --> 00:11:55.556
проект был основан в 2008 году, и они квалифицируются в основном на пяти различных потоковых

00:11:55.556 --> 00:12:00.207
шифрах, но здесь я хочу представить только один. Так первый из всех параметров для

00:12:00.207 --> 00:12:04.029
этих потоковых шифров, немного отличается, от тех которые мы использовали. Эти

00:12:04.029 --> 00:12:08.340
потоковые шифры как и все имеют источник.
Кроме того они имеют, так называемый

00:12:08.340 --> 00:12:12.821
случайный код и мы увидим, для чего используется данный случай через минуту.

00:12:12.821 --> 00:12:17.487
Итак они принимают на входе два параметра: источник и случайный код. Мы увидим, для чего используется случайный код

00:12:17.487 --> 00:12:21.274
через секунду. И конечно они производят очень большой выход, так что n здесь

00:12:21.274 --> 00:12:26.603
гораздо, гораздо, гораздо больше, чем s. Теперь, когда я говорю случайный код, я имею в виду это значение, которые

00:12:26.603 --> 00:12:31.218
никогда не будут повторяться до тех пор, пока ключ будет фиксированным. Я объясню более

00:12:31.218 --> 00:12:35.400
подробно через секунду. Но теперь, просто думайте о нем, как об уникальном значении, которое не будет

00:12:35.400 --> 00:12:40.527
повторятся до тех пор пока длится ключ.
И поэтому, конечно, как только вы получите PRG,

00:12:40.527 --> 00:12:45.357
и зашифруете, то получите потоковый шифр как и прежде, за исключением теперь того, что

00:12:45.357 --> 00:12:49.955
PRG принимает как входные данные ключ и одноразовый код. И свойство случайного кода это

00:12:49.955 --> 00:12:56.350
пара: k запятая r, поэтому ключ запятая случайный код, никогда не — никогда не повторяются. Он

00:12:56.350 --> 00:13:03.096
никогда не используется более одного раза. Таким образом в нижней строке описана возможность повторно использовать ключ, повторно использовать

00:13:03.096 --> 00:13:09.710
ключ, потому что случайный код делает пару уникальной, потому что k и r

00:13:09.710 --> 00:13:16.135
используются только один раз. Я скажу, что они уникальны. Ладно, этот случайный код это своего рода трюк, который,

00:13:16.135 --> 00:13:21.541
спасает нас от проблемы перехода на новый ключ каждый раз. Ладно, итак

00:13:21.541 --> 00:13:26.000
пример из eStream, который я хочу показать вам называют Сальса двадцать. Это

00:13:26.000 --> 00:13:30.292
потоковый шифр, который предназначен для реализации программного и аппаратного обеспечения

00:13:30.292 --> 00:13:33.385
Это достаточно интересно.
Вы должны понимать, что некоторые потоковые шифры

00:13:33.385 --> 00:13:38.763
предназначены для программного обеспечения, как RC4.
Все что разработано для

00:13:38.763 --> 00:13:42.689
программной реализации работает быстро, тогда как другие потоковые шифры разработанные для

00:13:42.689 --> 00:13:48.143
аппартаного обеспечения, как CSS, с помощью LFSR, частично разработано для того, чтобы сделать

00:13:48.143 --> 00:13:50.963
реализацию дешевле. Еще одна хорошая вещь в том

00:13:50.963 --> 00:13:55.008
что это легко осуществить его в аппаратном обеспечении и его программная

00:13:55.008 --> 00:13:59.747
разработка является также очень быстрой. Поэтому позвольте мне объяснить, как работает Сальса. Ну, сальса

00:13:59.747 --> 00:14:05.130
содержит 128 или 256-разрядный ключи. Только я объясню 128-разрядную версию сальсы.

00:14:05.130 --> 00:14:11.244
Это источник. И затем он также принимает случайный код, просто как и прежде

00:14:11.244 --> 00:14:15.425
случалось с 64 битами. И тогда он будет генерировать большой вывод. Теперь как это

00:14:15.425 --> 00:14:21.060
на самом деле работает? Ну сама функция определяется следующим образом. В основном учитывая

00:14:21.060 --> 00:14:26.378
ключ и случайный код, он будет генерировать очень длинную, ну, длинную псевдослучайную

00:14:26.378 --> 00:14:31.222
последовательность, так долго, как необходимо. И он делает это с помощью этой функции, которую я обозначу

00:14:31.222 --> 00:14:35.653
H. Эта функция H принимает три входа.
В основном ключ. Источник k,

00:14:35.653 --> 00:14:40.498
случайный код r, а затем счетчик, который увеличивается от шага к шагу. Так он идет

00:14:40.498 --> 00:14:45.263
от нуля до одного, двух, трех, четырех до тех пор пока нужно. Ладно? Поэтому в основном,

00:14:45.263 --> 00:14:49.956
по оценке этой H на этом k r, но используя этот счетчик приращения, мы можем получить

00:14:49.956 --> 00:14:54.882
последовательность такую, как нам нужно. Поэтому все что нужно сделать, это описать как эта функция

00:14:54.882 --> 00:14:59.460
H работает. Теперь позвольте мне сделать это здесь для вас.
Она работает следующим образом. Ну мы

00:14:59.460 --> 00:15:04.693
начинаем путем расширения состояния в нечто довольно большое, длиной 64 байт

00:15:04.693 --> 00:15:10.156
и мы делаем это следующим образом. В основном мы придерживаемся констант в начале, так

00:15:10.156 --> 00:15:15.552
есть tao ноль, эти четыре байта, это константа 4 байта, поэтому спецификации

00:15:15.552 --> 00:15:20.611
Сальсы в основном дает вам значение для tao ноль. Затем мы ставим k в котором

00:15:20.611 --> 00:15:25.467
шестнадцать байт. Затем мы ставим другую константу. Опять же это четыре байта. И

00:15:25.467 --> 00:15:30.795
как я сказал, спецификация в основном определяет фиксированную константу. Затем мы ставим

00:15:30.795 --> 00:15:37.435
случайный код, из восемь байтов. Затем индекс. Этот Счетчик ноль,

00:15:37.435 --> 00:15:43.063
один, два, три, четыре, который содержит еще восемь байт. Затем мы ставим другую константу

00:15:43.063 --> 00:15:49.056
Тау два, которая является еще четырьмя байтами.
Затем мы ставим ключ снова, это еще

00:15:49.056 --> 00:15:54.714
шестнадцать байт. И затем, наконец, мы ставим третью константу, Тау три, которая содержит

00:15:54.714 --> 00:15:59.948
еще четыре байта. Ладно, так, как я сказал, если вы, просуммируете все это, то получите 64

00:15:59.948 --> 00:16:05.249
байта. Поэтому мы расширили ключ, случайны код и счетчик в 64

00:16:05.249 --> 00:16:10.886
байт. В основном ключ повторяется дважды. И то, что мы делаем это применяем

00:16:10.886 --> 00:16:16.321
функцию, я буду называть эту функцию маленькой h. хорошо, поэтому мы применяем эту функцию, маленькую h.

00:16:16.321 --> 00:16:21.659
И это функция, которая является один к одному, поэтому он сопоставляется 64 байта 64 байт. Это

00:16:21.659 --> 00:16:26.005
полностью обратимой функция, ладно? Так что эта функция h, как я говорю, это

00:16:26.005 --> 00:16:30.260
invertable функция. Учитывая входные данные вы можете получить результат и учитывая

00:16:30.260 --> 00:16:34.906
выход, вы можете вернуться к входу. И он предназначен специально, поэтому он имеет - легко

00:16:34.906 --> 00:16:39.553
для реализации в аппаратных средств и b-на x 86, это очень легко осуществить, поскольку

00:16:39.553 --> 00:16:44.199
x 86 имеет этой SSE2 инструкции набор, который поддерживает все операции, вам нужно сделать

00:16:44.199 --> 00:16:48.622
для этой функции. Это очень, очень быстро.
В результате сальса имеет очень быстрый поток

00:16:48.622 --> 00:16:52.764
шифр. А затем она делает это в основном снова и снова. Поэтому он применяется это

00:16:52.764 --> 00:16:57.744
Функция h снова и он получает еще 64 байта. И так далее и так далее, в основном

00:16:57.744 --> 00:17:05.318
Он делает это в десять раз. Итак все это здесь, говорят повторяется в десять раз, так что

00:17:05.318 --> 00:17:17.961
в основном применяют h в десять раз. И затем сам по себе, это на самом деле не совсем случайно.

00:17:17.961 --> 00:17:22.144
Он является не собираешься смотреть случайные потому, что как мы сказали, H является полностью invertable. Так что

00:17:22.144 --> 00:17:25.521
Этот конечный результат, это очень легко просто инвертировать h и затем вернуться к оригиналу

00:17:25.521 --> 00:17:31.831
входы и затем тест, что ввод имеет право структуру. Так вы сделать еще один

00:17:31.831 --> 00:17:36.979
вещь, которая является в основном XOR входов и конечных мероприятий. На самом деле,

00:17:36.979 --> 00:17:42.405
Извините. Это не XOR. Это на самом деле дополнением. Таким образом вы сделать дополнение слово

00:17:42.405 --> 00:17:47.762
слово. Так что если есть 64 байта, вы сделать добавить слово в слово четырех байтов

00:17:47.762 --> 00:17:52.980
время и, наконец, вы получите 64-байтовый вывода, и вот оно. Это весь

00:17:52.980 --> 00:17:57.175
генератор псевдослучайных. Так что, что вся функция, мало h. И, как я

00:17:57.175 --> 00:18:01.758
объяснил, эта вся конструкция является функция большой H. И тогда вы оценить

00:18:01.758 --> 00:18:06.009
большой H путем увеличения счетчика I, ноль, один, два, три года. И что

00:18:06.009 --> 00:18:10.408
даст вам псевдослучайной последовательности, которая является столько, сколько вам нужно оно быть. И

00:18:10.408 --> 00:18:15.325
в принципе существует не signifigant нападения на это. Это имеет безопасности это

00:18:15.325 --> 00:18:20.371
непосредственной близости от двух до 128. Мы увидим, что это означает, что более точно позже на.

00:18:20.371 --> 00:18:25.417
Это очень быстрый потоковый шифр, аппаратного и программного обеспечения. И, насколько

00:18:25.417 --> 00:18:30.431
Мы можем сказать, это, как представляется, быть непредсказуемым, необходимые для потоковый шифр. Так что я

00:18:30.431 --> 00:18:34.797
следует сказать, что eStream проекта на самом деле имеет пять потоковые шифры как

00:18:34.797 --> 00:18:39.395
это. Я только выбрал сальса, потому что я думаю, что это самый элегантный. Но я могу дать вам

00:18:39.395 --> 00:18:44.053
Некоторые номера производительность здесь. Таким образом вы можете видеть, это показателей деятельности на

00:18:44.053 --> 00:18:48.768
2,2 Гигагерца, вы знаете, x 86 типа машины.
И вы можете видеть, что на самом деле является RC4

00:18:48.768 --> 00:18:53.017
медленный. Потому что по существу, ну он не принимает действительно преимущество

00:18:53.017 --> 00:18:57.475
аппаратное обеспечение. Она только не байтовые операции.
И так много впустую циклов,

00:18:57.475 --> 00:19:01.182
не используются. Но E-поток кандидатов, сальса и другие

00:19:01.182 --> 00:19:05.202
кандидат, называется Sosemanuk. Я должен сказать, что эти eStream финалистов. Эти

00:19:05.202 --> 00:19:09.588
на самом деле потоковых шифров, которые утверждаются eStream проекта. Вы можете видеть, что

00:19:09.588 --> 00:19:13.712
они достигли значительную скорость.
Это 643 МБ в секунду на этот

00:19:13.712 --> 00:19:18.150
Архитектура, более чем достаточно для кино и они на самом деле впечатляет

00:19:18.150 --> 00:19:22.432
Тарифы. И поэтому теперь вы видели примеры двух старых потоковые шифры, которые не должны быть

00:19:22.432 --> 00:19:26.661
используется, включая нападения на эти потоковые шифры.
Вы видели, современные поток шифры

00:19:26.661 --> 00:19:30.480
как выглядеть с этой nonce. И вы увидите число показателей для этих

00:19:30.480 --> 00:19:34.546
современные поток шифры, так что если вы будете нуждаться в потоковый шифр можно использовать один из

00:19:34.546 --> 00:19:37.991
eStream финалистов. В частности вы могли бы использовать что-то вроде сальсы.