Есть вот такой код отсюда: 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);
}

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

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

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

Здравствуйте, 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);
}

Здравствуйте, 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 ключ оптимального размера и в нем будет вся энтропия из оригинального ключа без потерь.

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

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

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

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

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

Когда я говорю, что ключ есть, это естественно подразумевает что на вход ECRYPT_keysetup в качестве ключа подается тот же sha256. Не пользовательский пароль же
Вопрос повторяю в другом — как лучше переписать ECRYPT_keysetup для любых kbits < 256

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

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

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

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

TB>Возможно это и так. Интересно что будет если "добрать" до 256 открытыми байтами.
Мда. С таким уровнем теоретической подготовки лучше не трогать криптографию — сделаешь только хуже

Здравствуйте, 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);
}

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

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

RC6

TB>void ECRYPT_keysetup(ECRYPT_ctx *x,const u8 *k,u32 kbits,u32 ivbits)

Как верно заметил CreatorCray, если не до конца понимаешь используемую математику, лучше не работай с низкоуровневыми примитивами. Возьми более-менее дуракоустойчивый nacl/libsodium, там как раз есть и KDF, и chacha20 в конкретном сценарии.

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

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

TB>И если вы знаете алгоритм шифрования эквивалентный стойкости с AES и желательно выше по скорости при софтверной реализации при одинаковой длине ключа
Дюд, у тебя ОЧЕНЬ сильно не хватает теории. Просто катастрофически.
Любой совет, который тебе тут дадут у тебя есть риск банально не понять правильно и потому накосячить банально от непонимания.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Спасибо, посмотрю как там все реализовано. Интересно, а формально в таком случае можно говорить, что стойкость реализуемого шифрования не больше заданного?
Вы сталкивались с такими задачами?

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

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

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

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

Здравствуйте, 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 за пределами требуемой стойкости. Все.
Я понял вашу идею. Там в ответе крэю ирония если что

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

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

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

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

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

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

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

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

Strong encryption (AES256)

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

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

Здравствуйте, 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