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

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

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

0:06:25.086,0:06:30.206
вже обмежена до дуже, дуже короткий ключів.[br]Просто 40 біт ключі. Отже, їх дизайн працює

0:06:30.206,0:06:35.398
наступним чином. В основному, CSS використовує два LFSR. Один, LFSR 17-біт. Іншими словами,

0:06:35.398,0:06:40.806
Реєстр містить 17 біти. А інші є 25-розрядні LFSR,

0:06:40.806,0:06:46.647
Це трохи більше часу, 25-розрядні LFSR. І як ці LFSRs seeded

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

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

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

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
вас не знаю, що там всередині тут.[br]Однак, так буває, що тільки тому, що

0:08:55.279,0:08:59.970
DVD шифрування використовує файли MPEG, так буває, якщо ви знаєте про префікс у

0:08:59.970,0:09:04.250
звичайний текст, давайте просто сказати, може бути це двадцять байт. Ну, ми знаємо, що якщо ви

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

0:09:18.472,0:09:23.986
Ось що ми будемо робити. Так, у нас є перші двадцять байт виводу. Зараз

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

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

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

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
вони приймають два входи, насіння і в даний час.[br]Ми побачимо, що в даний час використовується для

0:12:17.487,0:12:21.274
за секунду. І звичайно, вони виробляють дуже великі виводу, так n, ось

0:12:21.274,0:12:26.603
набагато, набагато, набагато більше, ніж s. Тепер, коли я кажу nonce, що я маю на увазі — це значення, що з

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

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

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

0:14:40.498,0:14:45.263
від нуля до один, два, три, чотири як тривалих як [нечутний] ми, щоб бути. Добре? Тому в основному,

0:14:45.263,0:14:49.956
на оцінці цього h на цьому k r, але з використанням цього incrementing лічильник, ми можемо отримати на

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

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

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

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