Подружить ChaCha20 с ключами разной длины
От: TheBeginner  
Дата: 14.01.24 07:08
Оценка:
Есть вот такой код отсюда: https://cr.yp.to/chacha.html
Можно и как правильно его подружить с ключами скажем 40, 56, 64, 80, 96, 160, 192 бит
Лучше конечно чтобы ключи были произвольной длины и не кратные u32, но и чтоб товарищу майору не стыдно было показать в случае чего

typedef struct
{
    u32 input[16]; /* could be compressed */
    /*
     * [edit]
     *
     * Put here all state variable needed during the encryption process.
     */
} ECRYPT_ctx;

static const char sigma[16] = "expand 32-byte k";
static const char tau[16] = "expand 16-byte k";

void ECRYPT_keysetup(ECRYPT_ctx *x,const u8 *k,u32 kbits,u32 ivbits)
{
  const char *constants;

  x->input[4] = U8TO32_LITTLE(k + 0);
  x->input[5] = U8TO32_LITTLE(k + 4);
  x->input[6] = U8TO32_LITTLE(k + 8);
  x->input[7] = U8TO32_LITTLE(k + 12);
  if (kbits == 256) { /* recommended */
    k += 16;
    constants = sigma;
  } else { /* kbits == 128 */
    constants = tau;
  }
  x->input[8] = U8TO32_LITTLE(k + 0);
  x->input[9] = U8TO32_LITTLE(k + 4);
  x->input[10] = U8TO32_LITTLE(k + 8);
  x->input[11] = U8TO32_LITTLE(k + 12);
  x->input[0] = U8TO32_LITTLE(constants + 0);
  x->input[1] = U8TO32_LITTLE(constants + 4);
  x->input[2] = U8TO32_LITTLE(constants + 8);
  x->input[3] = U8TO32_LITTLE(constants + 12);
}
Отредактировано 14.01.2024 7:44 TheBeginner . Предыдущая версия .
Re: Подружить ChaCha20 с ключами разной длины
От: vopl Россия  
Дата: 14.01.24 10:06
Оценка: +1
Здравствуйте, TheBeginner, Вы писали:

TB>Лучше конечно чтобы ключи были произвольной длины и не кратные u32, но и чтоб товарищу майору не стыдно было показать в случае чего


Смотри в сторону KDF (Key derivation function, гуглится легко). Это как раз инструмент для того чтобы взять некий секретный материал — пароль, мастер-ключ, или в твоем случае, некий "ключ произвольной длины", и из него сформировать такой ключ который подойдет для дальнейшего использования в алгоритме — будет правильной длины и прочее.. Я пользовался HKDF-SHA256, а так же blake3 в спец-режиме KDF, вполне приятно.
Re[2]: Подружить ChaCha20 с ключами разной длины
От: TheBeginner  
Дата: 14.01.24 10:55
Оценка:
Здравствуйте, vopl, Вы писали:

V>Смотри в сторону KDF (Key derivation function, гуглится легко). Это как раз инструмент для того чтобы взять некий секретный материал — пароль, мастер-ключ, или в твоем случае, некий "ключ произвольной длины", и из него сформировать такой ключ который подойдет для дальнейшего использования в алгоритме — будет правильной длины и прочее.. Я пользовался HKDF-SHA256, а так же blake3 в спец-режиме KDF, вполне приятно.


Вопрос не в этом. ключ есть, но в этой ECRYPT_keysetup хотя есть параметр kbits, но все ключи != 256 длиной считаются == 128.
Хотелось бы иметь возможность задать ключ произвольной длины, причем не кратный sizeof(u32).

https://cr.yp.to/streamciphers/timings/estreambench/submissions/salsa20/chacha8/ref/chacha.c

typedef struct
{
    u32 input[16]; /* could be compressed */
    /*
     * [edit]
     *
     * Put here all state variable needed during the encryption process.
     */
} ECRYPT_ctx;

static const char sigma[16] = "expand 32-byte k";
static const char tau[16] = "expand 16-byte k";

void ECRYPT_keysetup(ECRYPT_ctx *x,const u8 *k,u32 kbits,u32 ivbits)
{
  const char *constants;

  x->input[4] = U8TO32_LITTLE(k + 0);
  x->input[5] = U8TO32_LITTLE(k + 4);
  x->input[6] = U8TO32_LITTLE(k + 8);
  x->input[7] = U8TO32_LITTLE(k + 12);
  if (kbits == 256) { /* recommended */
    k += 16;
    constants = sigma;
  } else { /* kbits == 128 */
    constants = tau;
  }
  x->input[8] = U8TO32_LITTLE(k + 0);
  x->input[9] = U8TO32_LITTLE(k + 4);
  x->input[10] = U8TO32_LITTLE(k + 8);
  x->input[11] = U8TO32_LITTLE(k + 12);
  x->input[0] = U8TO32_LITTLE(constants + 0);
  x->input[1] = U8TO32_LITTLE(constants + 4);
  x->input[2] = U8TO32_LITTLE(constants + 8);
  x->input[3] = U8TO32_LITTLE(constants + 12);
}
Re[3]: Подружить ChaCha20 с ключами разной длины
От: vopl Россия  
Дата: 14.01.24 11:24
Оценка:
Здравствуйте, TheBeginner, Вы писали:

TB>Здравствуйте, vopl, Вы писали:


V>>Смотри в сторону KDF (Key derivation function, гуглится легко). Это как раз инструмент для того чтобы взять некий секретный материал — пароль, мастер-ключ, или в твоем случае, некий "ключ произвольной длины", и из него сформировать такой ключ который подойдет для дальнейшего использования в алгоритме — будет правильной длины и прочее.. Я пользовался HKDF-SHA256, а так же blake3 в спец-режиме KDF, вполне приятно.


TB>Вопрос не в этом. ключ есть, но в этой ECRYPT_keysetup хотя есть параметр kbits, но все ключи != 256 длиной считаются == 128.

TB>Хотелось бы иметь возможность задать ключ произвольной длины, причем не кратный sizeof(u32).

Почитай внимательно что такое KDF, это именно то что тебе нужно. Следующим образом:
У тебя есть некий ключ, размер которого не является оптимальным для ChaCha. Если его использовать наивно, то алгоритм отбросит часть ключа (возьмет только сладщие 128 бит), что видится неправильным, так как часть секрета не будет использоваться, то есть мощность как бы упадет. Чтобы не терять мощность ключа и запихнуть всю его энтропию в алгоритм — можно воспользоваться KDF. KDF это такой инструмент который может взять твой исходный ключ с плохими тактико-техническими характеристиками (вариабельная длина) и перепаковать всю его энтропию в заранее оговоренную длину (256 бит). Таким образом, ChaCha получит переработаный с помощью KDF ключ оптимального размера и в нем будет вся энтропия из оригинального ключа без потерь.
Re[3]: Подружить ChaCha20 с ключами разной длины
От: vsb Казахстан  
Дата: 14.01.24 11:48
Оценка: +1
Здравствуйте, TheBeginner, Вы писали:

TB>Вопрос не в этом. ключ есть, но в этой ECRYPT_keysetup хотя есть параметр kbits, но все ключи != 256 длиной считаются == 128.

TB>Хотелось бы иметь возможность задать ключ произвольной длины, причем не кратный sizeof(u32).

Чача по определению спроектирована для ключей 128 или 256 длины. Если ты что-то в алгоритме поменяешь, это уже будет не чача, а твой производный алгоритм, про криптостойкость которого никто ничего не знает. Если тебе просто надо поменять длину входного ключа, про KDF тебе уже сказали.
Re[4]: Подружить ChaCha20 с ключами разной длины
От: TheBeginner  
Дата: 14.01.24 12:06
Оценка:
Здравствуйте, vopl, Вы писали:

V>Почитай внимательно что такое KDF, это именно то что тебе нужно. Следующим образом:

V>У тебя есть некий ключ, размер которого не является оптимальным для ChaCha. Если его использовать наивно, то алгоритм отбросит часть ключа (возьмет только сладщие 128 бит), что видится неправильным, так как часть секрета не будет использоваться, то есть мощность как бы упадет. Чтобы не терять мощность ключа и запихнуть всю его энтропию в алгоритм — можно воспользоваться KDF. KDF это такой инструмент который может взять твой исходный ключ с плохими тактико-техническими характеристиками (вариабельная длина) и перепаковать всю его энтропию в заранее оговоренную длину (256 бит). Таким образом, ChaCha получит переработаный с помощью KDF ключ оптимального размера и в нем будет вся энтропия из оригинального ключа без потерь.

Когда я говорю, что ключ есть, это естественно подразумевает что на вход ECRYPT_keysetup в качестве ключа подается тот же sha256. Не пользовательский пароль же
Вопрос повторяю в другом — как лучше переписать ECRYPT_keysetup для любых kbits < 256
Re[4]: Подружить ChaCha20 с ключами разной длины
От: TheBeginner  
Дата: 14.01.24 12:19
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Чача по определению спроектирована для ключей 128 или 256 длины. Если ты что-то в алгоритме поменяешь, это уже будет не чача, а твой производный алгоритм, про криптостойкость которого никто ничего не знает.


Возможно это и так. Интересно что будет если "добрать" до 256 открытыми байтами.
Re[5]: Подружить ChaCha20 с ключами разной длины
От: CreatorCray  
Дата: 14.01.24 20:12
Оценка:
Здравствуйте, TheBeginner, Вы писали:

TB>Возможно это и так. Интересно что будет если "добрать" до 256 открытыми байтами.

Мда. С таким уровнем теоретической подготовки лучше не трогать криптографию — сделаешь только хуже
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Re[6]: Подружить ChaCha20 с ключами разной длины
От: TheBeginner  
Дата: 15.01.24 06:14
Оценка:
Здравствуйте, CreatorCray, Вы писали:

TB>>Возможно это и так. Интересно что будет если "добрать" до 256 открытыми байтами.

CC>Мда. С таким уровнем теоретической подготовки лучше не трогать криптографию — сделаешь только хуже

Да вопрос то теоретический больше. Конечно, если есть ограничение по длине ключа скажем 56 бит то лучше просто взять DES (В Америке как и в России как понимаю такие же правила к экспортному контролю, даже для бесплатной фривары https://www.bis.doc.gov/index.php/policy-guidance/encryption?)

В этой реализации при kbits == 128 ключ копируется при инициализации input. Какие еще варианты могут быть чтобы сказать, что ключ формально отвечает заданной разрядности. Подмешивать известные байты в input, что то еще. Повторяю — вопрос теоретический.
И если вы знаете алгоритм шифрования эквивалентный стойкости с AES и желательно выше по скорости при софтверной реализации при одинаковой длине ключа, но позволяющий задавать ключи произвольной длины — напишите.
Я профессионально криптографией не занимаюсь, мне просто интересно

void ECRYPT_keysetup(ECRYPT_ctx *x,const u8 *k,u32 kbits,u32 ivbits)
{
  const char *constants;

  x->input[4] = U8TO32_LITTLE(k + 0);
  x->input[5] = U8TO32_LITTLE(k + 4);
  x->input[6] = U8TO32_LITTLE(k + 8);
  x->input[7] = U8TO32_LITTLE(k + 12);
  if (kbits == 256) { /* recommended */
    k += 16;
    constants = sigma;
  } else { /* kbits == 128 */
    constants = tau;
  }
  x->input[8] = U8TO32_LITTLE(k + 0);
  x->input[9] = U8TO32_LITTLE(k + 4);
  x->input[10] = U8TO32_LITTLE(k + 8);
  x->input[11] = U8TO32_LITTLE(k + 12);
  x->input[0] = U8TO32_LITTLE(constants + 0);
  x->input[1] = U8TO32_LITTLE(constants + 4);
  x->input[2] = U8TO32_LITTLE(constants + 8);
  x->input[3] = U8TO32_LITTLE(constants + 12);
}
Отредактировано 15.01.2024 6:16 TheBeginner . Предыдущая версия .
Re[7]: Подружить ChaCha20 с ключами разной длины
От: rudzuk  
Дата: 15.01.24 07:31
Оценка: +1
Здравствуйте, TheBeginner, Вы писали:

TB> И если вы знаете алгоритм шифрования эквивалентный стойкости с AES и желательно выше по скорости при софтверной реализации при одинаковой длине ключа, но позволяющий задавать ключи произвольной длины — напишите.


RC6
avalon/3.0.2
Re[7]: Подружить ChaCha20 с ключами разной длины
От: SkyDance Земля  
Дата: 15.01.24 07:34
Оценка: +1
TB>void ECRYPT_keysetup(ECRYPT_ctx *x,const u8 *k,u32 kbits,u32 ivbits)

Как верно заметил CreatorCray, если не до конца понимаешь используемую математику, лучше не работай с низкоуровневыми примитивами. Возьми более-менее дуракоустойчивый nacl/libsodium, там как раз есть и KDF, и chacha20 в конкретном сценарии.
Re[7]: Подружить ChaCha20 с ключами разной длины
От: CreatorCray  
Дата: 15.01.24 09:38
Оценка:
Здравствуйте, TheBeginner, Вы писали:

TB>лучше просто взять DES

Нет.

TB>И если вы знаете алгоритм шифрования эквивалентный стойкости с AES и желательно выше по скорости при софтверной реализации при одинаковой длине ключа

Дюд, у тебя ОЧЕНЬ сильно не хватает теории. Просто катастрофически.
Любой совет, который тебе тут дадут у тебя есть риск банально не понять правильно и потому накосячить банально от непонимания.

А косяки в криптографии, утворенные без понимания как оно вообще правильно должно работать, это сейфовая дверь вставленная в дырявый прогнивший забор — иллюзия надёжности.
Почитай хотя бы Bruce Schneier: Applied Cryptography.

TB> но позволяющий задавать ключи произвольной длины — напишите.

Ключи давно уже принято генерить через KDF
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Re[8]: Подружить ChaCha20 с ключами разной длины
От: TheBeginner  
Дата: 15.01.24 10:47
Оценка:
Здравствуйте, CreatorCray, Вы писали:

TB>>лучше просто взять DES

CC>Нет.

Что "Нет"? Я как бы в курсе криптостойкости DES, но если у нас лимит в 56 бит, придётся опять лепить велосипед с неопределенной криптостойкостью потому, что ни один современный криптоалгоритм не реализован для такой длины ключа. Для того же семейства RC ключ должен быть кратен 32 битам и не реализован для ключей меньше 128 бит.

CC>Ключи давно уже принято генерить через KDF

OK. Я правильно понимаю — берем некий пользовательский ключ полученный например с помощью sha256, обрезаем его до 56 бит, потом применяем некую KDF, получаем требуемую для алгоритма шифрования размерность (например 256), задаем это в функция шифрования AES256 и радуемся что используем шифрование не больше чем 56 бит.
Отредактировано 15.01.2024 11:37 TheBeginner . Предыдущая версия . Еще …
Отредактировано 15.01.2024 11:32 TheBeginner . Предыдущая версия .
Re[9]: Подружить ChaCha20 с ключами разной длины
От: rudzuk  
Дата: 15.01.24 11:23
Оценка: 3 (1) +1
Здравствуйте, TheBeginner, Вы писали:

TB> Я как бы в курсе криптостойкости DES, но если у нас лимит в 56 бит, придётся опять лепить велосипед с неопределенной криптостойкостью потому, что ни один современный криптоалгоритм не реализован для такой длины ключа.


Если нужно ограничить криптостойкость 56 битами, достаточно брать от ключа только 56 бит, а остальные обнулять.

TB> Для того же семейства RC ключ должен быть кратен 32 битам и не реализован для ключей меньше 128 бит.


Не должен. На вход подается ключевая последовательность от 0 до 2040 бит над которой работает функция растяжения ключа для формирования внутренних таблиц. Алгоритм параметризуется под конкретные нужды. То, что по дефолту выбраны значения 128, 192, 256 всего лишь условность.
avalon/3.0.2
Re[10]: Подружить ChaCha20 с ключами разной длины
От: TheBeginner  
Дата: 15.01.24 11:52
Оценка:
Здравствуйте, rudzuk, Вы писали:

R>Если нужно ограничить криптостойкость 56 битами, достаточно брать от ключа только 56 бит, а остальные обнулять.


Ну вот — то, что я и говорил выше. Добирать до длины ключа известными байтами, в данном случае нулевыми

TB>> Для того же семейства RC ключ должен быть кратен 32 битам и не реализован для ключей меньше 128 бит.


R>Не должен. На вход подается ключевая последовательность от 0 до 2040 бит над которой работает функция растяжения ключа для формирования внутренних таблиц. Алгоритм параметризуется под конкретные нужды. То, что по дефолту выбраны значения 128, 192, 256 всего лишь условность.


Спасибо, посмотрю как там все реализовано. Интересно, а формально в таком случае можно говорить, что стойкость реализуемого шифрования не больше заданного?
Вы сталкивались с такими задачами?
Re[9]: Подружить ChaCha20 с ключами разной длины
От: rudzuk  
Дата: 15.01.24 11:52
Оценка: +1
Здравствуйте, TheBeginner, Вы писали:

TB> CC>Ключи давно уже принято генерить через KDF


TB> OK. Я правильно понимаю — берем некий пользовательский ключ полученный например с помощью sha256, обрезаем его до 56 бит, потом применяем некую KDF, получаем требуемую для алгоритма шифрования размерность (например 256), задаем это в функция шифрования AES256 и радуемся что используем шифрование не больше чем 56 бит.


Берем пользовательский ключ. От него с помощью KDF получаем PRK (pseudo random key) требуемого размера (128, 192, 256 etc). Обнуляем биты PRK за пределами требуемой стойкости. Все.
avalon/3.0.2
Re[10]: Подружить ChaCha20 с ключами разной длины
От: TheBeginner  
Дата: 15.01.24 11:56
Оценка:
Здравствуйте, rudzuk, Вы писали:

R>Здравствуйте, TheBeginner, Вы писали:


TB>> CC>Ключи давно уже принято генерить через KDF


TB>> OK. Я правильно понимаю — берем некий пользовательский ключ полученный например с помощью sha256, обрезаем его до 56 бит, потом применяем некую KDF, получаем требуемую для алгоритма шифрования размерность (например 256), задаем это в функция шифрования AES256 и радуемся что используем шифрование не больше чем 56 бит.


R>Берем пользовательский ключ. От него с помощью KDF получаем PRK (pseudo random key) требуемого размера (128, 192, 256 etc). Обнуляем биты PRK за пределами требуемой стойкости. Все.

Я понял вашу идею. Там в ответе крэю ирония если что
Re[11]: Подружить ChaCha20 с ключами разной длины
От: rudzuk  
Дата: 15.01.24 11:59
Оценка: 3 (1)
Здравствуйте, TheBeginner, Вы писали:

TB> Интересно, а формально в таком случае можно говорить, что стойкость реализуемого шифрования не больше заданного?


Да. стойкость определяется именно секретностью используемого ключа.

TB> Вы сталкивались с такими задачами?


Ослаблять криптографию мне не приходилось, но читал, что МС именно так и делали (обнуляли часть ключа) для удовлетворения требований регуляторов. Поищу ссылку.
avalon/3.0.2
Re[11]: Подружить ChaCha20 с ключами разной длины
От: rudzuk  
Дата: 15.01.24 13:02
Оценка:
Здравствуйте, TheBeginner, Вы писали:

r> Ослаблять криптографию мне не приходилось, но читал, что МС именно так и делали (обнуляли часть ключа) для удовлетворения требований регуляторов. Поищу ссылку.


Про МС не нашел, но нашел про Касперского. (Вопрос. Описание на сайте Касперского).

Strong encryption (AES256)

Дистрибутив содержит криптографические средства, реализующие криптографический алгоритм AES (Advanced Encryption Standard) с эффективной длиной ключа 256 бит.
Lite encryption (AES56)

Дистрибутив содержит криптографические средства, реализующие криптографический алгоритм AES с эффективной длиной ключа 56 бит.

avalon/3.0.2
Re[12]: Подружить ChaCha20 с ключами разной длины
От: TheBeginner  
Дата: 15.01.24 13:31
Оценка:
Здравствуйте, rudzuk, Вы писали:

R> Дистрибутив содержит криптографические средства, реализующие криптографический алгоритм AES с эффективной длиной ключа 56 бит.


По первой ссылке предположения конечно насчет заполнения нулями, но судя по всему так оно и есть. Если это так, насколько это соотносится с требованиями,
например американскими: https://www.bis.doc.gov/index.php/policy-guidance/encryption/2-items-in-cat-5-part-2/a-5a002-a-and-5d002-c-1/ii-key-length
Re: Подружить ChaCha20 с ключами разной длины
От: scf  
Дата: 15.01.24 13:38
Оценка:
Здравствуйте, 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 бит.
Re[13]: Подружить ChaCha20 с ключами разной длины
От: rudzuk  
Дата: 15.01.24 14:21
Оценка:
Здравствуйте, TheBeginner, Вы писали:

TB> По первой ссылке предположения конечно насчет заполнения нулями, но судя по всему так оно и есть. Если это так, насколько это соотносится с требованиями,

TB> например американскими: https://www.bis.doc.gov/index.php/policy-guidance/encryption/2-items-in-cat-5-part-2/a-5a002-a-and-5d002-c-1/ii-key-length

Речь об этом:

in excess of 56 bits of symmetric key length, or equivalent

?

Криптографический ключ физической длины 56 бит имеющий 56 бит энтропии можно рассматривать, как эквивалент криптографического ключа имеющего те же 56 бит энтропии, но имеющего другой физический размер.
avalon/3.0.2
Re[14]: Подружить ChaCha20 с ключами разной длины
От: rudzuk  
Дата: 15.01.24 15:07
Оценка: 3 (1)
Вот еще ссылка на RFC TLS 1.0. Тут описывается набор используемых шифров и применяемые параметры. Немного прокрутив спеку можно найти таблицу, где перечислены: шифры, количество энтропии в ключе, фактический размер ключа и его эффективный размер. У экспортных шифров количество энтропии меньше фактического размера ключа.
avalon/3.0.2
Re[5]: Подружить ChaCha20 с ключами разной длины
От: Pzz Россия https://github.com/alexpevzner
Дата: 15.01.24 17:02
Оценка:
Здравствуйте, TheBeginner, Вы писали:

TB>Когда я говорю, что ключ есть, это естественно подразумевает что на вход ECRYPT_keysetup в качестве ключа подается тот же sha256. Не пользовательский пароль же

TB>Вопрос повторяю в другом — как лучше переписать ECRYPT_keysetup для любых kbits < 256

vopl тебе дело говорит. Но если непонятно, то лучше никак. Криптография — такая штука, что очень легко насвистеть, причем пока не сломают, этого особо и не видно.
Re[5]: Подружить ChaCha20 с ключами разной длины
От: Pzz Россия https://github.com/alexpevzner
Дата: 15.01.24 17:10
Оценка:
Здравствуйте, TheBeginner, Вы писали:

vsb>>Чача по определению спроектирована для ключей 128 или 256 длины. Если ты что-то в алгоритме поменяешь, это уже будет не чача, а твой производный алгоритм, про криптостойкость которого никто ничего не знает.


TB>Возможно это и так. Интересно что будет если "добрать" до 256 открытыми байтами.


Ну, если у тебя хватит квалификации это всерьез разобрать, на эту тему можно дисертацию написать. А если нет, лучше не пробовать.
Re[6]: Подружить ChaCha20 с ключами разной длины
От: TheBeginner  
Дата: 15.01.24 17:22
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Ну, если у тебя хватит квалификации это всерьез разобрать, на эту тему можно дисертацию написать. А если нет, лучше не пробовать.


Ну вроде разобрались:

http://rsdn.org/forum/cpp.applied/8668562.1
Автор: rudzuk
Дата: 15.01 14:59
Re[9]: Подружить ChaCha20 с ключами разной длины
От: CreatorCray  
Дата: 15.01.24 19:24
Оценка:
Здравствуйте, TheBeginner, Вы писали:

TB>Что "Нет"? Я как бы в курсе криптостойкости DES, но

Никаких "но". Его использовать давно уже тупо нельзя.

TB> если у нас лимит в 56 бит

Откуда взялся этот лимит?

CC>>Ключи давно уже принято генерить через KDF

TB>OK. Я правильно понимаю — берем некий пользовательский ключ полученный например с помощью sha256
Вай какой бардак у тебя в теории. Но сначала давай разберёмся откуда вообще появился лимит в 56 бит.

TB>обрезаем его до 56 бит

Шта? Вот с этого места поподробнее. Зачем тебе в принципе обрезать?
Короткий ключ это дырища сама по себе, 128 не просто так поддерживаемый минимум.
56бит нынче тупо перебирается.

TB>радуемся что используем шифрование не больше чем 56 бит.

Если у тебя такой короткий ключ то надо не радоваться а паниковать.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Re[10]: Подружить ChaCha20 с ключами разной длины
От: TheBeginner  
Дата: 16.01.24 06:38
Оценка:
Здравствуйте, 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.


https://www.bis.doc.gov/index.php/policy-guidance/encryption/2-items-in-cat-5-part-2/a-5a002-a-and-5d002-c-1/ii-key-length

Если производитель ПО и пользователь находятся в одной стране — вопросов нет. А вот если распространять через стор или даже просто раздавать бесплатную фривару могут постучаться к вам или хостинг провайдеру.
Для сторов даже специальные требования и форма есть.

rudzuk привел пример с Касперским:

Комплект поставки содержит следующие дистрибутивы:

Strong encryption (AES256)
Дистрибутив содержит криптографические средства, реализующие криптографический алгоритм AES (Advanced Encryption Standard) с эффективной длиной ключа 256 бит.

Lite encryption (AES56)
Дистрибутив содержит криптографические средства, реализующие криптографический алгоритм AES с эффективной длиной ключа 56 бит.


https://support.kaspersky.com/KESWin/11.9.0/ru-RU/127970.htm

Причем не важно, является ли криптография основной функцией приложения или нет.

CC>>>Ключи давно уже принято генерить через KDF

TB>>OK. Я правильно понимаю — берем некий пользовательский ключ полученный например с помощью sha256
CC>Вай какой бардак у тебя в теории. Но сначала давай разберёмся откуда вообще появился лимит в 56 бит.

Я просто пытаюсь объяснить, что ключ в виде криптографического хеша уже есть и его длина соответствует максимальной длине ключа который поддерживает криптоалгоритм обозначенный в начале топика (ChaCha20) — 256 бит.
А это вот такой ответ с иронией (если не понятно) решить обозначенную проблему просто использовав некую kdf.
Вопрос в реализации эффективной длины ключа заданной размерности для алгоритмов, имеющих минимальную длину ключа больше требуемой нам.

rudzuk утверждает, что стандартной практикой для этого является обнуление битов за пределами требуемой длины ключа
https://rsdn.org/forum/cpp.applied/8668534.1
Автор: rudzuk
Дата: 15.01 14:23


То есть в данном случае получаем ключ, имеющий эффективную длину ключа 56 бит, но имеющий физический размер 256 бит.

И вот тут есть еще один маленький вопросик и два варианта как это реализовать:

1 вариант — не изменять исходный код функции задания ключа в условном AES256 и передавать ей 256 битный ключ, но имеющий эффективную длину 56 бит и дополненный нулевыми битами.
2 вариант — модифицировать функцию задания ключа в алгоритме шифрования так, чтобы на вход подавался 56 битный ключ, а внутри функции обнулять лишнее, так скажем.

Почему это может быть важно — могут попросить исходники. У той же NSA (АНБ) есть форма или email для сабмита исходников если будет нужна проверка в BIS (ссылка выше). В России аналогичная процедура в лице ФСБ.
И тут может быть небольшая проблемка при первом варианте — нужно доказать, что вы уменьшаете эффективную длину ключа где то за пределами функции задания ключа.
Если у кого есть подобный опыт или ссылки найдете интересно будет почитать.
Re[11]: Подружить ChaCha20 с ключами разной длины
От: CreatorCray  
Дата: 16.01.24 07:36
Оценка:
Здравствуйте, 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>И тут может быть небольшая проблемка при первом варианте — нужно доказать, что вы уменьшаете эффективную длину ключа где то за пределами функции задания ключа.

Эта проблема аналогична доказательству того, что в коде нет другой функции задания ключа, которая таких ограничений не имеет.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Re[11]: Подружить ChaCha20 с ключами разной длины
От: rudzuk  
Дата: 16.01.24 12:50
Оценка:
Здравствуйте, TheBeginner, Вы писали:

TB> И тут может быть небольшая проблемка при первом варианте — нужно доказать, что вы уменьшаете эффективную длину ключа где то за пределами функции задания ключа.


Разве же это проблема? Перед передачей ключа условному AES256 вставить код обнуления хвостовых 200 бит
avalon/3.0.2
Re[12]: Подружить ChaCha20 с ключами разной длины
От: CreatorCray  
Дата: 16.01.24 19:16
Оценка:
Здравствуйте, rudzuk, Вы писали:

R>Разве же это проблема? Перед передачей ключа условному AES256 вставить код обнуления хвостовых 200 бит

Это не техническая проблема а вопрос соблюдения ритуальных приседаний для выполнения условий регулятора.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Re[13]: Подружить ChaCha20 с ключами разной длины
От: rudzuk  
Дата: 16.01.24 20:48
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC> Это не техническая проблема а вопрос соблюдения ритуальных приседаний для выполнения условий регулятора.


Ну так регулятор увидит же обнуление части ключа перед использованием. Яснее ясного, как по мне
avalon/3.0.2
Re[14]: Подружить ChaCha20 с ключами разной длины
От: CreatorCray  
Дата: 16.01.24 21:02
Оценка:
Здравствуйте, rudzuk, Вы писали:

R>Ну так регулятор увидит же обнуление части ключа перед использованием.

Устроит ли это регулятора?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Re[15]: Подружить ChaCha20 с ключами разной длины
От: rudzuk  
Дата: 16.01.24 21:34
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC> R>Ну так регулятор увидит же обнуление части ключа перед использованием.


CC> Устроит ли это регулятора?


Не вижу причин почему может не устроить. Впрочем, я не регулятор
avalon/3.0.2
Re[12]: Подружить ChaCha20 с ключами разной длины
От: TheBeginner  
Дата: 17.01.24 07:15
Оценка:
Здравствуйте, 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?
Re[13]: Подружить ChaCha20 с ключами разной длины
От: rudzuk  
Дата: 17.01.24 09:42
Оценка: +1
Здравствуйте, TheBeginner, Вы писали:

TB> Вот кстати еще один технический вопрос — как требования к максимальной длине ключа (56 бит например) соотносятся c IV (вектором инициализации). Или вся эта нормативная база застряла на уровне DES?


Вектор инициализации не является секретом.
avalon/3.0.2
Re[14]: Подружить ChaCha20 с ключами разной длины
От: TheBeginner  
Дата: 17.01.24 11:01
Оценка:
Здравствуйте, rudzuk, Вы писали:

R>Здравствуйте, TheBeginner, Вы писали:


TB>> Вот кстати еще один технический вопрос — как требования к максимальной длине ключа (56 бит например) соотносятся c IV (вектором инициализации). Или вся эта нормативная база застряла на уровне DES?


R>Вектор инициализации не является секретом.


Но устойчивость то к взлому повышается, а ведь именно это их и интересует. Тем более распространенной практикой является использовать изменяемый криптографический хеш для формирования IV.
И этот IV скрыт и формируется допустим на основе внутренних состояний переменных на стороне шифровки и расшифровки с помощью криптографической хеш функции?
Отредактировано 17.01.2024 11:21 TheBeginner . Предыдущая версия .
Re[15]: Подружить ChaCha20 с ключами разной длины
От: rudzuk  
Дата: 17.01.24 11:46
Оценка: +1
Здравствуйте, TheBeginner, Вы писали:

TB> R>Вектор инициализации не является секретом.


TB> Но устойчивость то к взлому повышается, а ведь именно это их и интересует. Тем более распространенной практикой является использовать изменяемый криптографический хеш для формирования IV.


Она повышается только если для взлома будут использованы методы криптоанализа. Но при коротком ключе никто не будет заниматься криптоанализом, будут тупо брутить. Ну а брутфорсу, что есть IV, что нет (если он не секретен), немного дополнительных операций и только.

TB> И этот IV скрыт и формируется допустим на основе внутренних состояний переменных на стороне шифровки и расшифровки с помощью криптографической хеш функции?


Если алгоритм формирования IV и отправные точки известены, он опять же не является секретом.
avalon/3.0.2
Re[16]: Подружить ChaCha20 с ключами разной длины
От: TheBeginner  
Дата: 17.01.24 12:44
Оценка:
Здравствуйте, 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 битов.
void ECRYPT_keysetup(ECRYPT_ctx *x, const u8 *k, u32 kbits, u32 ivbits)
{
    const char *constants;

    x->input[4] = U8TO32_LITTLE(k + 0);
    x->input[5] = U8TO32_LITTLE(k + 4);
    x->input[6] = U8TO32_LITTLE(k + 8);
    x->input[7] = U8TO32_LITTLE(k + 12);
    if (kbits == 256) { /* recommended */
        k += 16;
        constants = sigma;
    }
    else { /* kbits == 128 */
        constants = tau;
    }
    x->input[8] = U8TO32_LITTLE(k + 0);
    x->input[9] = U8TO32_LITTLE(k + 4);
    x->input[10] = U8TO32_LITTLE(k + 8);
    x->input[11] = U8TO32_LITTLE(k + 12);
    x->input[0] = U8TO32_LITTLE(constants + 0);
    x->input[1] = U8TO32_LITTLE(constants + 4);
    x->input[2] = U8TO32_LITTLE(constants + 8);
    x->input[3] = U8TO32_LITTLE(constants + 12);
}

void ECRYPT_ivsetup(ECRYPT_ctx *x, const u8 *iv)
{
    x->input[12] = 0;
    x->input[13] = 0;
    x->input[14] = U8TO32_LITTLE(iv + 0);
    x->input[15] = U8TO32_LITTLE(iv + 4);
}
Re[17]: Подружить ChaCha20 с ключами разной длины
От: rudzuk  
Дата: 17.01.24 13:38
Оценка:
Здравствуйте, TheBeginner, Вы писали:

TB> R>Если алгоритм формирования IV и отправные точки известены, он опять же не является секретом.


TB> Вот. То есть в таком случае не достаточно поделиться криптоалгоритмом, а надо предоставить информации о приложении гораздо больше.


Ну да. Полагаю, необходимо предоставлять всю схему шифрования.

TB> И еще вот что — можно ли менять так просто эффективную длину ключа для любого криптоалгоритма просто обнуляя лишние биты, в том смысле, что задавая IV мы фактически увеличим эффективную длину ключа?


Она увеличится только при секретном IV, который, в этом случае, можно рассматривать, как часть ключа. Вообще, IV применяют для рандомизации внутреннего состояния шифра при использовании одного ключа с разными потоками данных. Если ключ всегда разный, то IV можно не использовать.
avalon/3.0.2
Re[18]: Подружить ChaCha20 с ключами разной длины
От: TheBeginner  
Дата: 17.01.24 14:15
Оценка:
Здравствуйте, rudzuk, Вы писали:

TB>> И еще вот что — можно ли менять так просто эффективную длину ключа для любого криптоалгоритма просто обнуляя лишние биты, в том смысле, что задавая IV мы фактически увеличим эффективную длину ключа?


R>Вообще, IV применяют для рандомизации внутреннего состояния шифра при использовании одного ключа с разными потоками данных. Если ключ всегда разный, то IV можно не использовать.


Это я знаю

R>Она увеличится только при секретном IV, который, в этом случае, можно рассматривать, как часть ключа.


Если вернуться к формальностям (описание и передача исходников криптоалгоритма) лучше наверное модифицировать сам криптоалгоритм, убрав задание IV, а внутри функции установки ключа обнулять лишние биты.
В таком случае не будет интереса за пределами этого кода. (а ключ естественно передавать новый для каждого шифруемого сообщения и интереса в том как он создается уже не будет).
Re[19]: Подружить ChaCha20 с ключами разной длины
От: rudzuk  
Дата: 17.01.24 14:50
Оценка: +1
Здравствуйте, TheBeginner, Вы писали:

TB> Если вернуться к формальностям (описание и передача исходников криптоалгоритма) лучше наверное модифицировать сам криптоалгоритм, убрав задание IV, а внутри функции установки ключа обнулять лишние биты.

TB> В таком случае не будет интереса за пределами этого кода. (а ключ естественно передавать новый для каждого шифруемого сообщения и интереса в том как он создается уже не будет).

Возможно

Кстати, в двух статьях в англоязычной вики сказано, что ограничения на размер ключей в 56-bit уже не действуют:

https://en.wikipedia.org/wiki/56-bit_encryption

In 2000, all restrictions on key length were lifted, except for exports to embargoed countries


https://en.wikipedia.org/wiki/Brute-force_attack

Although U.S. export regulations historically restricted key lengths to 56-bit symmetric keys (e.g. Data Encryption Standard), these restrictions are no longer in place, so modern symmetric algorithms typically use computationally stronger 128- to 256-bit keys.

avalon/3.0.2
Re[15]: Подружить ChaCha20 с ключами разной длины
От: CreatorCray  
Дата: 17.01.24 18:14
Оценка:
Здравствуйте, TheBeginner, Вы писали:

TB>Но устойчивость то к взлому повышается

К некоторым методам взлома.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Re[17]: Подружить ChaCha20 с ключами разной длины
От: CreatorCray  
Дата: 17.01.24 18:14
Оценка:
Здравствуйте, TheBeginner, Вы писали:

TB>Внутреннее состояние

TB>И всё это вместе похоже и есть некий ключ.

Не надо путать внутреннее состояние и ключ.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Re[20]: Подружить ChaCha20 с ключами разной длины
От: CreatorCray  
Дата: 17.01.24 18:14
Оценка:
Здравствуйте, rudzuk, Вы писали:

R>https://en.wikipedia.org/wiki/56-bit_encryption

R>

In 2000, all restrictions on key length were lifted, except for exports to embargoed countries


Вот мне тоже казалось что это давно не действует.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Re[21]: Подружить ChaCha20 с ключами разной длины
От: rudzuk  
Дата: 17.01.24 18:59
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC> R>https://en.wikipedia.org/wiki/56-bit_encryption

CC> R>In 2000, all restrictions on key length were lifted, except for exports to embargoed countries

CC> Вот мне тоже казалось что это давно не действует.


Да, но, с другой стороны, МС предупреждает (2023 год) о необходимости соблюдения экспортных ограничений
avalon/3.0.2
Re[22]: Подружить ChaCha20 с ключами разной длины
От: CreatorCray  
Дата: 17.01.24 22:15
Оценка: +1
Здравствуйте, rudzuk, Вы писали:

R>Да, но, с другой стороны, МС предупреждает (2023 год) о необходимости соблюдения экспортных ограничений


Как то они там весьма невнятно высказались. Не очень понятно, тот же "Password encryption" это governed by EAR или not restricted?

Note that some of the applications of cryptography are not restricted. Here are the unrestricted tasks:

Password encryption
Copy protection
Authentication
Digital rights management
Using digital signatures


Вот тут: https://www.bis.doc.gov/index.php/documents/pdfs/2759-table-of-changes-to-enc-in-wa2019-rule-final-version/file

5x992.c – mass market cryptographic libraries, modules, development kits and toolkits (except for items implementing “non-standard cryptography”) — Falls under EAR Section 740.17(b)(1) — No selfclassification report or classification required.

Вообще там очень бюрократически всё написано, надо садиться и внимательно читать все ссылки на другие документы.

https://www.bis.doc.gov/index.php/documents/new-encryption/1651-740-17-enc-table/file
https://www.bis.doc.gov/index.php/policy-guidance/encryption/3-license-exception-enc-and-mass-market/e-740-17-b-1

License Exception ENC
740.17(b)(1)

If an item or transaction does not fall under any of the above provisions (740.17(a), (b)(2), or (b)(3) then it falls under 740.17(b)(1).

Items described in 740.17(b)(1) DO NOT require a classification submission to BIS to be eligible for license exception ENC or NLR status for mass market items. They may be self-classified by the exporter.

If an exporter chooses to self-classify an item under 740.17(b)(1), they must submit an Annual Self-Classification Report. However, if the item is submitted for a classification request with BIS and the classification request has been issued, that item does not need to be included on the Annual Self-Classification Report.


Из того что я там вижу, если ты не экспортируешь в E:1/Cuba и не попадаешь в 740.17(b)(2) или 740.17(b)(3) то не надо париться обрезанием ключей, достаточно зарепортить.

Country group E:1 тут: https://www.ecfr.gov/current/title-15/subtitle-B/chapter-VII/subchapter-C/part-740/appendix-Supplement%20No.%201%20to%20Part%20740
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.