Comments 2
«алгоритм Skein уступил в финале SHA-3 более быстрому и менее уязвимому Keccak» — это очень голословное утверждение, так как Keccak был одним из самых медленных среди всех конкурсантов, а Skein быстрым, причём как на «больших» компьютерах, так и на встраиваемых процессорах. www.skein-hash.info/sha3-engineering eprint.iacr.org/2010/531.pdf. Как и утверждение про «уязвимость» Keccak vs Skein, мягко говоря, очень спорное (на чём основано?). Среди требований к SHA3 было и то, что хэш наоборот не должен быть слишком быстрым, что возможно было одной из причин «проигрыша» Skein. По анализам www.researchgate.net/publication/235677375_Security_Margin_Evaluation_of_SHA-3_Contest_Finalists_through_SAT-Based_Attacks вообще Skein имеет самый высокий порог безопасности, тогда как Keccak плетётся в конце финалистов SHA3. BLAKE считается имеет очень большой «запас прочности» и в BLAKE2 даже снижали его, ради производительности (BLAKE2 поэтому в целом очень и очень популярен во множестве задач, ибо быстрее MD5, при этом всё равно имея высочайшую безопасность).
«Изначально созданные для повышения эффективности цифровых подписей» — вообще криптографические хэш функции появились задолго даже до протокола Диффи-Хельмана, не говоря про асимметричные подписи: crypto.stackexchange.com/questions/56404/what-was-the-first-hash-and-what-problem-was-it-supposed-to-solve
«что показало наличие уязвимостей в алгоритмах и ставило под сомнение безопасность электронной цифровой подписи на основе данных хеш-функций» — тоже очень громкое утверждение. Проблемы с коллизиями есть у SHA1. Потенциально могут быть в теории у SHA2, который имеет схожую конструкцию. Это не значит что они есть, не значит что конструкция сама по себе плоха, не значит что SHA2 уязвим/сломан, поэтому на данный момент, даже когда создают какие-то системы с нуля (например Git переводят с SHA1), то всё равно продолжают с чистой совестью выбирать SHA2, так как SHA3 даже по производительности не покажет ощутимые плюсы и его выбор мало даст очевидных и осязаемых преимуществ. Никто от SHA2 не избавляется и не считает его уязвимым. А смысл перехода на SHA3 у многих вызывает скепсис.
«Изначально созданные для повышения эффективности цифровых подписей» — вообще криптографические хэш функции появились задолго даже до протокола Диффи-Хельмана, не говоря про асимметричные подписи: crypto.stackexchange.com/questions/56404/what-was-the-first-hash-and-what-problem-was-it-supposed-to-solve
«что показало наличие уязвимостей в алгоритмах и ставило под сомнение безопасность электронной цифровой подписи на основе данных хеш-функций» — тоже очень громкое утверждение. Проблемы с коллизиями есть у SHA1. Потенциально могут быть в теории у SHA2, который имеет схожую конструкцию. Это не значит что они есть, не значит что конструкция сама по себе плоха, не значит что SHA2 уязвим/сломан, поэтому на данный момент, даже когда создают какие-то системы с нуля (например Git переводят с SHA1), то всё равно продолжают с чистой совестью выбирать SHA2, так как SHA3 даже по производительности не покажет ощутимые плюсы и его выбор мало даст очевидных и осязаемых преимуществ. Никто от SHA2 не избавляется и не считает его уязвимым. А смысл перехода на SHA3 у многих вызывает скепсис.
«В конце хотелось бы упомянуть области применения хеш-функции Skein...» — упомянута только часть применений описанных в Skein reference whitepaper. Tree-hashing очень полезная штука, имеющаяся и в BLAKE(2?), помогающая распараллеливать вычисления хэша, в BLAKE3 вообще сразу из коробки работающая для «больших» сообщений. Skein из коробки имеет возможности для задания randomized hashing и personalization. Кроме PRNG Skein может безопасно использоваться и для симметричного шифрования. Всё это штатно предлагается и описывается к применению авторами Skein.
Sign up to leave a comment.
Знакомство со Skein