< Return to Video

Real-world stream ciphers (20 min)

  • 0:00 - 0:04
    У цьому сегменті я хочу дати кілька прикладів потокив шифрів, які використовуються на практиці.
  • 0:04 - 0:07
    Я збираюся почати з двох старих прикладів, які насправді не
  • 0:07 - 0:11
    повиненні використовуватися в нових системах.
    Але тим не менше, вони як і раніше досить
  • 0:11 - 0:14
    широко використовується і тому я просто хочу, щоб згадати імена, так щоб ви були знайомі з
  • 0:14 - 0:19
    з цими поняттями. Перший потоковий шифр, про який я хочу поговорити, називається RC4, розроблений
  • 0:19 - 0:23
    ще в 1987 році. І я тільки збираюся дати вам його опис високого-рівня, а потім
  • 0:23 - 0:28
    ми будемо говорити про деякі недоліки RC4 і залишимо його. Так RC4
  • 0:28 - 0:33
    з перемінним розміром насіння, тут я просто навів приклад, де він буде приймати 128 біт
  • 0:33 - 0:37
    як розмір зерна, який потім будуть використовуватися в якості ключа для потокового шифру.
  • 0:37 - 0:42
    Перше, що він робить, він розширює 128-бітний секретний ключ до 2048 біт, який
  • 0:42 - 0:46
    буде використовуватися як внутрішній стан для генератора. А потім, після того, як це зробить
  • 0:46 - 0:51
    це розширення, він в основному виконує дуже простий цикл, де кожна ітерація
  • 0:51 - 0:56
    цього циклу виводить один байт вихідних. Так, по суті, ви можете запустити генератор
  • 0:56 - 1:01
    так довго, як ви хочете, і створити один байт в той час. Тепер RC4, насправді, як я сказав,
  • 1:01 - 1:05
    досить популярний. Він використовується в протоколі HTTPS, і досить часто.
  • 1:05 - 1:12
    У ці дні, наприклад, Google використовує RC4 в своєму HTTPS. Він також використовується у WEP як ми
  • 1:12 - 1:16
    обговорювалися в останньому сегменті, але, звичайно, у WEP, воно неправильно і
  • 1:16 - 1:19
    це повністю небезпечно, так, як воно всередині WEP. Так, протягом багатьох років,
  • 1:19 - 1:24
    деякі недоліки були знайдені в RC4, і як наслідок, рекомендується, щоб нові проекти
  • 1:24 - 1:29
    фактично не використовували RC4, а використовувати більш сучасні псевдо-генератор випадкових чисел, як ми будемо
  • 1:29 - 1:34
    обговорити в кінці відрізка. Отже, дозвольте мені просто згадати два недоліки.
  • 1:34 - 1:40
    Таким чином, перший з них, це свого роду дивні принципі, якщо ви подивитеся на другий байт
  • 1:40 - 1:45
    виходу RC4. Виявляється, другий байт трохи упереджено. Якщо RC4 був
  • 1:45 - 1:50
    зовсім випадковим, ймовірність того, що другий байт буває рівним нулю
  • 1:50 - 1:55
    б рівно через 256. Є 256 можливих байтів, ймовірність того, що
  • 1:55 - 2:00
    це нуль повинна бути одна на 256. Буває так, що для RC4 ймовірності
  • 2:00 - 2:04
    насправді два більше 256, що означає, що якщо ви використовуєте вихід RC4 для шифрування
  • 2:04 - 2:10
    повідомлення, другий байт, швидше за все, не будуть зашифровані взагалі. Іншими словами, це буде
  • 2:10 - 2:15
    XOR з нулем в два рази ймовірність того, що він повинен.
  • 2:15 - 2:19
    Так, дві за 256, замість одного за 256.
    І до речі, я повинен сказати, що немає
  • 2:19 - 2:23
    нічого особливого в другому байті. Виявляється перший і третій байт
  • 2:23 - 2:28
    також упереджений. І справді тепер рекомендується, якщо ви збираєтеся використовувати RC4,
  • 2:28 - 2:33
    що ви повинні зробити, це ігнорувати основному перші 256 байт вихідний і просто
  • 2:33 - 2:37
    почати використовувати вихід генератора, починаючи від 257 байта. Перша пара
  • 2:37 - 2:41
    байтів, виявляється упередженною, тому ви просто ігноруєте їх. Друга атака що
  • 2:41 - 2:48
    була виявлена, що насправді, якщо ви подивитеся на дуже довге виведення з RC4 так буває
  • 2:48 - 2:54
    що ви швидше за все, отримаєте послідовність 00. Іншими словами, ви
  • 2:54 - 2:59
    швидше за все, отримаєте шістнадцять біт, два байти нуль, нуль, більше ніж потрібно. Знову ж таки якщо RC4
  • 2:59 - 3:04
    був цілком випадковий, ймовірність побачити нуль, нуль буде точно 1/256
  • 3:04 - 3:09
    в квадраті. Виявляється RC4 є трохи упередженим та зсуву складає 1/256 у кубі. Його
  • 3:09 - 3:14
    виявляється, це упередження фактично починається після того, як кілька гігабайт даних що виробляються
  • 3:14 - 3:19
    RC4. Але тим не менш, це щось, що може використовувати для прогнозування генератора
  • 3:19 - 3:23
    і безумовно ним можна відрізнити вихід генератора
  • 3:23 - 3:28
    з дійсно випадковою послідовностю. Основне те, що нуль, нуль частіше з'являється
  • 3:28 - 3:32
    чим потрібно є у distinguisher. А потім в останньому сегменті ми говорили про
  • 3:32 - 3:36
    пов'язані з ключем атаки, які були використані для нападу на WEP, які в основному говорять, що
  • 3:36 - 3:41
    якщо один використовує ключі, які тісно пов'язані один з одним тоді це дійсно можливо
  • 3:41 - 3:46
    щоб відновити кореневий ключ. Так що ці недоліки, які, як відомо, RC4 і як на
  • 3:46 - 3:50
    результат, рекомендується в нових систем фактично не використовувати RC4 і замість цього використовувати
  • 3:50 - 3:54
    сучасні генератори псевдовипадкових. Гаразд, другий приклад, я хочу дати
  • 3:54 - 3:59
    вам зламаний потоковий шифр, який використовується для шифрування DVD фільмів.Коли ви купуєте DVD
  • 3:59 - 4:04
    у магазині, фактично фільм шифрується за допомогою потокового шифру під назвою на
  • 4:04 - 4:08
    система шифрування змісту, CSS. CSS виявляється зламанним потоковим шифром,
  • 4:08 - 4:13
    і ми дуже легко можна взламати його, і я хочу, показати вам, як атакуючий алгоритм
  • 4:13 - 4:17
    працює. Ми робимо це, так що ви можете бачити приклад алгоритма атаки, але
  • 4:17 - 4:21
    насправді, є багато систем, що в основному використовують цю атаку для розшифровки
  • 4:21 - 4:26
    зашифрованих дисків DVD. Так що CSS потоковий шифр заснований на те, що апаратні
  • 4:26 - 4:30
    дизайнери люблять. Він призначений до шифрованного потоку обладнання, яке повинна бути
  • 4:30 - 4:34
    легко здійсненним в устаткуванні і на основі механізму під назвою в лінійний
  • 4:34 - 4:39
    зворотній зв'язок змінити реєстр. Так нелінійним зворотним зв'язком зсувний регістр в основному зареєструвати
  • 4:39 - 4:44
    що складається з клітинок, де кожна клітинка містить один біт. Тоді в основному
  • 4:44 - 4:49
    що відбувається, є ці крани в певних клітинок, не всі клітинки, певні
  • 4:49 - 4:54
    позиції називаються крани. І тоді ці крани каналу в на XOR а потім в
  • 4:54 - 4:59
    Кожен цикл, зрушення зареєструвати зрушення вліво. Останній шматок падає
  • 4:59 - 5:04
    і перший біт, то стає результатом цього XOR. Так що ви можете бачити, що
  • 5:04 - 5:09
    Це дуже простий механізм реалізації і в обладнанні займає дуже мало
  • 5:09 - 5:14
    транзисторів. Просто зрушення прямо, останній біт падає з і перший біт тільки
  • 5:14 - 5:19
    стає XOR попередніх бітів. Так що насіння для цього LFSR
  • 5:19 - 5:23
    в основному, це початковий стан на LFSR.
  • 5:24 - 5:29
    І це в основі ряд потік шифрів. Нижче наведено кілька прикладів. Так, як
  • 5:29 - 5:33
    Я сказав, DVD шифрування використовує два LFSRs.
    Я покажу вам, як це працює просто на
  • 5:33 - 5:38
    друге. GSM шифрування, вони алгоритмів, що називається A51 і A52. І що
  • 5:38 - 5:43
    три LFSRs. Bluetooth використовує шифрування — алгоритм під назвою Електронна нуля. Вони всі
  • 5:43 - 5:49
    потік шифри, і що використання чотирьох LFSRs. виявляється всі ці порушуються погано,
  • 5:49 - 5:53
    і дійсно, дійсно не слід довіряти для шифрування трафіку, але вони всі
  • 5:53 - 5:57
    реалізовані в апаратного забезпечення, так що це трохи складно зараз, змінити яке обладнання
  • 5:57 - 6:01
    робить. Але найпростіший з них, CSS, насправді має милий напасти на нього, так що хай
  • 6:01 - 6:05
    мені показати вам, як працює атака. Отже, давайте описати, як CSS насправді працює. Так,
  • 6:05 - 6:11
    ключ для CSS п'ять байт, а саме 40 біт, п'ять разів восьмий – 40 біт. На
  • 6:11 - 6:16
    причина, вони хочуть обмежити себе до лише 40 біт є був DVD шифрування
  • 6:16 - 6:20
    розроблений в той час, де експортувати США правил дозволено лише для експорту
  • 6:20 - 6:25
    crpyto алгоритми, де ключ був лише 40 біт. Таким чином були дизайнерів CSS
  • 6:25 - 6:30
    вже обмежена до дуже, дуже короткий ключів.
    Просто 40 біт ключі. Отже, їх дизайн працює
  • 6:30 - 6:35
    наступним чином. В основному, CSS використовує два LFSR. Один, LFSR 17-біт. Іншими словами,
  • 6:35 - 6:41
    Реєстр містить 17 біти. А інші є 25-розрядні LFSR,
  • 6:41 - 6:47
    Це трохи більше часу, 25-розрядні LFSR. І як ці LFSRs seeded
  • 6:47 - 6:52
    виглядає наступним чином. Так ключ для шифрування, в основному виглядає наступним чином.
  • 6:52 - 6:58
    Ви починаєте з один, і використовується для його перші два байти
  • 6:58 - 7:03
    ключ. І це початковий стан на LFSR.
  • 7:03 - 7:08
    А потім другий LFSR в основному intitialized так само.
  • 7:08 - 7:14
    Один об'єднані останніх трьох байт ключ. Ось
  • 7:14 - 7:20
    завантажені в початковий стан на LFSR.
    Ви можете побачити, що перші два байти
  • 7:20 - 7:25
    шістнадцять біти, плюс провідних один, що сімнадцять біти в цілому, у той час як другий
  • 7:25 - 7:31
    LFSR є 24 біта, плюс один, який є 25 біти.
    І ви помітите, що ми використовували всі п'ять біти
  • 7:31 - 7:37
    ключ. Так, то ці LFSRs в основному балотуватися на вісім циклів, так що вони генерувати
  • 7:37 - 7:42
    8 біт виводу. І тоді вони пройти через цей суматора, яка в основному робить
  • 7:42 - 7:48
    Додавання за модулем 256. Так, так що це вікні Додавання за модулем 256. Є ще один
  • 7:48 - 7:54
    Технічні речі, що відбувається. Справді, давайте фактично — також додав є нести від на
  • 7:54 - 8:00
    попередній блоку. Але це не так важливо. Це докладно, що не так
  • 8:00 - 8:05
    відповідні. Гаразд, так що кожен блок, ви помітите, що ми робимо додавання за модулем 256 і
  • 8:05 - 8:10
    Ми ігнорування на нести, але до виконання в основному додається як нуль або один до на
  • 8:10 - 8:15
    Додавання наступний блок. Добре? І потім, в основному це вихід один байт на раунд.
  • 8:15 - 8:20
    Гаразд, і то цей байт, то звичайно використовується, XOR-Ед з підходящим
  • 8:20 - 8:25
    байт фільм, який під час шифрування.
    Добре, так що це дуже простий потік
  • 8:25 - 8:30
    шифр, вона займає дуже мало устаткування для реалізації. Вона буде працювати швидко, навіть на дуже
  • 8:30 - 8:36
    Дешеві устаткування і вона буде шифрувати фільми.
    Так виходить, що це дуже просто розірвати
  • 8:36 - 8:41
    у час приблизно двох до в сімнадцять років. Тепер, дозвольте мені показати вам, як.
  • 8:41 - 8:46
    Тому припустимо, що ви перехоплювати фільми, так що тут ми є
  • 8:46 - 8:51
    зашифровані фільму, які потрібно розшифрувати.
    Так що давайте говорити, що це всі зашифровані так
  • 8:51 - 8:55
    вас не знаю, що там всередині тут.
    Однак, так буває, що тільки тому, що
  • 8:55 - 9:00
    DVD шифрування використовує файли MPEG, так буває, якщо ви знаєте про префікс у
  • 9:00 - 9:04
    звичайний текст, давайте просто сказати, може бути це двадцять байт. Ну, ми знаємо, що якщо ви
  • 9:04 - 9:09
    XOR ці дві речі разом, так само в інших словах, ви робите XOR тут,
  • 9:09 - 9:14
    те, що ви отримаєте це початковий сегмент на PRG. Таким чином, ви отримаєте на
  • 9:14 - 9:18
    перші двадцять байт вихідний CSS, вихід цього PRG. Гаразд, так що тепер
  • 9:18 - 9:24
    Ось що ми будемо робити. Так, у нас є перші двадцять байт виводу. Зараз
  • 9:24 - 9:31
    Ми виконайте такі дії. Ми спробуємо всі двох до сімнадцять можливі значення першого
  • 9:31 - 9:37
    LFSR. Добре? Таким чином, два сімнадцять можливих значень. Так що для кожного значення, так і для
  • 9:37 - 9:43
    кожен з цих двох до сімнадцять початкові значення у LFSR, ми збираємося працювати на
  • 9:43 - 9:48
    LFSR для двадцяти байт, добре? Так що ми будемо генерувати двадцять байт виходи з цієї
  • 9:48 - 9:53
    Перший LFSR, припускаючи, — для кожної з двох сімнадцять можливі параметри.
  • 9:53 - 9:59
    Тепер пам'ятаю, ми маємо повний вихідний CSS системи. Так що ми можемо зробити це ми
  • 9:59 - 10:04
    можна прийняти цей висновок, який ми маємо. Вилучення його з двадцяти укусів і що ми
  • 10:04 - 10:09
    отримав від першого LFSR і якщо насправді наші припущення для початкового стану перший
  • 10:09 - 10:14
    LFSR є правильним, що ми повинні отримати є перші двадцять байтове вихід на
  • 10:14 - 10:19
    Другий LFSR. Право? Тому що, за визначенням, що вихід з CSS
  • 10:19 - 10:25
    система є. Тепер виявляється що дивлячись на 20-байтове послідовність, це дуже легко
  • 10:25 - 10:30
    щоб сказати, чи Ця послідовність 20-байтове прийшли з 25-розрядні LFSR, чи ні. Якщо це
  • 10:30 - 10:34
    не, то ми знаємо, що наші припущення за 17-розрядні LFSR
  • 10:34 - 10:37
    неправильні і потім ми перейдемо до наступного вгадати для LFSR 17-біт і
  • 10:37 - 10:42
    наступний думаю, і так далі і так далі.
    Поки врешті-решт ми потрапили права початковий
  • 10:42 - 10:47
    держави за 17-трохи LFSR і тоді ми будемо реально отримати, ми побачимо, що
  • 10:47 - 10:52
    20 байтів, що ми отримуємо, як кандидат вихід для 25-розрядні LFSR
  • 10:52 - 10:57
    справді можливий вихід для 25-розрядні LFSR. І потім, не тільки буде ми повинні
  • 10:57 - 11:02
    дізнався правильну початковий стан для LFSR 17-біт, ми повинні також
  • 11:02 - 11:08
    дізнався правильну початкового стану 25-розрядні LFSR. І тоді ми можемо передбачити, що
  • 11:08 - 11:13
    залишаючись виходи, CSS і, звичайно, використовуючи, що, ми можемо дешифрувати залишок
  • 11:13 - 11:18
    фільм. Ми насправді можна відновити залишилися звичайний текст. Добре. Це
  • 11:18 - 11:22
    те, що ми говорили раніше. Так, я сказав це трохи швидко, але, сподіваюся,
  • 11:22 - 11:27
    було ясно. Ми також будемо робити домашнє завдання здійснювати на цей тип потоку
  • 11:27 - 11:31
    шифри і ви родом з отримаєте точку як ці атаки алгоритмів
  • 11:31 - 11:36
    роботи. І я повинен згадати, що є багато відкритих вихідних систем тепер, що насправді
  • 11:36 - 11:41
    використовувати цей метод, щоб дешифрувати дані, зашифровані CSS. Гаразд, так що тепер, що ми вже бачили два
  • 11:41 - 11:46
    слабкі прикладів, давайте перейдемо до найкращих прикладів і зокрема тим краще
  • 11:46 - 11:49
    псевдовипадкових генератори приходять від те, що називається eStream проекту. Це є
  • 11:49 - 11:56
    проект, що уклали в 2008 році, і вони право в основному п'ять різних потоку
  • 11:56 - 12:00
    шифри, але тут я хочу представити тільки один. Тому перше всіх параметрів для
  • 12:00 - 12:04
    Ці шифри потоку є трохи інакше, ніж те, що ми звикли. Так, ці
  • 12:04 - 12:08
    потік шифрів, як звичайно, вони мають насіння.
    Але крім цього них, що і в
  • 12:08 - 12:13
    званих даний час і ми побачимо, що даний час використовується для в хвилину. Так
  • 12:13 - 12:17
    вони приймають два входи, насіння і в даний час.
    Ми побачимо, що в даний час використовується для
  • 12:17 - 12:21
    за секунду. І звичайно, вони виробляють дуже великі виводу, так n, ось
  • 12:21 - 12:27
    набагато, набагато, набагато більше, ніж s. Тепер, коли я кажу nonce, що я маю на увазі — це значення, що з
  • 12:27 - 12:31
    ніколи не повторити тих пір, як ключ виправлена. І я поясню, що в більш
  • 12:31 - 12:35
    докладно в за секунду. Але зараз, просто думаю, що це як унікальну значення, ніколи не
  • 12:35 - 12:41
    повторення тих пір, як ключ це те ж саме.
    І тому, звичайно, якщо у вас є цей PRG
  • 12:41 - 12:45
    Ви б зашифрувати, ви отримаєте шифр потоку як і раніше, за винятком зараз як бачите, на
  • 12:45 - 12:50
    PRG приймає як введення ключа і в даний час. І є власність в даний час
  • 12:50 - 12:56
    що пара, k r кома, так ключових кома nonce, що ніколи не — ніколи не повторюється. Він має
  • 12:56 - 13:03
    ніколи не використовуються більше одного разу. Так суть в тому, що можна повторно використовувати ключ, повторне використання
  • 13:03 - 13:10
    ключ, тому що в даний час робить пара унікальний, тому що k і r, лише
  • 13:10 - 13:16
    використовується один раз. Я скажу, що вони унікальні. Добре, так що ця nonce роду милий трюк що
  • 13:16 - 13:22
    рятує нас біда з переїзд в новий ключ кожного разу. Гаразд, так що зокрема
  • 13:22 - 13:26
    приклад з eStream, що я хочу, щоб показати вам, називається сальса двадцять. Це є
  • 13:26 - 13:30
    потік шифр, який призначений для реалізації програмного забезпечення та устаткування
  • 13:30 - 13:33
    реалізацій. Це навіть цікавий.
    Ви розумієте, що деякі потік шифри
  • 13:33 - 13:39
    розроблений для програмного забезпечення, як RC4.
    Все це робить покликана зробити
  • 13:39 - 13:43
    Програмна реалізація працювати швидко, в той час як інші потік шифри призначені для
  • 13:43 - 13:48
    устаткування, як CSS, за допомогою LFSR, які особливо покликаний зробити устаткування
  • 13:48 - 13:51
    реалізацій дуже дешево. Крім того, гарна річ про це є те, що
  • 13:51 - 13:55
    Таким чином, що це, як легко реалізувати його в апаратне та програмне забезпечення
  • 13:55 - 14:00
    Реалізація є також дуже швидко. Отже, дозвольте мені пояснити, як працює сальса. Ну, сальса
  • 14:00 - 14:05
    приймає або 128 або 256 біт ключі. Тільки я поясню 128-бітна версія сальси.
  • 14:05 - 14:11
    Так що це насіння. А потім вона також вимагає даний час, як перед, яка
  • 14:11 - 14:15
    трапляється бути 64 біт. І тоді він буде генерувати великі виводу. Тепер як це робить
  • 14:15 - 14:21
    дійсно працюють? Ну, сама функція визначається наступним чином. В основному, враховуючи
  • 14:21 - 14:26
    ключ і в даний час, він буде генерувати дуже довго, Ну, давно псевдовипадкових
  • 14:26 - 14:31
    послідовність, так довго, як це необхідно. І це зроблю це за допомогою цієї функції, які я будете позначимо
  • 14:31 - 14:36
    H. це функція h бере три входи.
    В основному ключ. Ну, насіння k
  • 14:36 - 14:40
    nonce r а потім лічильник, який збільшує від кроку до кроку. Так само...
  • 14:40 - 14:45
    від нуля до один, два, три, чотири як тривалих як [нечутний] ми, щоб бути. Добре? Тому в основному,
  • 14:45 - 14:50
    на оцінці цього h на цьому k r, але з використанням цього incrementing лічильник, ми можемо отримати на
  • 14:50 - 14:55
    послідовності, що це так довго, як ми хочемо. Так що все, що потрібно зробити, це описати як ця функція
  • 14:55 - 14:59
    H працює. Тепер дозвольте мені зробити це тут для вас.
    Як це працює, виглядає наступним чином. Ну, ми
  • 14:59 - 15:05
    Почніть шляхом розширення Штатів в щось досить великий, який є 64 байт
  • 15:05 - 15:10
    Це давно і ми зробити наступним чином. В основному ми будемо дотримуватися константа на початку, так
  • 15:10 - 15:16
    Існує Тао нуль, ці чотири байт, це чотири байт константа, так специфікації для
  • 15:16 - 15:21
    Сальса в основному надає значення для Тао нуль. Потім ми покласти k, у яких є
  • 15:21 - 15:25
    шістнадцять байт. Потім ми покласти іншу константа. Знову ж таки це чотири байт. І
  • 15:25 - 15:31
    як я вже сказав, специфікації в основному призначення те, що Ця фіксована константа. Потім ми покласти
  • 15:31 - 15:37
    в даний час, який є 8 байт. Потім ми ставимо індексу. Це лічильник нуль,
  • 15:37 - 15:43
    один, два, три, чотири, яка є ще вісім байт. Потім ми покласти іншу константа
  • 15:43 - 15:49
    Тау два, яка є ще чотирьох байтів.
    Потім ми покласти ключ знову, це ще одна
  • 15:49 - 15:55
    шістнадцять байт. І потім, нарешті ми третій постійною, Тау три, яка є
  • 15:55 - 16:00
    інший чотирьох байтів. Добре, так як я вже сказав, якщо ви підсумувати дані, ви бачите, що ви отримаєте 64
  • 16:00 - 16:05
    байт. Тому в основному ми розширювались ключ і в даний час і лічильник на 64
  • 16:05 - 16:11
    байт. В основному ключ повторюється двічі я думаю. І тоді ми робимо ми застосовувати на
  • 16:11 - 16:16
    функція, я буду називати h цей функціональний мало. добре, так що ми застосувати цю функцію, мало h.
  • 16:16 - 16:22
    І це функція, що один до одного, так що це співставляє 64 байт 64 байт. Це є
  • 16:22 - 16:26
    повністю оборотна функції, добре? Тому ця функція h, як я вже сказав, це є
  • 16:26 - 16:30
    invertable функції. Так дано вводу можна отримати на виході і з огляду на
  • 16:30 - 16:35
    Ви можете повернутися до вводу виводу. І призначений спеціально тому вона має на - легко
  • 16:35 - 16:40
    для реалізації в устаткування і b-x-86, це дуже легко реалізувати, тому що
  • 16:40 - 16:44
    x86 має цей SSE2 інструкція встановити, який підтримує всі операції потрібно робити
  • 16:44 - 16:49
    для цієї функції. Це дуже, дуже швидко.
    В результаті, сальса має дуже швидкий потік
  • 16:49 - 16:53
    шифр. І тоді він робить це в основному знову і знову. Так що це відноситься це
  • 16:53 - 16:58
    Функція h знову і він отримує інший 64 байт. І так далі і тому подібне, в основному
  • 16:58 - 17:05
    він робить це в десять разів. Добре, так що все це тут, сказати повторюється в десять разів, так
  • 17:05 - 17:18
    в основному застосовуються h десять разів. А то сам по собі, це насправді не досить випадковий.
  • 17:18 - 17:22
    Це не буде дивитися випадкові, тому що, як ми вже казали, H є повністю invertable. Так, зважаючи
  • 17:22 - 17:26
    Цей кінцевого виводу, це дуже легко, просто Інвертувати h і потім повернутися до оригіналу
  • 17:26 - 17:32
    входи і потім тест, що введення має право структури. Так робити ще одна
  • 17:32 - 17:37
    річ, яка є в основному XOR, входи і виходи остаточний. Фактично,
  • 17:37 - 17:42
    Вибач. Це не є XOR. Це насправді доповненням. Так ви зробити доповнення-слово
  • 17:42 - 17:48
    слово. Так що якщо 64 байт, ви робите слово за словом доповнення чотирьох байтів в на
  • 17:48 - 17:53
    час і, нарешті, ви отримаєте 64-байтове виводу, і все. Це весь
  • 17:53 - 17:57
    генератор псевдовипадкових. Так що, що є функції, мало h. І, як я
  • 17:57 - 18:02
    пояснили, це цілий будівництво тут є функція великих h. І тоді вам оцінити
  • 18:02 - 18:06
    Великий h на збільшує лічильник я з нуля, один, два, три року. І що
  • 18:06 - 18:10
    дасть вам псевдовипадкових послідовності, що це так довго, як це буде потрібно. І
  • 18:10 - 18:15
    в основному, це не signifigant зазнає нападу на це. Це має безпеки що з
  • 18:15 - 18:20
    дуже близько двох до 128. Ми побачимо, що це означає, що більше саме пізніше на.
  • 18:20 - 18:25
    Це дуже швидкий потік шифр, як апаратного і програмного забезпечення. І, наскільки
  • 18:25 - 18:30
    Ми можемо сказати, що це, як видається, непередбачуваний, як це потрібно для потоку шифр. Так я
  • 18:30 - 18:35
    треба сказати, проект eStream насправді має п'ять потік шифри як
  • 18:35 - 18:39
    це. Я тільки вибрав сальса, тому що я думаю, це самий елегантний. Але я можу дати вам
  • 18:39 - 18:44
    деякі продуктивність номери тут. Так що ви можете бачити, це продуктивність чисел на на
  • 18:44 - 18:49
    2.2 Гігагерц, ви знаєте, x86 типа.
    І ви можете бачити, що RC4 фактично на
  • 18:49 - 18:53
    повільний. Тому, що по суті, Ну це не дійсно скористатися на
  • 18:53 - 18:57
    устаткування. Він тільки робить байтів операцій.
    І так багато даремно циклів,
  • 18:57 - 19:01
    не використовується. Але E-потік кандидатів, сальса та інші
  • 19:01 - 19:05
    кандидат називається Sosemanuk. Я повинен сказати, що це eStream фіналістів. Ці
  • 19:05 - 19:10
    власне потік шифрів, які затверджені eStream проекту. Ви можете бачити, що
  • 19:10 - 19:14
    вони досягли значних ставки.
    Це 643 мегабайт за секунду на цьому
  • 19:14 - 19:18
    Архітектура, більш ніж достатньо для фільму і ці насправді просто вражало
  • 19:18 - 19:22
    ставки. І тепер ви бачили приклади двох старі шифрів потоку, що не повинно бути
  • 19:22 - 19:27
    використовуються, включаючи нападів на ці потік шифрів.
    Ви бачили, сучасний ефір шифри
  • 19:27 - 19:30
    схожі з цього nonce. І ви побачите цифри продуктивності для цих
  • 19:30 - 19:35
    сучасний ефір шифрів, так що якщо вам трапиться потрібен шифр потоку ви могли б використовувати один з
  • 19:35 - 19:38
    eStream фіналістів. Зокрема, ви могли б використовувати щось подібне до сальси.
Title:
Real-world stream ciphers (20 min)
Video Language:
English
olezha.onoychenko edited Ukrainian subtitles for Real-world stream ciphers (20 min)
olezha.onoychenko added a translation

Ukrainian subtitles

Revisions