Здравствуйте, TheBeginner, Вы писали:
TB>Есть вот такой код отсюда: https://cr.yp.to/chacha.html TB>Можно и как правильно его подружить с ключами скажем 40, 56, 64, 80, 96, 160, 192 бит TB>Лучше конечно чтобы ключи были произвольной длины и не кратные u32, но и чтоб товарищу майору не стыдно было показать в случае чего
Есть только 1 (одна) причина использовать криптографический алгоритм с меньшей длиной ключа: скорость работы.
Если товарищ майор хочет ключ 58 бит, чтобы кому положено могли его взломать, то это делается следующим образом:
1. берется ключ 58 бит
2. расширяется специальным алгоритмом до 256 бит
3. профит
Расширенный ключ, несмотря на свою длину, будет иметь всё ту же взломостойкость в 58 бит.
in excess of 56 bits of symmetric key length, or equivalent
?
Криптографический ключ физической длины 56 бит имеющий 56 бит энтропии можно рассматривать, как эквивалент криптографического ключа имеющего те же 56 бит энтропии, но имеющего другой физический размер.
Вот еще ссылка на RFC TLS 1.0. Тут описывается набор используемых шифров и применяемые параметры. Немного прокрутив спеку можно найти таблицу, где перечислены: шифры, количество энтропии в ключе, фактический размер ключа и его эффективный размер. У экспортных шифров количество энтропии меньше фактического размера ключа.
Здравствуйте, TheBeginner, Вы писали:
TB>Когда я говорю, что ключ есть, это естественно подразумевает что на вход ECRYPT_keysetup в качестве ключа подается тот же sha256. Не пользовательский пароль же TB>Вопрос повторяю в другом — как лучше переписать ECRYPT_keysetup для любых kbits < 256
vopl тебе дело говорит. Но если непонятно, то лучше никак. Криптография — такая штука, что очень легко насвистеть, причем пока не сломают, этого особо и не видно.
Здравствуйте, TheBeginner, Вы писали:
vsb>>Чача по определению спроектирована для ключей 128 или 256 длины. Если ты что-то в алгоритме поменяешь, это уже будет не чача, а твой производный алгоритм, про криптостойкость которого никто ничего не знает.
TB>Возможно это и так. Интересно что будет если "добрать" до 256 открытыми байтами.
Ну, если у тебя хватит квалификации это всерьез разобрать, на эту тему можно дисертацию написать. А если нет, лучше не пробовать.
Здравствуйте, Pzz, Вы писали:
Pzz>Ну, если у тебя хватит квалификации это всерьез разобрать, на эту тему можно дисертацию написать. А если нет, лучше не пробовать.
Здравствуйте, TheBeginner, Вы писали:
TB>Что "Нет"? Я как бы в курсе криптостойкости DES, но
Никаких "но". Его использовать давно уже тупо нельзя.
TB> если у нас лимит в 56 бит
Откуда взялся этот лимит?
CC>>Ключи давно уже принято генерить через KDF TB>OK. Я правильно понимаю — берем некий пользовательский ключ полученный например с помощью sha256
Вай какой бардак у тебя в теории. Но сначала давай разберёмся откуда вообще появился лимит в 56 бит.
TB>обрезаем его до 56 бит
Шта? Вот с этого места поподробнее. Зачем тебе в принципе обрезать?
Короткий ключ это дырища сама по себе, 128 не просто так поддерживаемый минимум.
56бит нынче тупо перебирается.
TB>радуемся что используем шифрование не больше чем 56 бит.
Если у тебя такой короткий ключ то надо не радоваться а паниковать.
Здравствуйте, CreatorCray, Вы писали:
TB>>Что "Нет"? Я как бы в курсе криптостойкости DES, но CC>Никаких "но". Его использовать давно уже тупо нельзя. TB>> если у нас лимит в 56 бит CC>Откуда взялся этот лимит? TB>>обрезаем его до 56 бит CC>Шта? Вот с этого места поподробнее. Зачем тебе в принципе обрезать?
Дело в экспортных ограничениях, которые одинаковы по длине ключа для США, России и других стран.
Вот для США:
A “symmetric algorithm” employing a key length in excess of 56-bits is controlled in Category 5, Part 2. Therefore, items with a key length of 56 bits or less are not in 5A002.a.
Если производитель ПО и пользователь находятся в одной стране — вопросов нет. А вот если распространять через стор или даже просто раздавать бесплатную фривару могут постучаться к вам или хостинг провайдеру.
Для сторов даже специальные требования и форма есть.
rudzuk привел пример с Касперским:
Комплект поставки содержит следующие дистрибутивы:
Strong encryption (AES256)
Дистрибутив содержит криптографические средства, реализующие криптографический алгоритм AES (Advanced Encryption Standard) с эффективной длиной ключа 256 бит.
Lite encryption (AES56)
Дистрибутив содержит криптографические средства, реализующие криптографический алгоритм AES с эффективной длиной ключа 56 бит.
Причем не важно, является ли криптография основной функцией приложения или нет.
CC>>>Ключи давно уже принято генерить через KDF TB>>OK. Я правильно понимаю — берем некий пользовательский ключ полученный например с помощью sha256 CC>Вай какой бардак у тебя в теории. Но сначала давай разберёмся откуда вообще появился лимит в 56 бит.
Я просто пытаюсь объяснить, что ключ в виде криптографического хеша уже есть и его длина соответствует максимальной длине ключа который поддерживает криптоалгоритм обозначенный в начале топика (ChaCha20) — 256 бит.
А это вот такой ответ с иронией (если не понятно) решить обозначенную проблему просто использовав некую kdf.
Вопрос в реализации эффективной длины ключа заданной размерности для алгоритмов, имеющих минимальную длину ключа больше требуемой нам.
То есть в данном случае получаем ключ, имеющий эффективную длину ключа 56 бит, но имеющий физический размер 256 бит.
И вот тут есть еще один маленький вопросик и два варианта как это реализовать:
1 вариант — не изменять исходный код функции задания ключа в условном AES256 и передавать ей 256 битный ключ, но имеющий эффективную длину 56 бит и дополненный нулевыми битами.
2 вариант — модифицировать функцию задания ключа в алгоритме шифрования так, чтобы на вход подавался 56 битный ключ, а внутри функции обнулять лишнее, так скажем.
Почему это может быть важно — могут попросить исходники. У той же NSA (АНБ) есть форма или email для сабмита исходников если будет нужна проверка в BIS (ссылка выше). В России аналогичная процедура в лице ФСБ.
И тут может быть небольшая проблемка при первом варианте — нужно доказать, что вы уменьшаете эффективную длину ключа где то за пределами функции задания ключа.
Если у кого есть подобный опыт или ссылки найдете интересно будет почитать.
Здравствуйте, TheBeginner, Вы писали:
TB>Дело в экспортных ограничениях, которые одинаковы по длине ключа для США, России и других стран.
Ну т.е. задача вообще не криптографическая.
TB>Я просто пытаюсь объяснить, что ключ в виде криптографического хеша уже есть и его длина соответствует максимальной длине ключа который поддерживает криптоалгоритм обозначенный в начале топика (ChaCha20) — 256 бит.
Изначальное объяснение было довольно мутным. Сейчас хотя бы понятно нафига это всё.
TB>А это вот такой ответ с иронией (если не понятно) решить обозначенную проблему просто использовав некую kdf.
Ну например PKCS #5 PBKDF2 (https://www.rfc-editor.org/rfc/rfc8018#page-23) позволяет тебе сказать какой длины ты хочешь получить ключ на выходе в байтах
TB>Вопрос в реализации эффективной длины ключа заданной размерности для алгоритмов, имеющих минимальную длину ключа больше требуемой нам. TB>rudzuk утверждает, что стандартной практикой для этого является обнуление битов за пределами требуемой длины ключа
Тут вопрос поставлен несколько неверно. Тебе надо покоцать длину ключа, это совсем другая задача нежели правильное использование алгоритма, где скармливается всегда ключ нужной длиный, как правило выхлоп какого нить KDF.
Зануление тут должно подойти. Ключом является собственно секрет, т.е. то, что не известно. Занулённая часть всегда известна, потому секретом не является.
TB>И вот тут есть еще один маленький вопросик и два варианта как это реализовать: TB>1 вариант — не изменять исходный код функции задания ключа в условном AES256 и передавать ей 256 битный ключ, но имеющий эффективную длину 56 бит и дополненный нулевыми битами. TB>2 вариант — модифицировать функцию задания ключа в алгоритме шифрования так, чтобы на вход подавался 56 битный ключ, а внутри функции обнулять лишнее, так скажем.
№1 сильно проще и удобнее в реализации (грубо говоря меняется всего лишь аргумент в KDF, ну и хвост добивается нулями если надо)
Если хочется заморочиться то №2, тогда точно нельзя будет сказать что можно обойти ограничение просто забив код зануления nop-ами если там просто отсутствует код чтения части ключа из памяти.
TB>И тут может быть небольшая проблемка при первом варианте — нужно доказать, что вы уменьшаете эффективную длину ключа где то за пределами функции задания ключа.
Эта проблема аналогична доказательству того, что в коде нет другой функции задания ключа, которая таких ограничений не имеет.
Здравствуйте, TheBeginner, Вы писали:
TB> И тут может быть небольшая проблемка при первом варианте — нужно доказать, что вы уменьшаете эффективную длину ключа где то за пределами функции задания ключа.
Разве же это проблема? Перед передачей ключа условному AES256 вставить код обнуления хвостовых 200 бит
Здравствуйте, rudzuk, Вы писали:
R>Разве же это проблема? Перед передачей ключа условному AES256 вставить код обнуления хвостовых 200 бит
Это не техническая проблема а вопрос соблюдения ритуальных приседаний для выполнения условий регулятора.
Здравствуйте, rudzuk, Вы писали:
R>Разве же это проблема? Перед передачей ключа условному AES256 вставить код обнуления хвостовых 200 бит
Возможно и так.
На самом деле это целый квест. Это что получается — чтобы разместить приложение с шифрованием в любом сторе надо подать заявку в BIS, получить CCATS и выделенного куратора из АНБ
Причем не понятно как это все соотносится с криптостойкостью.
Вот старая статья: https://www.zetetic.net/blog/2009/8/3/mass-market-encryption-ccats-commodity-classification-for-ip.html
Интересно конечно было бы почитать как сейчас это все выглядит на практике.
Вот кстати еще один технический вопрос — как требования к максимальной длине ключа (56 бит например) соотносятся c IV (вектором инициализации). Или вся эта нормативная база застряла на уровне DES?
Здравствуйте, TheBeginner, Вы писали:
TB> Вот кстати еще один технический вопрос — как требования к максимальной длине ключа (56 бит например) соотносятся c IV (вектором инициализации). Или вся эта нормативная база застряла на уровне DES?
Здравствуйте, rudzuk, Вы писали:
R>Здравствуйте, TheBeginner, Вы писали:
TB>> Вот кстати еще один технический вопрос — как требования к максимальной длине ключа (56 бит например) соотносятся c IV (вектором инициализации). Или вся эта нормативная база застряла на уровне DES?
R>Вектор инициализации не является секретом.
Но устойчивость то к взлому повышается, а ведь именно это их и интересует. Тем более распространенной практикой является использовать изменяемый криптографический хеш для формирования IV.
И этот IV скрыт и формируется допустим на основе внутренних состояний переменных на стороне шифровки и расшифровки с помощью криптографической хеш функции?
Здравствуйте, TheBeginner, Вы писали:
TB> R>Вектор инициализации не является секретом.
TB> Но устойчивость то к взлому повышается, а ведь именно это их и интересует. Тем более распространенной практикой является использовать изменяемый криптографический хеш для формирования IV.
Она повышается только если для взлома будут использованы методы криптоанализа. Но при коротком ключе никто не будет заниматься криптоанализом, будут тупо брутить. Ну а брутфорсу, что есть IV, что нет (если он не секретен), немного дополнительных операций и только.
TB> И этот IV скрыт и формируется допустим на основе внутренних состояний переменных на стороне шифровки и расшифровки с помощью криптографической хеш функции?
Если алгоритм формирования IV и отправные точки известены, он опять же не является секретом.
Здравствуйте, rudzuk, Вы писали:
TB>> И этот IV скрыт и формируется допустим на основе внутренних состояний переменных на стороне шифровки и расшифровки с помощью криптографической хеш функции? R>Если алгоритм формирования IV и отправные точки известены, он опять же не является секретом.
Вот. То есть в таком случае не достаточно поделиться криптоалгоритмом, а надо предоставить информации о приложении гораздо больше.
И еще вот что — можно ли менять так просто эффективную длину ключа для любого криптоалгоритма просто обнуляя лишние биты, в том смысле, что задавая IV мы фактически увеличим эффективную длину ключа?
Я в криптографии дилетант, но если взять этот код с ChaCha20:
typedef struct
{ u32 input[16]; /* could be compressed */
} ECRYPT_ctx;
Внутреннее состояние (input) массив из 16 u32. Сам ключ сохраняется по индексам 4-11 (для 128 битного ключа просто копируется еще раз по индексам 8-11), константы — 0-3, а IV — 12-15 (ECRYPT_ivsetup)
И всё это вместе похоже и есть некий ключ. То есть вероятно эффективная длина ключа больше (из за задания IV) даже если обнулить ключ за пределами 56 битов.
Здравствуйте, TheBeginner, Вы писали:
TB> R>Если алгоритм формирования IV и отправные точки известены, он опять же не является секретом.
TB> Вот. То есть в таком случае не достаточно поделиться криптоалгоритмом, а надо предоставить информации о приложении гораздо больше.
Ну да. Полагаю, необходимо предоставлять всю схему шифрования.
TB> И еще вот что — можно ли менять так просто эффективную длину ключа для любого криптоалгоритма просто обнуляя лишние биты, в том смысле, что задавая IV мы фактически увеличим эффективную длину ключа?
Она увеличится только при секретном IV, который, в этом случае, можно рассматривать, как часть ключа. Вообще, IV применяют для рандомизации внутреннего состояния шифра при использовании одного ключа с разными потоками данных. Если ключ всегда разный, то IV можно не использовать.