Хешування

Строго в один бік: довільний вхід — вихід фіксованого розміру; 1 TB чи 100 TB на вході, 20 байтів на виході, і, як жартує Віктор, «це не архівація»: дані назад не дістанеш. Відео-таксономія (різниця між хешуванням, кодуванням і шифруванням) розкладає хеш-функції на його три родини за призначенням: контрольні суми (MD5, SHA-1 — git використовує SHA-1), криптографічне хешування паролів (scrypt/bcrypt — саме так паролі насправді й зберігають, тож навіть атакувальник із повною базою та конфігами не зможе їх відновити) та хеші для хеш-таблиць (MurmurHash), створені заради швидкості й розподілу, а не безпеки. Ця односторонність — його відповідь на ще одне питання з підступом: паролі в базі не «зашифровані», а захешовані — там нема чого розшифровувати.

Канал подає хешування як міст між безпекою і структурами даних. У відео про те, навіщо алгоритми JS-івські Map-и та об'єкти виявляються хеш-таблицями з пошуком за O(1) у середньому — саме це перетворює злиття за O(n·m) на O(n+m). У випуску про фільтр Блума і Firefox він занурюється в серйозні деталі реалізації: фільтру Блума потрібні швидкі та рівномірно розподілені хеші (наївна сума кодів символів ніколи не дотягнеться до дальнього кінця масиву з 10 млн бітів), тож він бере xxHash і перевірений трюк подвійного хешування — порахувати один 64-бітний хеш, розділити його на h1/h2 і вивести k хешів як h1 + i·h2; згадує і ланцюжки колізій у хеш-таблицях, і стару вразливість Python з атакою через хеш-колізії. З криптографічного боку підписи обчислюються над хешем документа (цифрові підписи), а IV у шифруванні порівняно із сіллю пароля, що ламає райдужні таблиці.