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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

0:06:25.086,0:06:30.206
были ограничены очень очень короткими ключами.[br]Ключ всего из 40 бит. Таким образом их проект был

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

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

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

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

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

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

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

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

0:07:14.012,0:07:19.889
загружается в начальное состояние LFSR.[br]Вы можете увидеть что первые два байта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

0:12:04.029,0:12:08.340
потоковые шифры как и все имеют источник.[br]Кроме того они имеют, так называемый

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

0:13:33.385,0:13:38.763
предназначены для программного обеспечения, как RC4.[br]Все что разработано для

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

0:14:54.882,0:14:59.460
H работает. Теперь позвольте мне сделать это здесь для вас.[br]Она работает следующим образом. Ну мы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

0:19:09.588,0:19:13.712
они достигли значительную скорость.[br]Это 643 МБ в секунду на этот

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

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

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

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

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

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