Watch videos with subtitles in your language, upload your videos, create your own subtitles! Click here to learn more on "how to Dotsub"

Hashing Algorithms and Security - Computerphile

0 (0 Likes / 0 Dislikes)
Припустимо, ви хочете перемістити файл із одного компьютера на інший. І вам дійсно важливо знати, що він прийшов туди цілісний та непошкоджений. Ви можете надіслати його декілька разів та потім порівняти всі надіслані файли між собою. Але зазвичай використовується дещо, що називається алгоритмом хешування. Алгоритм хешування - це щось на кшталт контрольної цифри на штрих-коді кредитної картки. Здається, Джеймс Грайм розповідав про це давно на каналі Numberphile. Остання цифра штрих-коду кредитної картки визначається всіма іншими його цифрами. Тож, якщо ви зміните хоча б одну цифру у штрих-коді кредитної картки, то остання цифра також зміниться. Таким чином, якщо ви заносите цей номер у компьютер, то ви точно знаєте, чи правильний він, чи ні. Алгоритм хешування - це щось подібне, але для всього файлу, розмір якого може вимірюватися мега- або навіть гігабайтами. На виході він дає код. 16, 32 або 64 символів, в загальному випадку у шістнадцятковій системі числення. По суті, це лише одне довге число, представлене у такому вигляді. Це є ніби резюме всього того, що є у файлі. Якщо ви будете "згортати" цей файл велику кількість разів, то в результаті отримаєте цей код, який і буде цим "резюме". Ви ніколи не зможете зробити зворотній процес, тобто отримати з цього коду вміст файлу. Це щось на кшталт підпису, це підтвердження того, що цей файл є дійсно тим, за що його видають. Найпростіший алгоритм хешування, який я можу придумати - це просто скласти всі числа в тому файлі. Це буде 4... 9... 13... 23. Це не гарний алгоритм хешування з декількох причин У алгоритмів хешування є 3 основних вимоги Перше - це швидіксть. Він повинен бути дійсно швидким та бути спроможним опрацювати великий файл за секунду або максимум дві. Проте він не повинен бути і занадто швидким Якщо він дуже швидкий, то його легко зламати - я поясню це пізніше. Друга вимога - це, якщо ви зміните хоча б один байт, навіть біт будь-де у файлі: на початку, всередині або в кінці тоді весь хеш-код має бути повністю іншим. Це називається лавинний ефект. Якщо ви зацікавлені в тому, як цього досягнути, зануртесь глибше у самі алгоритми - це займе десь годину у мене, щоб пояснити як це працює зрозумілою мовою ;) Якщо вам це дійсно цікаво, почитайте. Проте варто наголосити ще раз, що якщо ви зміните хоча б один біт будь-де у повідомленні, то все повідомлення повністю зміниться. Третя вимога - вам потрібно уникати того, що називається колізії. Це така ситуація, коли у вас є два абсолютно різні файли з однаковим хешем Є такий принцип у математиці, який називається принцип Діріхле. Якщо у вас є 50 пінгвінів та 25 клітин, ви матимете посадити як мінімум у одну з них 2 пінгвіни. Це жахлива аналогія, але я спробую пояснити Нехай є велика кількість файлів (з точки зору алгоритму хешування - це лише дуже довге число). І з усіх цих файлів знайдуться ті, які, природньо, матимуть один і той самий хеш. І це нормально, бо ймовірність того, що таке станеться за звичних умов дуже мала - це не буде правилом - тож ми можемо обробити таку ситуацію, адже природньо такого ніколи не станеться. Але якщо ви можете штучно створити колізію, наприклад створити файл та змінити його ім'я та отримати колізію то, Хьюстон, у нас проблеми. І в цей момент на сцену виходить безпека, бо якщо я можу створити файл, якому відповідає конкретний хеш тоді я просто можу підміняти файли, слати одні замість інших, при тому що їх "підписи" співпадатимуть. Припустимо, у мене є важливий документ - не знаю, нехай дозвіл на політ на Місяць Так, дозвіл на політ на місяць - саме так! І на ньому є чиєсь ім'я Цей файл шлеться через захищений канал разом із хешем, який дозволяє перевірити, що це дійсно те, що нам потрібно. Припустимо, я можу перехопити цей файл та змінити його Оскільки алгоритм хешування несправний, я можу зробити це. Я можу змінити ім'я, дату, ще щось так, щоб хеш-код залишився незмінним і відправити на Місяць когось іншого! Бо я можу залишити хеш-код незмінним, просто акуратно міняючи байти Проте це неймовірно важко зробити. На практиці вам потрібно бути багато файлів та ще більше коду. Але, існують старі алгоритми хешування, (як-то md5, що використовувався багато-багато років) у яких зараз виникають ці колізії при повсякденному використанні і які вважаються зламаними. Причина в тому, що ви можете взяти файл (не текстовий, а наприклад файл з компьютерним кодом або чимось таким) та, змінивши щось у цьому файлі зі зловмисними намірами, отримати той самий хеш, який мав оригінальний. Це дуже важливо, це той момент, де потрібно говорити про швидкість хешування Якщо алгоритм дуже повільний, то ніхто не захоче його використовувати Але, якщо він занадто швидкий, такий, що ви можете згенерувати декілька хеш-кодів за пару циклів процесора тоді ви дуже просто зможете згенерувати файл, чий хеш співпадає з хешем конкретного файлу Це дуже схоже на гонку озброєнь Як я сказав, md5 був багато років визнаним алгоритмом і він досі використовується для деяких речей Проте md5 зараз повністю зламаний, бо компьютери зараз досить швидкі та є декілька трюків, які ви можете використати, щоб навмисно створити колізії Ця проблема виникла, тому що md5 використовувася дуже широко. Він використовувався повсюди в Інтернеті. Google став винятковим ресурсом для зламу md5 хеш-кодів Не потрібно використовувати md5 для зберігання паролів! Я розповім про це у подальших відео. Але люди так і робили багато років і з неясних причин він зберігався разом з своїм md5 хешем. Якщо ви введете цей хеш у Google, дуже часто у відповідь ви отримаєте те слово, яке він шифрує. Це означає що всі англійські слова та, крім того, й інші паролі можуть бути зламані просто за допомогою введення їх md5-хешкодів у Google. Таким чином md5 всебічно та абсолютно точно зламаний Тоді спільнота перешла на алгоритм, який називається SHA1. І ходять чутки, що він дуже скоро може також "зламатися", бо компьютери стають швидшими. тобто колізії стає легше згенерувати. Тому ми переходимо на SHA2, який наразі є безпечнішим. SHA3 наразі проходить процес ратифікації усіма агенціями. І через декілька років, він стане стандартом. Зрештою, я хочу ще раз наголосити - не використовуйте їх для збереження паролів - я розповім про це у наступних відео. Вони використовуються для перевірки файлів, для перевірки передачі данних - вони повинні використовуватися лише для цього І остання річ, яку я хочу розповісти. Напевно, ви бачили сайти для завантажень програмного забезпечення які кажуть: "Ось ваш файл, який ми вам перешлемо. Ось посилання на завантаження. І якщо ви хочете бути убезпеченим, ось вам хеш-код файлу, щоб ви змогли перевірити, що цей саме той файл, який вам потрібно". Це дуже погана ідея. Я маю на увазі... Так, він дійсно перевірить ваш файл на цілісність та неушкодженість, але вони продають це як: "Ось вам ключ, ви можете перевірити файл і ми гарантуємо, що при співпадінні хешів, ви отримали правильний файл". І це погана ідея, бо якщо хтось зміг продертися на їх сайт та змінити програмне забезпечення, що надсилається то дуже просто змінити і хеш до того файлу. Тож, це і є алгоритми хешування: ми беремо великий обсяг даних та перетворюємо на малий, щоб верифікувати його. І в подальших відео я розкажу як він використовується та як не повинен використовуватися, щоб тримати дані у безпеці.

Video Details

Duration: 8 minutes and 11 seconds
Country: United States
Language: English
Genre: None
Views: 456
Posted by: dkalpakchi on Mar 5, 2015

Video from http://www.youtube.com/watch?v=b4b8ktEV4Bg

Caption and Translate

    Sign In/Register for Dotsub to translate this video.