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
У ці дні, наприклад, Google використовує RC4 в своєму 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, замість одного за 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
чим потрібно є у distinguisher. А потім в останньому сегменті ми говорили про

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
система шифрування змісту, 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 використовує шифрування — алгоритм під назвою Електронна нуля. Вони всі

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
crpyto алгоритми, де ключ був лише 40 біт. Таким чином були дизайнерів CSS

83
00:06:25,086 --> 00:06:30,206
вже обмежена до дуже, дуже короткий ключів.
Просто 40 біт ключі. Отже, їх дизайн працює

84
00:06:30,206 --> 00:06:35,398
наступним чином. В основному, CSS використовує два LFSR. Один, LFSR 17-біт. Іншими словами,

85
00:06:35,398 --> 00:06:40,806
Реєстр містить 17 біти. А інші є 25-розрядні LFSR,

86
00:06:40,806 --> 00:06:46,647
Це трохи більше часу, 25-розрядні LFSR. І як ці LFSRs seeded

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 в основному intitialized так само.

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
8 біт виводу. І тоді вони пройти через цей суматора, яка в основному робить

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
у час приблизно двох до в сімнадцять років. Тепер, дозвольте мені показати вам, як.

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
звичайний текст, давайте просто сказати, може бути це двадцять байт. Ну, ми знаємо, що якщо ви

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
перші двадцять байт вихідний CSS, вихід цього PRG. Гаразд, так що тепер

116
00:09:18,472 --> 00:09:23,986
Ось що ми будемо робити. Так, у нас є перші двадцять байт виводу. Зараз

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 для двадцяти байт, добре? Так що ми будемо генерувати двадцять байт виходи з цієї

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
неправильні і потім ми перейдемо до наступного вгадати для LFSR 17-біт і

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
дізнався правильну початковий стан для LFSR 17-біт, ми повинні також

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. Тепер, коли я кажу nonce, що я маю на увазі — це значення, що з

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 кома, так ключових кома nonce, що ніколи не — ніколи не повторюється. Він має

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
використовується один раз. Я скажу, що вони унікальні. Добре, так що ця nonce роду милий трюк що

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
nonce r а потім лічильник, який збільшує від кроку до кроку. Так само...

181
00:14:40,498 --> 00:14:45,263
від нуля до один, два, три, чотири як тривалих як [нечутний] ми, щоб бути. Добре? Тому в основному,

182
00:14:45,263 --> 00:14:49,956
на оцінці цього h на цьому k r, але з використанням цього incrementing лічильник, ми можемо отримати на

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
Існує Тао нуль, ці чотири байт, це чотири байт константа, так специфікації для

188
00:15:15,552 --> 00:15:20,611
Сальса в основному надає значення для Тао нуль. Потім ми покласти 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
в даний час, який є 8 байт. Потім ми ставимо індексу. Це лічильник нуль,

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
x86 має цей 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 на збільшує лічильник я з нуля, один, два, три року. І що

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 Гігагерц, ви знаєте, x86 типа.
І ви можете бачити, що 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 фіналістів. Зокрема, ви могли б використовувати щось подібне до сальси.