WEBVTT 00:00:00.000 --> 00:00:04.010 У цьому сегменті я хочу дати кілька прикладів потокив шифрів, які використовуються на практиці. 00:00:04.010 --> 00:00:07.072 Я збираюся почати з двох старих прикладів, які насправді не 00:00:07.072 --> 00:00:11.017 повиненні використовуватися в нових системах. Але тим не менше, вони як і раніше досить 00:00:11.017 --> 00:00:14.164 широко використовується і тому я просто хочу, щоб згадати імена, так щоб ви були знайомі з 00:00:14.164 --> 00:00:19.087 з цими поняттями. Перший потоковий шифр, про який я хочу поговорити, називається RC4, розроблений 00:00:19.087 --> 00:00:23.429 ще в 1987 році. І я тільки збираюся дати вам його опис високого-рівня, а потім 00:00:23.429 --> 00:00:27.818 ми будемо говорити про деякі недоліки RC4 і залишимо його. Так RC4 00:00:27.818 --> 00:00:32.702 з перемінним розміром насіння, тут я просто навів приклад, де він буде приймати 128 біт 00:00:32.702 --> 00:00:36.980 як розмір зерна, який потім будуть використовуватися в якості ключа для потокового шифру. 00:00:36.980 --> 00:00:41.738 Перше, що він робить, він розширює 128-бітний секретний ключ до 2048 біт, який 00:00:41.738 --> 00:00:46.382 буде використовуватися як внутрішній стан для генератора. А потім, після того, як це зробить 00:00:46.382 --> 00:00:51.197 це розширення, він в основному виконує дуже простий цикл, де кожна ітерація 00:00:51.197 --> 00:00:55.898 цього циклу виводить один байт вихідних. Так, по суті, ви можете запустити генератор 00:00:55.898 --> 00:01:00.653 так довго, як ви хочете, і створити один байт в той час. Тепер RC4, насправді, як я сказав, 00:01:00.653 --> 00:01:05.205 досить популярний. Він використовується в протоколі HTTPS, і досить часто. 00:01:05.205 --> 00:01:11.888 У ці дні, наприклад, Google використовує RC4 в своєму HTTPS. Він також використовується у WEP як ми 00:01:11.888 --> 00:01:15.686 обговорювалися в останньому сегменті, але, звичайно, у WEP, воно неправильно і 00:01:15.686 --> 00:01:18.861 це повністю небезпечно, так, як воно всередині WEP. Так, протягом багатьох років, 00:01:18.861 --> 00:01:23.886 деякі недоліки були знайдені в RC4, і як наслідок, рекомендується, щоб нові проекти 00:01:23.886 --> 00:01:28.793 фактично не використовували RC4, а використовувати більш сучасні псевдо-генератор випадкових чисел, як ми будемо 00:01:28.793 --> 00:01:34.059 обговорити в кінці відрізка. Отже, дозвольте мені просто згадати два недоліки. 00:01:34.059 --> 00:01:39.561 Таким чином, перший з них, це свого роду дивні принципі, якщо ви подивитеся на другий байт 00:01:39.561 --> 00:01:44.630 виходу RC4. Виявляється, другий байт трохи упереджено. Якщо RC4 був 00:01:44.630 --> 00:01:49.780 зовсім випадковим, ймовірність того, що другий байт буває рівним нулю 00:01:49.780 --> 00:01:54.744 б рівно через 256. Є 256 можливих байтів, ймовірність того, що 00:01:54.744 --> 00:01:59.646 це нуль повинна бути одна на 256. Буває так, що для RC4 ймовірності 00:01:59.646 --> 00:02:04.486 насправді два більше 256, що означає, що якщо ви використовуєте вихід RC4 для шифрування 00:02:04.486 --> 00:02:09.574 повідомлення, другий байт, швидше за все, не будуть зашифровані взагалі. Іншими словами, це буде 00:02:09.574 --> 00:02:14.575 XOR з нулем в два рази ймовірність того, що він повинен. 00:02:14.575 --> 00:02:19.436 Так, дві за 256, замість одного за 256. І до речі, я повинен сказати, що немає 00:02:19.436 --> 00:02:22.849 нічого особливого в другому байті. Виявляється перший і третій байт 00:02:22.849 --> 00:02:27.818 також упереджений. І справді тепер рекомендується, якщо ви збираєтеся використовувати RC4, 00:02:27.818 --> 00:02:32.800 що ви повинні зробити, це ігнорувати основному перші 256 байт вихідний і просто 00:02:32.800 --> 00:02:37.246 почати використовувати вихід генератора, починаючи від 257 байта. Перша пара 00:02:37.246 --> 00:02:41.241 байтів, виявляється упередженною, тому ви просто ігноруєте їх. Друга атака що 00:02:41.241 --> 00:02:48.482 була виявлена, що насправді, якщо ви подивитеся на дуже довге виведення з RC4 так буває 00:02:48.482 --> 00:02:53.863 що ви швидше за все, отримаєте послідовність 00. Іншими словами, ви 00:02:53.863 --> 00:02:58.970 швидше за все, отримаєте шістнадцять біт, два байти нуль, нуль, більше ніж потрібно. Знову ж таки якщо RC4 00:02:58.970 --> 00:03:03.948 був цілком випадковий, ймовірність побачити нуль, нуль буде точно 1/256 00:03:03.948 --> 00:03:08.556 в квадраті. Виявляється RC4 є трохи упередженим та зсуву складає 1/256 у кубі. Його 00:03:08.556 --> 00:03:13.718 виявляється, це упередження фактично починається після того, як кілька гігабайт даних що виробляються 00:03:13.718 --> 00:03:18.634 RC4. Але тим не менш, це щось, що може використовувати для прогнозування генератора 00:03:18.634 --> 00:03:23.120 і безумовно ним можна відрізнити вихід генератора 00:03:23.120 --> 00:03:28.097 з дійсно випадковою послідовностю. Основне те, що нуль, нуль частіше з'являється 00:03:28.097 --> 00:03:32.414 чим потрібно є у distinguisher. А потім в останньому сегменті ми говорили про 00:03:32.414 --> 00:03:36.313 пов'язані з ключем атаки, які були використані для нападу на WEP, які в основному говорять, що 00:03:36.313 --> 00:03:41.078 якщо один використовує ключі, які тісно пов'язані один з одним тоді це дійсно можливо 00:03:41.078 --> 00:03:45.732 щоб відновити кореневий ключ. Так що ці недоліки, які, як відомо, RC4 і як на 00:03:45.732 --> 00:03:50.217 результат, рекомендується в нових систем фактично не використовувати RC4 і замість цього використовувати 00:03:50.217 --> 00:03:54.421 сучасні генератори псевдовипадкових. Гаразд, другий приклад, я хочу дати 00:03:54.421 --> 00:03:59.131 вам зламаний потоковий шифр, який використовується для шифрування DVD фільмів.Коли ви купуєте DVD 00:03:59.131 --> 00:04:03.504 у магазині, фактично фільм шифрується за допомогою потокового шифру під назвою на 00:04:03.504 --> 00:04:07.933 система шифрування змісту, CSS. CSS виявляється зламанним потоковим шифром, 00:04:07.933 --> 00:04:12.523 і ми дуже легко можна взламати його, і я хочу, показати вам, як атакуючий алгоритм 00:04:12.523 --> 00:04:16.894 працює. Ми робимо це, так що ви можете бачити приклад алгоритма атаки, але 00:04:16.894 --> 00:04:21.435 насправді, є багато систем, що в основному використовують цю атаку для розшифровки 00:04:21.435 --> 00:04:25.749 зашифрованих дисків DVD. Так що CSS потоковий шифр заснований на те, що апаратні 00:04:25.749 --> 00:04:30.291 дизайнери люблять. Він призначений до шифрованного потоку обладнання, яке повинна бути 00:04:30.291 --> 00:04:34.491 легко здійсненним в устаткуванні і на основі механізму під назвою в лінійний 00:04:34.491 --> 00:04:38.749 зворотній зв'язок змінити реєстр. Так нелінійним зворотним зв'язком зсувний регістр в основному зареєструвати 00:04:38.749 --> 00:04:43.801 що складається з клітинок, де кожна клітинка містить один біт. Тоді в основному 00:04:43.801 --> 00:04:49.046 що відбувається, є ці крани в певних клітинок, не всі клітинки, певні 00:04:49.046 --> 00:04:54.134 позиції називаються крани. І тоді ці крани каналу в на XOR а потім в 00:04:54.134 --> 00:04:59.053 Кожен цикл, зрушення зареєструвати зрушення вліво. Останній шматок падає 00:04:59.053 --> 00:05:04.345 і перший біт, то стає результатом цього XOR. Так що ви можете бачити, що 00:05:04.345 --> 00:05:08.703 Це дуже простий механізм реалізації і в обладнанні займає дуже мало 00:05:08.703 --> 00:05:13.622 транзисторів. Просто зрушення прямо, останній біт падає з і перший біт тільки 00:05:13.622 --> 00:05:18.541 стає XOR попередніх бітів. Так що насіння для цього LFSR 00:05:18.541 --> 00:05:23.460 в основному, це початковий стан на LFSR. 00:05:23.650 --> 00:05:28.538 І це в основі ряд потік шифрів. Нижче наведено кілька прикладів. Так, як 00:05:28.538 --> 00:05:33.362 Я сказав, DVD шифрування використовує два LFSRs. Я покажу вам, як це працює просто на 00:05:33.362 --> 00:05:38.060 друге. GSM шифрування, вони алгоритмів, що називається A51 і A52. І що 00:05:38.060 --> 00:05:43.456 три LFSRs. Bluetooth використовує шифрування — алгоритм під назвою Електронна нуля. Вони всі 00:05:43.456 --> 00:05:48.534 потік шифри, і що використання чотирьох LFSRs. виявляється всі ці порушуються погано, 00:05:48.534 --> 00:05:53.245 і дійсно, дійсно не слід довіряти для шифрування трафіку, але вони всі 00:05:53.245 --> 00:05:56.705 реалізовані в апаратного забезпечення, так що це трохи складно зараз, змінити яке обладнання 00:05:56.705 --> 00:06:01.047 робить. Але найпростіший з них, CSS, насправді має милий напасти на нього, так що хай 00:06:01.047 --> 00:06:05.459 мені показати вам, як працює атака. Отже, давайте описати, як CSS насправді працює. Так, 00:06:05.459 --> 00:06:11.073 ключ для CSS п'ять байт, а саме 40 біт, п'ять разів восьмий – 40 біт. На 00:06:11.073 --> 00:06:15.587 причина, вони хочуть обмежити себе до лише 40 біт є був DVD шифрування 00:06:15.587 --> 00:06:19.941 розроблений в той час, де експортувати США правил дозволено лише для експорту 00:06:19.941 --> 00:06:25.086 crpyto алгоритми, де ключ був лише 40 біт. Таким чином були дизайнерів CSS 00:06:25.086 --> 00:06:30.206 вже обмежена до дуже, дуже короткий ключів. Просто 40 біт ключі. Отже, їх дизайн працює 00:06:30.206 --> 00:06:35.398 наступним чином. В основному, CSS використовує два LFSR. Один, LFSR 17-біт. Іншими словами, 00:06:35.398 --> 00:06:40.806 Реєстр містить 17 біти. А інші є 25-розрядні LFSR, 00:06:40.806 --> 00:06:46.647 Це трохи більше часу, 25-розрядні LFSR. І як ці LFSRs seeded 00:06:46.647 --> 00:06:51.870 виглядає наступним чином. Так ключ для шифрування, в основному виглядає наступним чином. 00:06:51.870 --> 00:06:57.669 Ви починаєте з один, і використовується для його перші два байти 00:06:57.669 --> 00:07:02.947 ключ. І це початковий стан на LFSR. 00:07:02.947 --> 00:07:08.256 А потім другий LFSR в основному intitialized так само. 00:07:08.256 --> 00:07:14.012 Один об'єднані останніх трьох байт ключ. Ось 00:07:14.012 --> 00:07:19.889 завантажені в початковий стан на LFSR. Ви можете побачити, що перші два байти 00:07:19.889 --> 00:07:25.411 шістнадцять біти, плюс провідних один, що сімнадцять біти в цілому, у той час як другий 00:07:25.411 --> 00:07:31.217 LFSR є 24 біта, плюс один, який є 25 біти. І ви помітите, що ми використовували всі п'ять біти 00:07:31.217 --> 00:07:36.881 ключ. Так, то ці LFSRs в основному балотуватися на вісім циклів, так що вони генерувати 00:07:36.881 --> 00:07:42.333 8 біт виводу. І тоді вони пройти через цей суматора, яка в основному робить 00:07:42.333 --> 00:07:48.197 Додавання за модулем 256. Так, так що це вікні Додавання за модулем 256. Є ще один 00:07:48.197 --> 00:07:54.325 Технічні речі, що відбувається. Справді, давайте фактично — також додав є нести від на 00:07:54.325 --> 00:07:59.723 попередній блоку. Але це не так важливо. Це докладно, що не так 00:07:59.723 --> 00:08:04.761 відповідні. Гаразд, так що кожен блок, ви помітите, що ми робимо додавання за модулем 256 і 00:08:04.761 --> 00:08:09.982 Ми ігнорування на нести, але до виконання в основному додається як нуль або один до на 00:08:09.982 --> 00:08:15.147 Додавання наступний блок. Добре? І потім, в основному це вихід один байт на раунд. 00:08:15.147 --> 00:08:20.411 Гаразд, і то цей байт, то звичайно використовується, XOR-Ед з підходящим 00:08:20.411 --> 00:08:25.167 байт фільм, який під час шифрування. Добре, так що це дуже простий потік 00:08:25.167 --> 00:08:29.986 шифр, вона займає дуже мало устаткування для реалізації. Вона буде працювати швидко, навіть на дуже 00:08:29.986 --> 00:08:35.830 Дешеві устаткування і вона буде шифрувати фільми. Так виходить, що це дуже просто розірвати 00:08:35.830 --> 00:08:41.222 у час приблизно двох до в сімнадцять років. Тепер, дозвольте мені показати вам, як. 00:08:41.222 --> 00:08:45.734 Тому припустимо, що ви перехоплювати фільми, так що тут ми є 00:08:45.734 --> 00:08:50.647 зашифровані фільму, які потрібно розшифрувати. Так що давайте говорити, що це всі зашифровані так 00:08:50.647 --> 00:08:55.279 вас не знаю, що там всередині тут. Однак, так буває, що тільки тому, що 00:08:55.279 --> 00:08:59.970 DVD шифрування використовує файли MPEG, так буває, якщо ви знаєте про префікс у 00:08:59.970 --> 00:09:04.250 звичайний текст, давайте просто сказати, може бути це двадцять байт. Ну, ми знаємо, що якщо ви 00:09:04.250 --> 00:09:08.589 XOR ці дві речі разом, так само в інших словах, ви робите XOR тут, 00:09:08.589 --> 00:09:13.523 те, що ви отримаєте це початковий сегмент на PRG. Таким чином, ви отримаєте на 00:09:13.523 --> 00:09:18.472 перші двадцять байт вихідний CSS, вихід цього PRG. Гаразд, так що тепер 00:09:18.472 --> 00:09:23.986 Ось що ми будемо робити. Так, у нас є перші двадцять байт виводу. Зараз 00:09:23.986 --> 00:09:31.405 Ми виконайте такі дії. Ми спробуємо всі двох до сімнадцять можливі значення першого 00:09:31.405 --> 00:09:37.088 LFSR. Добре? Таким чином, два сімнадцять можливих значень. Так що для кожного значення, так і для 00:09:37.088 --> 00:09:42.622 кожен з цих двох до сімнадцять початкові значення у LFSR, ми збираємося працювати на 00:09:42.622 --> 00:09:47.953 LFSR для двадцяти байт, добре? Так що ми будемо генерувати двадцять байт виходи з цієї 00:09:47.953 --> 00:09:53.284 Перший LFSR, припускаючи, — для кожної з двох сімнадцять можливі параметри. 00:09:53.284 --> 00:09:58.615 Тепер пам'ятаю, ми маємо повний вихідний CSS системи. Так що ми можемо зробити це ми 00:09:58.615 --> 00:10:03.814 можна прийняти цей висновок, який ми маємо. Вилучення його з двадцяти укусів і що ми 00:10:03.814 --> 00:10:08.928 отримав від першого LFSR і якщо насправді наші припущення для початкового стану перший 00:10:08.928 --> 00:10:14.042 LFSR є правильним, що ми повинні отримати є перші двадцять байтове вихід на 00:10:14.042 --> 00:10:19.222 Другий LFSR. Право? Тому що, за визначенням, що вихід з CSS 00:10:19.222 --> 00:10:24.501 система є. Тепер виявляється що дивлячись на 20-байтове послідовність, це дуже легко 00:10:24.501 --> 00:10:29.763 щоб сказати, чи Ця послідовність 20-байтове прийшли з 25-розрядні LFSR, чи ні. Якщо це 00:10:29.763 --> 00:10:33.561 не, то ми знаємо, що наші припущення за 17-розрядні LFSR 00:10:33.561 --> 00:10:37.416 неправильні і потім ми перейдемо до наступного вгадати для LFSR 17-біт і 00:10:37.416 --> 00:10:41.904 наступний думаю, і так далі і так далі. Поки врешті-решт ми потрапили права початковий 00:10:41.904 --> 00:10:46.937 держави за 17-трохи LFSR і тоді ми будемо реально отримати, ми побачимо, що 00:10:46.937 --> 00:10:51.969 20 байтів, що ми отримуємо, як кандидат вихід для 25-розрядні LFSR 00:10:51.969 --> 00:10:56.936 справді можливий вихід для 25-розрядні LFSR. І потім, не тільки буде ми повинні 00:10:56.936 --> 00:11:02.164 дізнався правильну початковий стан для LFSR 17-біт, ми повинні також 00:11:02.164 --> 00:11:07.523 дізнався правильну початкового стану 25-розрядні LFSR. І тоді ми можемо передбачити, що 00:11:07.523 --> 00:11:12.796 залишаючись виходи, CSS і, звичайно, використовуючи, що, ми можемо дешифрувати залишок 00:11:12.796 --> 00:11:17.565 фільм. Ми насправді можна відновити залишилися звичайний текст. Добре. Це 00:11:17.565 --> 00:11:22.335 те, що ми говорили раніше. Так, я сказав це трохи швидко, але, сподіваюся, 00:11:22.335 --> 00:11:27.331 було ясно. Ми також будемо робити домашнє завдання здійснювати на цей тип потоку 00:11:27.331 --> 00:11:31.444 шифри і ви родом з отримаєте точку як ці атаки алгоритмів 00:11:31.444 --> 00:11:36.018 роботи. І я повинен згадати, що є багато відкритих вихідних систем тепер, що насправді 00:11:36.018 --> 00:11:41.453 використовувати цей метод, щоб дешифрувати дані, зашифровані CSS. Гаразд, так що тепер, що ми вже бачили два 00:11:41.453 --> 00:11:45.888 слабкі прикладів, давайте перейдемо до найкращих прикладів і зокрема тим краще 00:11:45.888 --> 00:11:49.370 псевдовипадкових генератори приходять від те, що називається eStream проекту. Це є 00:11:49.370 --> 00:11:55.556 проект, що уклали в 2008 році, і вони право в основному п'ять різних потоку 00:11:55.556 --> 00:12:00.207 шифри, але тут я хочу представити тільки один. Тому перше всіх параметрів для 00:12:00.207 --> 00:12:04.029 Ці шифри потоку є трохи інакше, ніж те, що ми звикли. Так, ці 00:12:04.029 --> 00:12:08.340 потік шифрів, як звичайно, вони мають насіння. Але крім цього них, що і в 00:12:08.340 --> 00:12:12.821 званих даний час і ми побачимо, що даний час використовується для в хвилину. Так 00:12:12.821 --> 00:12:17.487 вони приймають два входи, насіння і в даний час. Ми побачимо, що в даний час використовується для 00:12:17.487 --> 00:12:21.274 за секунду. І звичайно, вони виробляють дуже великі виводу, так n, ось 00:12:21.274 --> 00:12:26.603 набагато, набагато, набагато більше, ніж s. Тепер, коли я кажу nonce, що я маю на увазі — це значення, що з 00:12:26.603 --> 00:12:31.218 ніколи не повторити тих пір, як ключ виправлена. І я поясню, що в більш 00:12:31.218 --> 00:12:35.400 докладно в за секунду. Але зараз, просто думаю, що це як унікальну значення, ніколи не 00:12:35.400 --> 00:12:40.527 повторення тих пір, як ключ це те ж саме. І тому, звичайно, якщо у вас є цей PRG 00:12:40.527 --> 00:12:45.357 Ви б зашифрувати, ви отримаєте шифр потоку як і раніше, за винятком зараз як бачите, на 00:12:45.357 --> 00:12:49.955 PRG приймає як введення ключа і в даний час. І є власність в даний час 00:12:49.955 --> 00:12:56.350 що пара, k r кома, так ключових кома nonce, що ніколи не — ніколи не повторюється. Він має 00:12:56.350 --> 00:13:03.096 ніколи не використовуються більше одного разу. Так суть в тому, що можна повторно використовувати ключ, повторне використання 00:13:03.096 --> 00:13:09.710 ключ, тому що в даний час робить пара унікальний, тому що k і r, лише 00:13:09.710 --> 00:13:16.135 використовується один раз. Я скажу, що вони унікальні. Добре, так що ця nonce роду милий трюк що 00:13:16.135 --> 00:13:21.541 рятує нас біда з переїзд в новий ключ кожного разу. Гаразд, так що зокрема 00:13:21.541 --> 00:13:26.000 приклад з eStream, що я хочу, щоб показати вам, називається сальса двадцять. Це є 00:13:26.000 --> 00:13:30.292 потік шифр, який призначений для реалізації програмного забезпечення та устаткування 00:13:30.292 --> 00:13:33.385 реалізацій. Це навіть цікавий. Ви розумієте, що деякі потік шифри 00:13:33.385 --> 00:13:38.763 розроблений для програмного забезпечення, як RC4. Все це робить покликана зробити 00:13:38.763 --> 00:13:42.689 Програмна реалізація працювати швидко, в той час як інші потік шифри призначені для 00:13:42.689 --> 00:13:48.143 устаткування, як CSS, за допомогою LFSR, які особливо покликаний зробити устаткування 00:13:48.143 --> 00:13:50.963 реалізацій дуже дешево. Крім того, гарна річ про це є те, що 00:13:50.963 --> 00:13:55.008 Таким чином, що це, як легко реалізувати його в апаратне та програмне забезпечення 00:13:55.008 --> 00:13:59.747 Реалізація є також дуже швидко. Отже, дозвольте мені пояснити, як працює сальса. Ну, сальса 00:13:59.747 --> 00:14:05.130 приймає або 128 або 256 біт ключі. Тільки я поясню 128-бітна версія сальси. 00:14:05.130 --> 00:14:11.244 Так що це насіння. А потім вона також вимагає даний час, як перед, яка 00:14:11.244 --> 00:14:15.425 трапляється бути 64 біт. І тоді він буде генерувати великі виводу. Тепер як це робить 00:14:15.425 --> 00:14:21.060 дійсно працюють? Ну, сама функція визначається наступним чином. В основному, враховуючи 00:14:21.060 --> 00:14:26.378 ключ і в даний час, він буде генерувати дуже довго, Ну, давно псевдовипадкових 00:14:26.378 --> 00:14:31.222 послідовність, так довго, як це необхідно. І це зроблю це за допомогою цієї функції, які я будете позначимо 00:14:31.222 --> 00:14:35.653 H. це функція h бере три входи. В основному ключ. Ну, насіння k 00:14:35.653 --> 00:14:40.498 nonce r а потім лічильник, який збільшує від кроку до кроку. Так само... 00:14:40.498 --> 00:14:45.263 від нуля до один, два, три, чотири як тривалих як [нечутний] ми, щоб бути. Добре? Тому в основному, 00:14:45.263 --> 00:14:49.956 на оцінці цього h на цьому k r, але з використанням цього incrementing лічильник, ми можемо отримати на 00:14:49.956 --> 00:14:54.882 послідовності, що це так довго, як ми хочемо. Так що все, що потрібно зробити, це описати як ця функція 00:14:54.882 --> 00:14:59.460 H працює. Тепер дозвольте мені зробити це тут для вас. Як це працює, виглядає наступним чином. Ну, ми 00:14:59.460 --> 00:15:04.693 Почніть шляхом розширення Штатів в щось досить великий, який є 64 байт 00:15:04.693 --> 00:15:10.156 Це давно і ми зробити наступним чином. В основному ми будемо дотримуватися константа на початку, так 00:15:10.156 --> 00:15:15.552 Існує Тао нуль, ці чотири байт, це чотири байт константа, так специфікації для 00:15:15.552 --> 00:15:20.611 Сальса в основному надає значення для Тао нуль. Потім ми покласти k, у яких є 00:15:20.611 --> 00:15:25.467 шістнадцять байт. Потім ми покласти іншу константа. Знову ж таки це чотири байт. І 00:15:25.467 --> 00:15:30.795 як я вже сказав, специфікації в основному призначення те, що Ця фіксована константа. Потім ми покласти 00:15:30.795 --> 00:15:37.435 в даний час, який є 8 байт. Потім ми ставимо індексу. Це лічильник нуль, 00:15:37.435 --> 00:15:43.063 один, два, три, чотири, яка є ще вісім байт. Потім ми покласти іншу константа 00:15:43.063 --> 00:15:49.056 Тау два, яка є ще чотирьох байтів. Потім ми покласти ключ знову, це ще одна 00:15:49.056 --> 00:15:54.714 шістнадцять байт. І потім, нарешті ми третій постійною, Тау три, яка є 00:15:54.714 --> 00:15:59.948 інший чотирьох байтів. Добре, так як я вже сказав, якщо ви підсумувати дані, ви бачите, що ви отримаєте 64 00:15:59.948 --> 00:16:05.249 байт. Тому в основному ми розширювались ключ і в даний час і лічильник на 64 00:16:05.249 --> 00:16:10.886 байт. В основному ключ повторюється двічі я думаю. І тоді ми робимо ми застосовувати на 00:16:10.886 --> 00:16:16.321 функція, я буду називати h цей функціональний мало. добре, так що ми застосувати цю функцію, мало h. 00:16:16.321 --> 00:16:21.659 І це функція, що один до одного, так що це співставляє 64 байт 64 байт. Це є 00:16:21.659 --> 00:16:26.005 повністю оборотна функції, добре? Тому ця функція h, як я вже сказав, це є 00:16:26.005 --> 00:16:30.260 invertable функції. Так дано вводу можна отримати на виході і з огляду на 00:16:30.260 --> 00:16:34.906 Ви можете повернутися до вводу виводу. І призначений спеціально тому вона має на - легко 00:16:34.906 --> 00:16:39.553 для реалізації в устаткування і b-x-86, це дуже легко реалізувати, тому що 00:16:39.553 --> 00:16:44.199 x86 має цей SSE2 інструкція встановити, який підтримує всі операції потрібно робити 00:16:44.199 --> 00:16:48.622 для цієї функції. Це дуже, дуже швидко. В результаті, сальса має дуже швидкий потік 00:16:48.622 --> 00:16:52.764 шифр. І тоді він робить це в основному знову і знову. Так що це відноситься це 00:16:52.764 --> 00:16:57.744 Функція h знову і він отримує інший 64 байт. І так далі і тому подібне, в основному 00:16:57.744 --> 00:17:05.318 він робить це в десять разів. Добре, так що все це тут, сказати повторюється в десять разів, так 00:17:05.318 --> 00:17:17.961 в основному застосовуються h десять разів. А то сам по собі, це насправді не досить випадковий. 00:17:17.961 --> 00:17:22.144 Це не буде дивитися випадкові, тому що, як ми вже казали, H є повністю invertable. Так, зважаючи 00:17:22.144 --> 00:17:25.521 Цей кінцевого виводу, це дуже легко, просто Інвертувати h і потім повернутися до оригіналу 00:17:25.521 --> 00:17:31.831 входи і потім тест, що введення має право структури. Так робити ще одна 00:17:31.831 --> 00:17:36.979 річ, яка є в основному XOR, входи і виходи остаточний. Фактично, 00:17:36.979 --> 00:17:42.405 Вибач. Це не є XOR. Це насправді доповненням. Так ви зробити доповнення-слово 00:17:42.405 --> 00:17:47.762 слово. Так що якщо 64 байт, ви робите слово за словом доповнення чотирьох байтів в на 00:17:47.762 --> 00:17:52.980 час і, нарешті, ви отримаєте 64-байтове виводу, і все. Це весь 00:17:52.980 --> 00:17:57.175 генератор псевдовипадкових. Так що, що є функції, мало h. І, як я 00:17:57.175 --> 00:18:01.758 пояснили, це цілий будівництво тут є функція великих h. І тоді вам оцінити 00:18:01.758 --> 00:18:06.009 Великий h на збільшує лічильник я з нуля, один, два, три року. І що 00:18:06.009 --> 00:18:10.408 дасть вам псевдовипадкових послідовності, що це так довго, як це буде потрібно. І 00:18:10.408 --> 00:18:15.325 в основному, це не signifigant зазнає нападу на це. Це має безпеки що з 00:18:15.325 --> 00:18:20.371 дуже близько двох до 128. Ми побачимо, що це означає, що більше саме пізніше на. 00:18:20.371 --> 00:18:25.417 Це дуже швидкий потік шифр, як апаратного і програмного забезпечення. І, наскільки 00:18:25.417 --> 00:18:30.431 Ми можемо сказати, що це, як видається, непередбачуваний, як це потрібно для потоку шифр. Так я 00:18:30.431 --> 00:18:34.797 треба сказати, проект eStream насправді має п'ять потік шифри як 00:18:34.797 --> 00:18:39.395 це. Я тільки вибрав сальса, тому що я думаю, це самий елегантний. Але я можу дати вам 00:18:39.395 --> 00:18:44.053 деякі продуктивність номери тут. Так що ви можете бачити, це продуктивність чисел на на 00:18:44.053 --> 00:18:48.768 2.2 Гігагерц, ви знаєте, x86 типа. І ви можете бачити, що RC4 фактично на 00:18:48.768 --> 00:18:53.017 повільний. Тому, що по суті, Ну це не дійсно скористатися на 00:18:53.017 --> 00:18:57.475 устаткування. Він тільки робить байтів операцій. І так багато даремно циклів, 00:18:57.475 --> 00:19:01.182 не використовується. Але E-потік кандидатів, сальса та інші 00:19:01.182 --> 00:19:05.202 кандидат називається Sosemanuk. Я повинен сказати, що це eStream фіналістів. Ці 00:19:05.202 --> 00:19:09.588 власне потік шифрів, які затверджені eStream проекту. Ви можете бачити, що 00:19:09.588 --> 00:19:13.712 вони досягли значних ставки. Це 643 мегабайт за секунду на цьому 00:19:13.712 --> 00:19:18.150 Архітектура, більш ніж достатньо для фільму і ці насправді просто вражало 00:19:18.150 --> 00:19:22.432 ставки. І тепер ви бачили приклади двох старі шифрів потоку, що не повинно бути 00:19:22.432 --> 00:19:26.661 використовуються, включаючи нападів на ці потік шифрів. Ви бачили, сучасний ефір шифри 00:19:26.661 --> 00:19:30.480 схожі з цього nonce. І ви побачите цифри продуктивності для цих 00:19:30.480 --> 00:19:34.546 сучасний ефір шифрів, так що якщо вам трапиться потрібен шифр потоку ви могли б використовувати один з 00:19:34.546 --> 00:19:37.991 eStream фіналістів. Зокрема, ви могли б використовувати щось подібне до сальси.