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 има као улаз

00:00:27.818 --> 00:00:32.702
неку вредност променљиве дужине - семе; овде ћемо као пример да узмемо

00:00:32.702 --> 00:00:36.980
128 битова за семе, које се затим користи као кључ за шифру тока.

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
Гугл га на пример користи у свом HTTPS-у. Користи се и у WEP-у који

00:01:11.888 --> 00:01:15.686
смо разматрали у претходном одељку, али ту се користи неправилно

00:01:15.686 --> 00:01:18.861
тако да није нимало безбедан. Током година,

00:01:18.861 --> 00:01:23.886
пронађене су неке слабости у RC4, тако да се препоручује да се у новим пројектима

00:01:23.886 --> 00:01:28.793
не користи, већ да се користи савремени псеудо-случајни генератор који ћемо да

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
случајан, вероватноћа да други бајт буте 0

00:01:49.780 --> 00:01:54.744
била би тачно 1 / 256. Постоји 256 могућих бајтова, тако да вероватноћа

00:01:54.744 --> 00:01:59.646
да буде 0 треба да буде 1 / 256. Испоставља се да је за RC4 ова вероватноћа

00:01:59.646 --> 00:02:04.486
у ствари 2 / 256, што значи да ако користите RC4 да шифрујете

00:02:04.486 --> 00:02:09.574
поруку, постоји извесна вероватноћа да се други бајт уопште не шифрује. Другим речима,

00:02:09.574 --> 00:02:14.575
биће ХОR-ован са 0 са два пута већом вероватноћом него што треба да буде.

00:02:14.575 --> 00:02:19.436
Значи 2 / 256 уместо 1 / 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
постоји мало већа вероватноћа да се добије ових 16 битова (2 бајта) 0, 0, него што би требало.

00:02:58.970 --> 00:03:03.948
Да је RC4 сасвим насумичан, вероватноћа да се појави 00 била би тачно (1 / 256) на 2.

00:03:03.948 --> 00:03:08.556
Испоставља се да је RC4 делимично пристрасан, тако да вероватноћа износи (1 / 256) на 3.

00:03:08.556 --> 00:03:13.718
Ова пристрасност се појављује тек након излаза дужине неколико гигабајта података.

00:03:13.718 --> 00:03:18.634
Ипак, овако нешто може да се користи како би се предвидео генератор

00:03:18.634 --> 00:03:23.120
и свакако може да послужи да би се разликовао излаз генератора

00:03:23.120 --> 00:03:28.097
од истински случајног низа. Та чињеница да се 00 појављује чешће него што би требало

00:03:28.097 --> 00:03:32.414
је показатељ разлике. У последњем одељку већ смо говорили

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
врло слаба шифра тока која се користи код шифровања двд филмова. Када купите

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
шифроване двд-јеве. 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
а њихове вредности се доводе у ХОR,

00:04:54.134 --> 00:04:59.053
а затим се на сваки циклус клока, регистар помера на десно. Последњи бит отпада

00:04:59.053 --> 00:05:04.345
а нови први бит постаје излаз из овог ХОR-а.

00:05:04.345 --> 00:05:08.703
Видите да је ово једноставан механизам за примену, и заузима врло мало транзистора.

00:05:08.703 --> 00:05:13.622
Само померај удесно, последњи бит отпада, а први бит постаје

00:05:13.622 --> 00:05:18.541
ХОR претходних битова. Дакле почетна вредност - семе - код овог регистра је

00:05:18.541 --> 00:05:23.460
заправо његово почетно стање.

00:05:23.650 --> 00:05:28.538
На њему се заснива више шифара тока. Ево и неких примера.

00:05:28.538 --> 00:05:33.362
Рекли смо да двд шифровање користи два оваква регистра. То ћу да вам покажем за који тренутак.

00:05:33.362 --> 00:05:38.060
GSM шифровање садржи два алгоритма, А51 и А52,

00:05:38.060 --> 00:05:43.456
који користе 3 регистра померања. Bluetooth шифровање садржи алгоритам Е0, такође

00:05:43.456 --> 00:05:48.534
шифру тока, са 4 регистра. Испоставља се да су сви они доста слаби,

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
тако да хајде да вам покажем како се изводи овај напад.

00:06:05.459 --> 00:06:11.073
Кључ за CSS је 5-бајтни, тј. 40-битни, 5 х 8 је 40 битова.

00:06:11.073 --> 00:06:15.587
Ограничили су се на 40 битова зато што је двд шифровање развијено

00:06:15.587 --> 00:06:19.941
у време када је прописима извоза из САД био дозвољен само извоз

00:06:19.941 --> 00:06:25.086
алгоритама за шифровање где је кључ само 40 битова. Тако да су пројектанти CSS-а били

00:06:25.086 --> 00:06:30.206
ограничени на јако, јако кратке кључеве. Њихов поступак је следећи:

00:06:30.206 --> 00:06:35.398
користе се два регистра померања, један 17-битни,

00:06:35.398 --> 00:06:40.806
и други 25-битни,

00:06:40.806 --> 00:06:46.647
нешто дужи. Њима се почетна вредност задаје

00:06:46.647 --> 00:06:51.870
на следећи начин. Дакле кључ изгледа овако.

00:06:51.870 --> 00:06:57.669
Почне се са јединицом, која се придодаје на прва два бајта кључа.

00:06:57.669 --> 00:07:02.947
А то је почетно стање регистра померања.

00:07:02.947 --> 00:07:08.256
И другом регистру померања се почетно стање задаје на сличан начин.

00:07:08.256 --> 00:07:14.012
Јединица придружена на последња 3 бајта кључа,

00:07:14.012 --> 00:07:19.889
што се спушта као почетно стање регистра. Можете да видите да су прва два бајта

00:07:19.889 --> 00:07:25.411
- 16 битова, плус почетни, то је укупно 17 битова, а за други регистар померања

00:07:25.411 --> 00:07:31.217
24 бита плус један - то је 25 битова. Примећујете да смо искористили свих 5 битова кључа.

00:07:31.217 --> 00:07:36.881
Затим се ови регистри померања покрећу у осам циклуса, тако да се њима добија

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
да бисмо занемарили бит преноса, мада се он у ствари додаје као 0 или 1 у збир

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
у времену оквирно 2 на 17. Да вам покажем како.

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
што двд шифровање користи MPEG датотеке, ви знате префикс

00:08:59.970 --> 00:09:04.250
отвореног текста, на пример можда је ово 20 бајтова. Дакле знамо да

00:09:04.250 --> 00:09:08.589
ако извршите ХОR ових двеју ствари,

00:09:08.589 --> 00:09:13.523
добијате почетни одељак од PRG-а. Дакле добићете

00:09:13.523 --> 00:09:18.472
првих 20 бајтова излаза из CSS-a.

00:09:18.472 --> 00:09:23.986
Дакле ево шта ћемо да урадимо. Имамо првих 20 бајтова излаза.

00:09:23.986 --> 00:09:31.405
Урадимо сада следеће. Покушамо свих 2 на 17 могућих вредности за први

00:09:31.405 --> 00:09:37.088
регистар померања. Дакле 2 на 17 могућих вредности. За сваку вредност,

00:09:37.088 --> 00:09:42.622
за сваку од ових 2 на 17 почетних вредности регистра, одрадићемо пролазак

00:09:42.622 --> 00:09:47.953
кроз регистар за 20 бајтова. Дакле добијамо 20 бајтова од овог

00:09:47.953 --> 00:09:53.284
првог регистра, за сваки од 2 на 17 могућих почетних вредности.

00:09:53.284 --> 00:09:58.615
Сетите се да имамо пун излаз из CSS-a. Тако да можемо

00:09:58.615 --> 00:10:03.814
да узмемо овај излаз, и да га одузмемо од 20 бајтова

00:10:03.814 --> 00:10:08.928
које смо добили из првог регистра, тако да ако је наш погодак за почетно стање првог регистра

00:10:08.928 --> 00:10:14.042
исправан, оно што добијемо је првих 20 бајтова излаза

00:10:14.042 --> 00:10:19.222
из другог регистра. Зато што је то оно што је по дефиницији излаз из CSS система.

00:10:19.222 --> 00:10:24.501
Испоставља се да је посматрајући 20-бајтни низ, врло лако

00:10:24.501 --> 00:10:29.763
да се закључи да ли је овај 20-бајтни низ потекао од 25-битног регистра померања или не.

00:10:29.763 --> 00:10:33.561
Ако није, онда знамо да је наша претпоставка за 17-битни регистар померања била

00:10:33.561 --> 00:10:37.416
погрешна, и тада прелазимо на следећи покушај за регистар,

00:10:37.416 --> 00:10:41.904
па на следећи, итд. Све док коначно не погодимо право почетно стање

00:10:41.904 --> 00:10:46.937
17-битног регистра померања, а тада заправо добијамо

00:10:46.937 --> 00:10:51.969
да 20 бајтова које смо узели као кандидате за излаз 25-битног регистра

00:10:51.969 --> 00:10:56.936
јесу заиста могући излаз из 25-битног регистра. А тада, не само да смо

00:10:56.936 --> 00:11:02.164
открили право почетно стање за 17-битни регистар, већ смо открили

00:11:02.164 --> 00:11:07.523
и право почетно стање за 25-битни регистар. А тада можемо да предвидимо

00:11:07.523 --> 00:11:12.796
преостале излазе из CSS-a, и наравно, користећи ово, можемо да дешифрујемо остатак филма.

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
бољи псеудо-насумични генератори потичу од такозваног еСтрим пројекта. Ово је пројекат

00:11:49.370 --> 00:11:55.556
који је завршен у 2008-ој, и њиме је квалификовано 5 различитих шифара тока,

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. Под привременом вредношћу подразумевам вредност која

00:12:26.603 --> 00:12:31.218
неће бити поновљена докле год је кључ исти. Ускоро ћу то мало темељније да

00:12:31.218 --> 00:12:35.400
објасним. За сада, само је посматрајте као јединствену вредност која се не

00:12:35.400 --> 00:12:40.527
понавља све док је вредност кључа иста. Једном када имате псеудо-насумични генератор (ПНГ),

00:12:40.527 --> 00:12:45.357
са којим шифрујете, добијате шифру тока као и раније, осим што сада, као што видите,

00:12:45.357 --> 00:12:49.955
ПНГ узима као улазне вредности и кључ и привремену вредност. Уз својство

00:12:49.955 --> 00:12:56.350
да се пар (k, r), дакле (кључ, привремена вредност), никад, никад не понавља.

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
користе само једном. Пар је јединствен. Дакле привремена вредност је згодна досетка

00:13:16.135 --> 00:13:21.541
која нас поштеђује тога да прелазимо на нови кључ сваки пут. Конкретан пример

00:13:21.541 --> 00:13:26.000
из еСтрима који желим да вам покажем је Салса 20.

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, која користи регистар померања нарочито развијен

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. Функција Н има три улаза. Кључ, тј. семе k,

00:14:35.653 --> 00:14:40.498
привремену вредност r, и бројач који се повећава из корака у корак. Дакле иде

00:14:40.498 --> 00:14:45.263
од нуле, до 1, 2, 3, 4, докле год је потребно. Значи,

00:14:45.263 --> 00:14:49.956
одређујући вредност за Н за ове k, r и растући бројач, добијамо

00:14:49.956 --> 00:14:54.882
низ који је оне дужине коју хоћемо. Све што имам да урадим јесте да опишем како функција

00:14:54.882 --> 00:14:59.460
Н ради. Хајде да то и урадимо. Она ради на следећи начин.

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
т0, ово је 4 бајта, 4-бајтна константа,

00:15:15.552 --> 00:15:20.611
Салса вам задаје вредност за т0. Затим стављамо k које је

00:15:20.611 --> 00:15:25.467
16 бајта. Затим ставимо још једну константу. Поново, ово је 4 бајта.

00:15:25.467 --> 00:15:30.795
Као што сам рекао, ова константа има унапред задату вредност. Затим ставимо

00:15:30.795 --> 00:15:37.435
привремену вредност, која је 8 бајта. Затим ставимо индекс - то је бројач - 0,

00:15:37.435 --> 00:15:43.063
1, 2, 3, 4, који заузима још 8 бајта. Затим ставимо још једну константу,

00:15:43.063 --> 00:15:49.056
т2, која заузима још 4 бајта. Затим поново ставимо кључ, ово је додатних

00:15:49.056 --> 00:15:54.714
16 бајтова. Најзад стављамо и трећу константу, т3, која је

00:15:54.714 --> 00:15:59.948
4-бајтна. Као што само рекао, сабравши ово имамо укупно 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
а она је 1-на-1, дакле додељује 64-бајтну вредност за 64-бајтни улаз.

00:16:21.659 --> 00:16:26.005
Она је потпуно иверзибилна. Дакле функција h је

00:16:26.005 --> 00:16:30.260
иверзибилна функција. То значи да за задати улаз добијамо један излаз, и за задати

00:16:30.260 --> 00:16:34.906
излаз добијамо улаз. Развијена је нарочито на такав начин да буде, као прво, лака

00:16:34.906 --> 00:16:39.553
за примену у хардверу, а као друго, на х86 је нарочито лака за примену зато што

00:16:39.553 --> 00:16:44.199
х86 има 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
ово се одради 10 пута. Дакле све ово овде се понавља 10 пута,

00:17:05.318 --> 00:17:17.961
дакле применити h 10 пута. Само по себи, ово и није тако насумично.

00:17:17.961 --> 00:17:22.144
Неће да изгледа насумично зато што, као што сам рекао, H је потпуно иреверзибилна.

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 бајта, сабирамо реч по реч, 4 бајта

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
Као што сам објаснио, цела ова конструкција овде јесте функција Н. Она се рачуна

00:18:01.758 --> 00:18:06.009
тако што се бројач i повећава од 0 на 1, 2, 3 итд.

00:18:06.009 --> 00:18:10.408
То вам даје псеудо-насумични низ који је оне дужине која вам треба.

00:18:10.408 --> 00:18:15.325
Не постоје значајни напади на ово. Безбедност овог система је

00:18:15.325 --> 00:18:20.371
јако близу 2 на 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
Треба да напоменем да пројекат еСтрим има 5 шифара тока попут

00:18:34.797 --> 00:18:39.395
ове. Одабрао сам Салсу зато што ми делује најелегантније. Али могу да вам дам

00:18:39.395 --> 00:18:44.053
неке вредности перформанси. Овде можете да видите вредности перформанси за

00:18:44.053 --> 00:18:48.768
машину типа х86, на 2.2 гигахерца. И можете да видите да је 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
Али кандидати еСтрима, како Салса тако и овај

00:19:01.182 --> 00:19:05.202
други кандидат, Сосеманук (треба рећи да су ово еСтрим финалисти,

00:19:05.202 --> 00:19:09.588
шифре тока које је одобрио еСтрим пројекат), као што видите

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
са привременом вредношћу. И видите вредности перформански за ове

00:19:30.480 --> 00:19:34.546
савремене шифре тока, тако да ако вам буде била потребна шифра тока, можете да користите неку

00:19:34.546 --> 00:19:37.991
од финалиста еСтрима, на пример Салсу.