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

2
00:00:04,010 --> 00:00:07,072
Я хочу начать с двух старых примеров, которые фактически не

3
00:00:07,072 --> 00:00:11,017
должны использоваться в новых системах.
Но тем не менее, они все еще довольно

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

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

6
00:00:19,087 --> 00:00:23,429
в 1987 году. Я просто дам вам его общее описание, затем

7
00:00:23,429 --> 00:00:27,818
мы поговорим о некоторых недостатках RC4 и на этом закончим. Итак RC4 занимает

8
00:00:27,818 --> 00:00:32,702
переменный размер источника, для примера я взял 128

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

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

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

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

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

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

15
00:01:00,653 --> 00:01:05,205
популярен. Он часто используется в протоколе HTTPS .

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

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

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

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

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

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

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

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

24
00:01:44,630 --> 00:01:49,780
случайным то вероятность того, что второй байт будет нулем

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

26
00:01:54,744 --> 00:01:59,646
нуля одна к 256. Случилось так, что для RC4 вероятность

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

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

29
00:02:09,574 --> 00:02:14,575
этот ноль будет проXORен дважды

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

31
00:02:19,436 --> 00:02:22,849
ничего особенного во втором байте. Оказывается, первый и третий байт

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

33
00:02:27,818 --> 00:02:32,800
игнорировать в основном первые 256 байт вывода и просто

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

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

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

37
00:02:48,482 --> 00:02:53,863
что у вас больше шансов получить последовательность 00. Другими словами вы

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

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

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

41
00:03:08,556 --> 00:03:13,718
уклон фактически начинается после нескольких гигабайт данных и производятся

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

43
00:03:18,634 --> 00:03:23,120
и определенно может использоваться для различения вывода генератора

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

45
00:03:28,097 --> 00:03:32,414
чем он должен это и есть отличительный признак. И затем в последней лекции мы говорили о

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

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

48
00:03:41,078 --> 00:03:45,732
восстановления ключа корня. Вот такие недостатки присутствуют в RC4 и, как

49
00:03:45,732 --> 00:03:50,217
результат, рекомендуется, не использовать RC4 в новых системах, а вместо нее использовать

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

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

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

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

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

55
00:04:12,523 --> 00:04:16,894
Вы можете увидеть пример алгоритма нападения на слайде, но по

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

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

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

59
00:04:30,291 --> 00:04:34,491
быть легко осуществлен в аппаратной части и основывается на механизме с названием линейные

60
00:04:34,491 --> 00:04:38,749
регистры сдвига с обратной связью . Таким образом линейные регистры сдвига с обратной связью - это в основном регистры

61
00:04:38,749 --> 00:04:43,801
которые состоят из ячеек, где каждая ячейка содержит один бит. Что затем

62
00:04:43,801 --> 00:04:49,046
происходит? В определенных ячейках есть отводы, не во всех, а на определенных

63
00:04:49,046 --> 00:04:54,134
позициях. Затем эти отводы XORят и на

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

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

66
00:05:04,345 --> 00:05:08,703
этот механизм очень простой для реализации и в оборудовании занимает немного

67
00:05:08,703 --> 00:05:13,622
транзисторов. Простой сдвиг вправо, последний бит уходит и первый бит просто

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

69
00:05:18,541 --> 00:05:23,460
в основном является начальным состоянием LFSR.

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

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

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

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

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

75
00:05:48,534 --> 00:05:53,245
и действительно, не следует доверять для шифрованию трафика, так как они все

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

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

78
00:06:01,047 --> 00:06:05,459
мне показать вам, как работает эта атака. Итак рассмотрим как фактически CSS работает.

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

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

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

82
00:06:19,941 --> 00:06:25,086
крипто алгоритмы с ключем в 40 бит. Поэтому разработчики CSS

83
00:06:25,086 --> 00:06:30,206
были ограничены очень очень короткими ключами.
Ключ всего из 40 бит. Таким образом их проект был

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

85
00:06:35,398 --> 00:06:40,806
Регистр содержит 17 бит. И второй — 25-битный LFSR,

86
00:06:40,806 --> 00:06:46,647
Он немного больше - 25-бит. Исследованием LFSRs

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

88
00:06:51,870 --> 00:06:57,669
Вы начинаете с одного и объединяете первые два байта

89
00:06:57,669 --> 00:07:02,947
ключа. Это и есть начальное состояние LFSR.

90
00:07:02,947 --> 00:07:08,256
И тогда второй LFSR инициализируется таким же образом.

91
00:07:08,256 --> 00:07:14,012
Один соединен с последним тремя байтами ключа. Это

92
00:07:14,012 --> 00:07:19,889
загружается в начальное состояние LFSR.
Вы можете увидеть что первые два байта

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

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

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

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

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

98
00:07:48,197 --> 00:07:54,325
техническая вещь. В самом деле давайте добавим это к информации из

99
00:07:54,325 --> 00:07:59,723
предыдущего блока. Но это не так важно. Это деталь не столь

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

101
00:08:04,761 --> 00:08:09,982
игнорируем транспортировку, но она в основном добавляет ноль или единицу

102
00:08:09,982 --> 00:08:15,147
в следующий блок. Понятно? И затем выводим один байт за раунд.

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

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

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

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

107
00:08:35,830 --> 00:08:41,222
в промежутке времени от 2 до 17 переборов. Теперь позвольте мне показать вам это.

108
00:08:41,222 --> 00:08:45,734
Предположим, что вы перехватили фильм, поэтому десь мы имеем

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

110
00:08:50,647 --> 00:08:55,279
что находится здесь внутри. Такое случается потому что

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

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

113
00:09:04,250 --> 00:09:08,589
проXORите эти две вещи вместе, другими словами, вы делаете здесь XOR

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

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

116
00:09:18,472 --> 00:09:23,986
вот что мы собираемся делать. У нас первые 20 байт выходных данных. Теперь

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

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

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

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

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

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

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

124
00:10:03,814 --> 00:10:08,928
из первого LFSR и, если на самом деле наша догадка для начального состояния первого

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

126
00:10:14,042 --> 00:10:19,222
второго LFSR. Правильно? Потому что это по определению вывод CSS

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

128
00:10:24,501 --> 00:10:29,763
сказать является ли эта 20-байтная последовательность 25-разрядным LFSR или нет. Если нет

129
00:10:29,763 --> 00:10:33,561
тогда мы знаем, что наша догадка для 17-разрядного LFSR

130
00:10:33,561 --> 00:10:37,416
неправильна и затем мы перейдем к следующему предположению для 17-разрядного LFSR и

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

132
00:10:41,904 --> 00:10:46,937
состояние для 17-битных LFSR и тогда мы увидим, что

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

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

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

136
00:11:02,164 --> 00:11:07,523
узнаем верное начальное состояние 25-разрядного LFSR. И затем мы сможем предсказать

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

138
00:11:12,796 --> 00:11:17,565
фильма. На самом деле мы можем восстановить оставшуюся часть открытым текстом. Отлично. Это

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

140
00:11:22,335 --> 00:11:27,331
было ясно. Также на этот тип потового шифра есть домашнее задание

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

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

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

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

145
00:11:45,888 --> 00:11:49,370
псевдослучайные генераторы приходят из так называемого eStream проекта. Этот

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

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

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

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

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

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

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

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

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

155
00:12:31,218 --> 00:12:35,400
подробно через секунду. Но теперь, просто думайте о нем, как об уникальном значении, которое не будет

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

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

158
00:12:45,357 --> 00:12:49,955
PRG принимает как входные данные ключ и одноразовый код. И свойство случайного кода это

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

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

161
00:13:03,096 --> 00:13:09,710
ключ, потому что случайный код делает пару уникальной, потому что k и r

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

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

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

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

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

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

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

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

170
00:13:48,143 --> 00:13:50,963
реализацию дешевле. Еще одна хорошая вещь в том

171
00:13:50,963 --> 00:13:55,008
что это легко осуществить его в аппаратном обеспечении и его программная

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

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

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

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

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

177
00:14:21,060 --> 00:14:26,378
ключ и случайный код, он будет генерировать очень длинную, ну, длинную псевдослучайную

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

201
00:16:26,005 --> 00:16:30,260
invertable функция. Учитывая входные данные вы можете получить результат и учитывая

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

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

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

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

206
00:16:48,622 --> 00:16:52,764
шифр. А затем она делает это в основном снова и снова. Поэтому он применяется это

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

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

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

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

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

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

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

214
00:17:36,979 --> 00:17:42,405
Извините. Это не XOR. Это на самом деле дополнением. Таким образом вы сделать дополнение слово

215
00:17:42,405 --> 00:17:47,762
слово. Так что если есть 64 байта, вы сделать добавить слово в слово четырех байтов

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

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

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

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

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

221
00:18:10,408 --> 00:18:15,325
в принципе существует не signifigant нападения на это. Это имеет безопасности это

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

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

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

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

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

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

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

229
00:18:48,768 --> 00:18:53,017
медленный. Потому что по существу, ну он не принимает действительно преимущество

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

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

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

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

234
00:19:09,588 --> 00:19:13,712
они достигли значительную скорость.
Это 643 МБ в секунду на этот

235
00:19:13,712 --> 00:19:18,150
Архитектура, более чем достаточно для кино и они на самом деле впечатляет

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

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

238
00:19:26,661 --> 00:19:30,480
как выглядеть с этой nonce. И вы увидите число показателей для этих

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

240
00:19:34,546 --> 00:19:37,991
eStream финалистов. В частности вы могли бы использовать что-то вроде сальсы.