F(два массива случайных чисел) = секретный ключ

нюанс в том что суммарная длина массивов не равна длине ключа

меньше длины ключа?

Сабж, надо имея два массива случайных чисел (байт)

а откуда ты их взял?

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

зачем ты изобретаешь свой криптопротокол, когда есть TLS 1.2?

А ключ можно сделать, склеив два массива последовательно и взяв хэш

затем что кроме tcp существуют еще протоколы 8)

а хеш имеет постоянную длину и не факт что такую же как и ключ

А почему ты функцию подбираешь под случайное число, а не наоборот? Ты уверен что числа случайные? Или у тебя железка их в таком виде выдает?

echo $a$b | sha1sum

Или я что-то не так понял?

а есди длина хеша меня не устраивает (т.е. требуется больше?)

что?

Длинна ключа или твоих массивов?
Если первое - а зачем длиннее? Максимальноэффективная длинна хеша зависит от алгоритма который его будет юзать. Если нужно длиннее используй другой алгоритм.

Можно просто взять оба твоих массива, преобразовать в 16-тиричное представление, обрезать сколько надо и получить свой секретный ключ. Если массивы длинные и действительно случайные.

Да то что алгоритмы генерации секретных ключей подразумевают случайное число. Зачем тебе нужно именно в формате «два массива случайных чисел, суммарная длина массивов не равна длине ключа». Почему бы не использовать такие случайные числа, которые принимает алгоритм, который ты выберешь.

А что, длина ключа у тебя рандомна и совершенно непредсказуема? )

есть разные хэши, sha224, sha256, sha384, 512

Если нужно длиннее используй другой алгоритм.

какой алгоритм использовать для 512 байтного ключа?

оба твоих массива, преобразовать в 16-тиричное представление

зачем массивы байтов преобразовывать в строку?

F(два массива случайных чисел) = секретный ключ (комментарий)

дык, ее вообще юзер может выбрать

нельзя такое юзверю доверять, он по дефолту идиот ) Разве что несколько фиксированных значений из списка

Не проще и безопаснее ли генерировать секретный ключ опреденённого размера и уже его шифровать юзерским паролем, как делают нормальные люди?

по дефолту там 16 байт, но надо предусмотреть в протоколе возможность любых вариантов, а соотв. закрепить механизм генерации ключа

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

Даже боюсь предположить зачем это нужно

зачем массивы байтов преобразовывать в строку?

Что-бы получить строку и использовать ее как секретный ключ.

какой алгоритм использовать для 512 байтного ключа?

PBKDF2? А зачем такой длинный ключ?

какой пароль, какие нормальные люди используют пароль если есть нормальные добрые приватные RSA ключи для этого?

генерацию разбивают на два источника скорее всего для улучшения энтропии - так она собирается с обоих машин

Эти ключи иногда шифруют с паролем, чтоб так просто не скопировали. // я читал тред не сначала, поэтому ответил невпопад.

http://technet.microsoft.com/en-us/library/cc785811(WS.10).aspx

генерацию разбивают на два источника скорее всего для улучшения энтропии - так она собирается с обоих машин

Делать a ^ b и обрезать на длину ключа.

PBKDF2? А зачем такой длинный ключ?

это алгоритм для паролей, для ключей я описал выше, и просил рассказать зачем оно такое мудрое

Делать a ^ b

и как это удлинит данные до размера ключа?

Суммарная длина массивов меньше чем длина ключа?

Ну я же не знаю какой длинны у тебя массивы, раз они короче ключа почему бы нет?

и как это удлинит данные до размера ключа?

Если массивы ты получаешь сам, что мешает сделать их длиннее?

F(два массива случайных чисел) = секретный ключ (комментарий)

генерацию разбивают на два источника скорее всего для улучшения энтропии - так она собирается с обоих машин

Объединять каким-то образом энтропию с двух физически раздёлённых хостов — идея дурацкая на первый взгляд. Потому что её придётся гонять либо по открытому каналу, либо по шифрованному ключом k0. Надёжность полученного ключа будет порядка k0. Либо объясни более подробно, что хочешь делать.

Какой бы подход ты ни выбрал, если длина входных данных меньше требуемого размера ключа, перебор можно будет делать по этим данным. Так что бессмысленно, IMHO.

если функция, вычисляющая ключ, достаточно процессорожручая, то вовсе не факт, что перебор по ключу будет тогда медленнее

Объединять каким-то образом энтропию с двух физически раздёлённых хостов — идея дурацкая на первый взгляд.

она используется в ssl http://technet.microsoft.com/en-us/library/cc785811(WS.10).aspx

ТС, а ты матчасть по криптографии хорошо изучил? Шнайера там, других аффтаров...

ты про какой секретный ключ говоришь, для RSA?

возможно поэтому и применяют HKDF вместо того что тут предлагали колхозить

за время этого треда я покрылся фейспалмами в три слоя

вот тут я написал F(два массива случайных чисел) = секретный ключ (комментарий) что RSA ключи у меня уже есть, зачем бы я спрашивал как их генерить и кидался ссылками на генерацию _симметричного_ ключа?

ну так называл бы тему правильно, «генерация ключа для симметричного алгоритма шифрования»

кроме tcp существуют еще протоколы

DTLS.

Поиск телепатов оказался неудачным.

она используется в ssl http://technet.microsoft.com/en-us/library/cc785811(WS.10).aspx

там эти два рандома от клиента и сервера не единственный источник для генерации ключа

http://tools.ietf.org/html/rfc5246

он не подходит, там нагородили кучу всякой радости отчего для передачи одного сообщения надо сначала осуществить handshake, а у меня большую часть времени передается одно сообщение

и мне нужно чтобы часть сообщения была не закодирована но подписана

pre_master_secret там тоже из гсч, потом все это вместе со строкой попадает в PRF (которая также умеет выдачать произвольную длину) что напоминает HKDF и тут опять вопрос из топика: зачем там так, зачем потом HKDF и какие проблемы.

DH?