Відповіді:
CRC прекрасно працює для виявлення випадкових помилок у даних, які можуть виникнути, наприклад, від перешкод мережі, шуму в лінії, спотворень тощо.
CRC обчислювально набагато менш складний, ніж MD5 або SHA1. Використання хеш-функції на зразок MD5, ймовірно, є надмірним для виявлення випадкових помилок. Однак використання CRC для будь-якого виду перевірки безпеки було б набагато менш безпечним, ніж більш складна функція хешування, наприклад MD5.
І так, CRC набагато простіше реалізувати на вбудованому обладнання, ви навіть можете отримати різні упаковані рішення для цього в ІС.
MD5, SHA-1також слід уникати, рекомендується якийсь варіант SHA-2.
CRC розроблений проти ненавмисних змін у даних. Тобто це добре для виявлення ненавмисних помилок, але буде марним, як спосіб переконатися, що дані не були зловмисно оброблені.
Побачте і це .
Я знайшов дослідження, яке показує, наскільки невідповідні хеші CRC для хеш-таблиць . Це також пояснює фактичні характеристики алгоритму. Дослідження також включає оцінку інших хеш-алгоритмів і є хорошим посиланням.
Відповідний висновок щодо CRC для хешей:
CRC32 ніколи не призначався для використання хеш-таблиці. Дійсно немає вагомих причин використовувати його для цієї мети, і я рекомендую вам уникати цього. Якщо ви вирішили використовувати CRC32, важливо використовувати хеш-біти з кінця, протилежного тому, в якому подаються ключові октети. З якого боку це залежить, залежить від конкретної реалізації CRC32. Не трактуйте CRC32 як хеш-функцію "чорної скриньки" і не використовуйте її як хеш загального призначення. Обов’язково перевіряйте кожну програму на придатність.
ОНОВЛЕННЯ
Здається, сайт вниз. В інтернет-архіві є копія .
Я провів кожен рядок цього коду PHP у циклі 1.000.000. Результати - у коментарях (#).
hash('crc32', 'The quick brown fox jumped over the lazy dog.');# 750ms 8 chars
hash('crc32b','The quick brown fox jumped over the lazy dog.');# 700ms 8 chars
hash('md5', 'The quick brown fox jumped over the lazy dog.');# 770ms 32 chars
hash('sha1', 'The quick brown fox jumped over the lazy dog.');# 880ms 40 chars
hash('sha256','The quick brown fox jumped over the lazy dog.');# 1490ms 64 chars
hash('sha384','The quick brown fox jumped over the lazy dog.');# 1830ms 96 chars
hash('sha512','The quick brown fox jumped over the lazy dog.');# 1870ms 128 chars
Мій висновок:
Використовуйте "sha256" (або вище), коли вам потрібен додатковий рівень захисту.
Не використовуйте "md5" або "sha1", оскільки вони мають:
"The quick brown fox jumped over the lazy dog." ), ви побачите, наскільки швидше CRC, ніж MD5.
Інформацію про CRC щодо впровадження, швидкості та надійності див . Безболісний посібник з алгоритмів виявлення помилок CRC . У CRC є все.
Якщо хтось не намагатиметься змінити ваші дані зловмисно і приховати зміни CRC, достатньо. Просто використовуйте «Добрий» (стандартний) поліном.
Все залежить від ваших вимог та очікувань.
Ось короткі короткі відмінності між цими алгоритмами хеш-функцій :
- алгоритм криптографічного хешу,
створює 160-бітове (20-байтне) хеш-значення, відоме як дайджест повідомлень
це криптографічний хеш, і з 2005 року це вже не вважається захищеним,
може використовуватися для шифрування,
вперше опублікований у 1993 р. (як SHA-0), потім 1995 як SHA-1,
серія: SHA-0, SHA-1, SHA-2, SHA-3,
Підсумовуючи це, використання SHA-1 вже не вважається захищеним від добре фінансованих супротивників, оскільки в 2005 році криптоаналітики виявили напади на SHA-1, що говорить про те, що воно може бути недостатньо безпечним для постійного використання шнайера . Американський NIST радить, що федеральні органи повинні припинити використовувати SHA1-1 для застосувань, які потребують стійкості до зіткнення, і повинні використовувати SHA-2 після 2010 року NIST .
Тому, якщо ви шукаєте просте і швидке рішення для перевірки цілісності файлів (проти пошкодження) або для деяких простих цілей кешування з точки зору продуктивності, ви можете розглянути CRC-32, для хешування ви можете розглянути можливість використання MD5, однак якщо ви розробляєте професійний додаток (який повинен бути безпечним і послідовним), щоб уникнути будь-яких імовірностей зіткнення - використовуйте SHA-2 і вище (наприклад, SHA-3).
Деякі прості тестові показники в PHP:
# Testing static text.
$ time php -r 'for ($i=0;$i<1000000;$i++) crc32("foo");'
real 0m0.845s
user 0m0.830s
sys 0m0.008s
$ time php -r 'for ($i=0;$i<1000000;$i++) md5("foo");'
real 0m1.103s
user 0m1.089s
sys 0m0.009s
$ time php -r 'for ($i=0;$i<1000000;$i++) sha1("foo");'
real 0m1.132s
user 0m1.116s
sys 0m0.010s
# Testing random number.
$ time php -r 'for ($i=0;$i<1000000;$i++) crc32(rand(0,$i));'
real 0m1.754s
user 0m1.735s
sys 0m0.012s\
$ time php -r 'for ($i=0;$i<1000000;$i++) md5(rand(0,$i));'
real 0m2.065s
user 0m2.042s
sys 0m0.015s
$ time php -r 'for ($i=0;$i<1000000;$i++) sha1(rand(0,$i));'
real 0m2.050s
user 0m2.021s
sys 0m0.015s
Пов'язані:
Ви не говорите, що це таке, що ви намагаєтесь захистити.
CRC часто використовується у вбудованих системах як перевірка проти випадкових пошкоджень даних на відміну від запобігання зміні зловмисної системи. Приклади місць, де CRC може бути корисним, - це перевірка зображення EPROM під час ініціалізації системи для захисту від пошкодження програмного забезпечення. Завантажувач системи буде обчислювати CRC для коду програми та порівнювати зі збереженим значенням, перш ніж дозволити запуск коду. Це захищає від можливості випадкової пошкодження програми або невдалого завантаження.
CRC також може бути використаний аналогічним чином для захисту даних конфігурації, що зберігаються в FLASH або EEPROM. Якщо CRC невірний, то дані можуть бути позначені як недійсні та використати набір даних за замовчуванням або резервне копіювання. CRC може бути недійсним через збій пристрою або якщо користувач відключив живлення під час оновлення сховища даних конфігурації.
Повідомлялося, що хеш забезпечує більшу ймовірність виявлення корупції, ніж CRC з декількома помилками бітів. Це дійсно так, і рішення про те, використовувати чи не використовувати 16 чи 32-бітову CRC, залежатиме від наслідків безпеки використовуваного пошкодженого блоку даних та чи можна виправдати шанс 1 на 2 ^ 16 або 2 ^ 32 блок даних невірно оголошений дійсним
Багато пристроїв мають вбудований генератор CRC для стандартних алгоритмів. Серія MSP430F5X від Техасу має технічну реалізацію стандарту CRC-CCITT.
Використовуйте CRC лише в тому випадку, якщо ресурси для обчислень дуже обмежені (тобто деякі вбудовані середовища) або вам потрібно зберігати / транспортувати багато вихідних значень і простір / пропускна здатність є тісним (оскільки CRC зазвичай 32-бітний, коли вихід MD5 128-розрядний, SHA1 160 біт та інші варіанти SHA до 512 біт).
Ніколи не використовуйте CRC для перевірки безпеки, оскільки CRC дуже легко "підробити".
Навіть для виявлення випадкових помилок (а не виявлення зловмисних змін) хеші краще, ніж прості CRC. Частково через простий спосіб обчислення CRC (а почасти тому, що значення CRC зазвичай коротші, ніж загальні хешові виходи, тому мають набагато менший діапазон можливих значень), набагато ймовірніше, що в ситуації, коли є дві або більше помилок , одна помилка замаскує іншу, тож ви отримаєте ту саму CRC, незважаючи на дві помилки.
Якщо коротко: якщо у вас немає підстав не використовувати гідний алгоритм хешу, уникайте простих CRC.
Нещодавно я натрапив на використання CRC, який був розумним. Автор інструменту ідентифікації та видалення дублювання файлів jdupe (той же автор популярного інструменту exif jhead) використовує його під час першого проходження файлів. CRC обчислюється на перших 32K кожного файлу для позначення файлів, які здаються однаковими, також файли повинні мати однаковий розмір. Ці файли додаються до списку файлів, за якими можна виконати повне бінарне порівняння. Це прискорює перевірку великих медіафайлів.
Почнемо з основ.
У криптографії алгоритм хешування перетворює багато біт на меншу кількість біт за допомогою дайджесту. Хеші використовуються для підтвердження цілісності повідомлень і файлів.
Усі алгоритми хешування генерують зіткнення. Зіткнення - це коли декілька багатобітних комбінацій дають однаковий менший вихід бітів. Сила криптографічного алгоритму хешування визначається нездатністю індивіда визначити, який буде вихід для даного вводу, оскільки, якби вони могли, вони могли б сконструювати файл із хешем, який відповідає легальному файлу, та скомпрометувати передбачувану цілісність системи. Різниця між CRC32 та MD5 полягає в тому, що MD5 генерує більший хеш, що важче передбачити.
Коли ви хочете реалізувати цілісність повідомлення - це означає, що повідомлення не було підроблене під час транзиту, - неможливість передбачити зіткнення є важливою властивістю. 32-бітний хеш може описати 4 мільярди різних повідомлень або файлів , використовуючи 4 мільярди різних унікальних хешів. Якщо у вас 4 мільярди та 1 файл, ви гарантовано матимете зіткнення. 1 TB Bitspace має можливість зіткнення мільярдів. Якщо я зловмисник і можу передбачити, який буде 32-бітний хеш, я можу побудувати заражений файл, що стикається з цільовим файлом; що має той же хеш.
Крім того, якщо я роблю передачу в 10 Мбіт / с, тоді можливість пошкодження пакету прямо в обхід crc32 і продовження по пункту призначення та виконання дуже низька. Скажімо, в 10 Мбіт / с я отримую 10 помилок \ секунду . Якщо я розширював це до 1 Гбіт / с, тепер я отримую 1000 помилок в секунду . Якщо я прошиваю до 1 ексебіт в секунду, то у мене частота помилок 1 000 000 000 помилок в секунду . Скажімо, у нас зіткнення 1 \ 1 000 000Помилки передачі. Значення 1 на мільйон помилок передачі призводить до пошкодження даних, що потрапляють через невиявлені. У 10 Мбіт / с я отримую дані про помилки, що надсилаються кожні 100 000 секунд або приблизно один раз на день. При 1gbps це трапляється раз на 5 хвилин. З 1 швидкістю в секунду ми говоримо кілька разів на секунду.
Якщо ви відкриєте Wireshark, ви побачите, що у типовому заголовку Ethernet є CRC32, у вашому заголовку IP є CRC32, а у заголовку TCP - CRC32, і це додатково до того, що можуть робити протоколи вищого рівня; наприклад, IPSEC може використовувати MD5 або SHA для перевірки цілісності на додаток до вищезазначеного. Існує кілька шарів перевірки помилок у типових мережевих комунікаціях, і вони РОЗПОВІДАЮТЬсь знову і знову на низькій швидкості 10 Мбіт / с.
Циклічна перевірка надмірності (CRC) має кілька поширених версій і декілька нечастостей, але, як правило, розроблена так, щоб просто повідомити, коли повідомлення або файл пошкоджено під час транзиту (кілька бітів гортаючи). CRC32 сам по собі не дуже хороший протокол перевірки помилок за сучасними стандартами у великих, скалярних корпоративних середовищах через швидкість зіткнення; середній жорсткий диск користувачів може мати понад 100 тис. файлів, а спільний доступ до файлів у компанії може становити десятки мільйонів. Відношення хеш-простору до кількості файлів є занадто низьким. CRC32 обчислювально дешево реалізувати, тоді як MD5 - це не так.
MD5 був розроблений, щоб зупинити навмисне використання зіткнень, щоб шкідливий файл виглядав доброякісним. Це вважається небезпечним, оскільки хеш-простір був достатньо відображений для того, щоб дозволити деякі атаки, а деякі зіткнення передбачувані. SHA1 і SHA2 - це нові діти на блоці.
Для перевірки файлів Md5 починає використовуватися багатьма постачальниками, тому що ви можете швидко робити з ним багатогабайтні файли або мультитербайтні файли, а також укладати їх над загальним використанням ОС та підтримкою CRC32. Не дивуйтеся, якщо протягом наступного десятиліття файлові системи почнуть використовувати MD5 для перевірки помилок.