Какой наш криптоалгоритм будет использоваться в системе ЭЦП?

[Oybek Djuraev]

Какой наш криптографический алгоритм будет использоватся в системе ЭЦП? Насколько я знаю УзДСТ 1105, 1106 отменили? Или введутся разработки над новым алгоритмом? (Юнусов) Рустам ака
в УзАСИ помоему непосредственно этими вопросаи занимались Вы, можете как нибудь прокомментировать? Или после выхода Постановлении Президента РУз №614 (по криптографической защите)
этими вопросами занимается только СНБ РУз?
Заранее благодарю...

[Rustam Yunusov]

Какой наш криптографический алгоритм будет использоватся в системе ЭЦП? Насколько я знаю УзДСТ 1105, 1106 отменили? Или введутся разработки над новым алгоритмом? (Юнусов) Рустам ака
в УзАСИ помоему непосредственно этими вопросаи занимались Вы, можете как нибудь прокомментировать? Или после выхода Постановлении Президента РУз №614 (по криптографической защите)
этими вопросами занимается только СНБ РУз?
Заранее благодарю...

Спасибо за вопрос уважаемый Ойбек Джураев. УзДСТ 1105, 1106 не отменили проста их введения в действий продлили по приказу УЗДАВСТАНДАРТ. На счет ПП № 614 уполномоченным органом отвечающий за СКЗИ определен СНБ РУ, и это не значить что мы не можем заниматься разработкой СКЗИ. С разработкой СКЗИ у нас занимается отдел криптологии при ЦНТМИ и они же при лице УзАСИ.

[Djalolatdin Rakhimov]

С разработкой СКЗИ у нас занимается отдел криптологии при ЦНТМИ и они же при лице УзАСИ. Вот лучше самих разработчкив бы пригласили для комментариев...

[Erkin Kuchkarov]

С разработкой СКЗИ у нас занимается отдел криптологии при ЦНТМИ и они же при лице УзАСИ.
Двуликий Янус или просто как члены ВТК при УзАСИ?

[Rustam Yunusov]

С разработкой СКЗИ у нас занимается отдел криптологии при ЦНТМИ и они же при лице УзАСИ.
Двуликий Янус или просто как члены ВТК при УзАСИ?

ЦНТМИ входит в подведомственную структуру УзАСИ.

[Oybek Djuraev]

Спасибо за вопрос уважаемый Ойбек Джураев. УзДСТ 1105, 1106 не отменили проста их введения в действий продлили по приказу УЗДАВСТАНДАРТ. На счет ПП № 614 уполномоченным органом отвечающий за СКЗИ определен СНБ РУ, и это не значить что мы не можем заниматься разработкой СКЗИ. С разработкой СКЗИ у нас занимается отдел криптологии при ЦНТМИ и они же при лице УзАСИ.

Слыхал что после выхода Пост. Президента №614, создали спец. группу с специалистами криптографии УзАСИ, СНБ, и помоему ТУИТ тоже (совместно), которая серъёзно занимается разработкой новой СКЗИ. Это правда или просто слухи, или все это является секретной?

[shumbola]

Спасибо за вопрос уважаемый Ойбек Джураев. УзДСТ 1105, 1106 не отменили проста их введения в действий продлили по приказу УЗДАВСТАНДАРТ. На счет ПП № 614 уполномоченным органом отвечающий за СКЗИ определен СНБ РУ, и это не значить что мы не можем заниматься разработкой СКЗИ. С разработкой СКЗИ у нас занимается отдел криптологии при ЦНТМИ и они же при лице УзАСИ.

Слыхал что после выхода Пост. Президента №614, создали спец. группу с специалистами криптографии УзАСИ, СНБ, и помоему ТУИТ тоже (совместно), которая серъёзно занимается разработкой новой СКЗИ. Это правда или просто слухи, или все это является секретной?

Оооооо, стало интересно.
Чтобы защитить государственные интересы необходимы свои СКЗИ. А вдруг там у "империалистов" есть backdoor, откуда нам знать. ;)

[Rustam Yunusov]

Спасибо за вопрос уважаемый Ойбек Джураев. УзДСТ 1105, 1106 не отменили проста их введения в действий продлили по приказу УЗДАВСТАНДАРТ. На счет ПП № 614 уполномоченным органом отвечающий за СКЗИ определен СНБ РУ, и это не значить что мы не можем заниматься разработкой СКЗИ. С разработкой СКЗИ у нас занимается отдел криптологии при ЦНТМИ и они же при лице УзАСИ.

Слыхал что после выхода Пост. Президента №614, создали спец. группу с специалистами криптографии УзАСИ, СНБ, и помоему ТУИТ тоже (совместно), которая серъёзно занимается разработкой новой СКЗИ. Это правда или просто слухи, или все это является секретной?

Тут нет ничего секретного. А вот создали группу незнаю откуда у вас такая инфа но это не правильно. СКЗИ от имени УзАСИ занимается отдел криптологии как я уже говорил при ЦНТМИ.

[Rustam Yunusov]

С разработкой СКЗИ у нас занимается отдел криптологии при ЦНТМИ и они же при лице УзАСИ. Вот лучше самих разработчкив бы пригласили для комментариев...

ДЖ пригласили их надеюсь скоро они присоединятся к нашим постам.

[Rustam Yunusov]

Спасибо за вопрос уважаемый Ойбек Джураев. УзДСТ 1105, 1106 не отменили проста их введения в действий продлили по приказу УЗДАВСТАНДАРТ. На счет ПП № 614 уполномоченным органом отвечающий за СКЗИ определен СНБ РУ, и это не значить что мы не можем заниматься разработкой СКЗИ. С разработкой СКЗИ у нас занимается отдел криптологии при ЦНТМИ и они же при лице УзАСИ.

Слыхал что после выхода Пост. Президента №614, создали спец. группу с специалистами криптографии УзАСИ, СНБ, и помоему ТУИТ тоже (совместно), которая серъёзно занимается разработкой новой СКЗИ. Это правда или просто слухи, или все это является секретной?

Оооооо, стало интересно.
Чтобы защитить государственные интересы необходимы свои СКЗИ. А вдруг там у "империалистов" есть backdoor, откуда нам знать. ;)

Конечно интересно иметь свои собственные СКЗИ. Мировая практика показывает что в России есть своя, Белоруссии и Укарины имеют свои СКЗИ а чем мы хуже. Думаю нам тоже надо иметь свои собственные разработанные своими специалистами СКЗИ. Вот над этим и наши специалисты работают и уже есть хорошие результаты в области СКЗИ.

[shumbola]

УзДСТ 1105, 1106 не отменили проста их введения в действий продлили по приказу УЗДАВСТАНДАРТ.

Скажите, а до какого срока продлили? И есть ли ссылка на это где-нибудь или это внутренный приказ?

[shumbola]

Я для разработчиков приготовил, свой первый вопрос :)

Согласно OzDST 1106, для функции хеширования необходимо иметь ключ хеширования k с длиной 128 (256) бит. А откуда берется значение этого ключа хеширования? Можно ли использовать постоянный ключ? От знания ключа хеширования меняется ли защищенность функции хеширования? Зависит ли от ключа хеширования конечный результат?

Спасибо.

[Erkin Kuchkarov]

А я в соседней ветке тоже терроризирую

[shumbola]

А я в соседней ветке тоже терроризирую

Как вы думаете какая тема наиболее подходящая? :icon_wink:
Если соседная, то все перебираемся туда, если эта, то сюда.

[Rustam Yunusov]

УзДСТ 1105, 1106 не отменили проста их введения в действий продлили по приказу УЗДАВСТАНДАРТ.

Скажите, а до какого срока продлили? И есть ли ссылка на это где-нибудь или это внутренный приказ?

Стандарт O'zDSt 1106: 2006 "Информационный технологии. Криптографическая защита информации. Функция хеширования" 12 апреля 2006 года зарегистрирован в агентстве УзСтандарт под номером 1106 и введен в действие на пять лет с 1 октября 2006 года.

[Rustam Yunusov]

Я для разработчиков приготовил, свой первый вопрос :)

Согласно OzDST 1106, для функции хеширования необходимо иметь ключ хеширования k с длиной 128 (256) бит. А откуда берется значение этого ключа хеширования? Можно ли использовать постоянный ключ? От знания ключа хеширования меняется ли защищенность функции хеширования? Зависит ли от ключа хеширования конечный результат?

Спасибо.

Ответы на вопросы:
1. Откуда берутся ключи хеширования?
Ключи хеширования могут генерироваться с помощью какого либо генератора случайных чисел или в качестве ключа хеширования можно взять результат шифрования хешируемого сообщения.

2. Можно ли использовать постоянный ключ?
Можно. В инфраструктуре открытых ключей (ИОК) используется хеширования со сроком действия не менее пяти лет.

3. От знания ключа хеширования меняется защищенность функции хеширования? (Перефразируем вопрос: Зависит ли стойкость функции хеширования от знания ключа хеширования?)
Это зависит от того где и в каких целях используется хеширование.
Если хеширование используется в парольной защите, то ключ хеширования не должен быть известен.
Если хеширование используется в ИОК, то ключ хеширования устанавливается с сертификате открытого ключа то есть известен всем.
и т.д.

4. Зависит ли от ключа хеширования конечный результат?
Да. Конечный результат хеширования зависит от ключа хеширования. При изменении хотя бы одного бита ключа хеширования полностью меняется хешированное сообщение то есть должен происходить "лавинный эффект".

[shumbola]

Я для разработчиков приготовил, свой первый вопрос :)

Согласно OzDST 1106, для функции хеширования необходимо иметь ключ хеширования k с длиной 128 (256) бит. А откуда берется значение этого ключа хеширования? Можно ли использовать постоянный ключ? От знания ключа хеширования меняется ли защищенность функции хеширования? Зависит ли от ключа хеширования конечный результат?

Спасибо.

Ответы на вопросы:
1. Откуда берутся ключи хеширования?
Ключи хеширования могут генерироваться с помощью какого либо генератора случайных чисел или в качестве ключа хеширования можно взять результат шифрования хешируемого сообщения.

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

2. Можно ли использовать постоянный ключ?
Можно. В инфраструктуре открытых ключей (ИОК) используется хеширования со сроком действия не менее пяти лет.

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


3. От знания ключа хеширования меняется защищенность функции хеширования? (Перефразируем вопрос: Зависит ли стойкость функции хеширования от знания ключа хеширования?)
Это зависит от того где и в каких целях используется хеширование.
Если хеширование используется в парольной защите, то ключ хеширования не должен быть известен.
Если хеширование используется в ИОК, то ключ хеширования устанавливается с сертификате открытого ключа то есть известен всем.
и т.д.

А где хранить ключ хеширования в парольной защите? Не удобно ей богу, недобно :(

Т.е., стойкость функции хеширования зависить от знания ключа хеширования. Тогда, зачем вообще использовать хеширование в ИОК?
Получается, backdoor?


4. Зависит ли от ключа хеширования конечный результат?
Да. Конечный результат хеширования зависит от ключа хеширования. При изменении хотя бы одного бита ключа хеширования полностью меняется хешированное сообщение то есть должен происходить "лавинный эффект".

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

[Evgeniy Sklyarevskiy]

Что такое СКЗИ?

[shumbola]

Что такое СКЗИ?

Средства Криптографической Защиты Информации

[Rustam Yunusov]

Я для разработчиков приготовил, свой первый вопрос :)

Согласно OzDST 1106, для функции хеширования необходимо иметь ключ хеширования k с длиной 128 (256) бит. А откуда берется значение этого ключа хеширования? Можно ли использовать постоянный ключ? От знания ключа хеширования меняется ли защищенность функции хеширования? Зависит ли от ключа хеширования конечный результат?

Спасибо.

Ответы на вопросы:
1. Откуда берутся ключи хеширования?
Ключи хеширования могут генерироваться с помощью какого либо генератора случайных чисел или в качестве ключа хеширования можно взять результат шифрования хешируемого сообщения.

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

Вы наверняка ошибаетесь такого требования к алгоритмам хеширования не существует и тем более простое число не может быть четным. :-)
Ранее было сказано когда хеширование используется в ИОК ключ выдается на определнный срок и нет
необходимости генерации ключа при каждом сеансе (см. далее).


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

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


3. От знания ключа хеширования меняется защищенность функции хеширования? (Перефразируем вопрос: Зависит ли стойкость функции хеширования от знания ключа хеширования?)
Это зависит от того где и в каких целях используется хеширование.
Если хеширование используется в парольной защите, то ключ хеширования не должен быть известен.
Если хеширование используется в ИОК, то ключ хеширования устанавливается с сертификате открытого ключа то есть известен всем.
и т.д.

А где хранить ключ хеширования в парольной защите? Не удобно ей богу, недобно :(

Ключ хеширования не обязательно где-то хранить. Существуют много подходов для получения ключа
хеширования. Один из этих подходов это в качестве ключа хеширования использовать сам пароль и с помощью него же хешировать пароль и полученное хеш значение сравнивать с хранимым в компьютере хеш-значением.


Т.е., стойкость функции хеширования зависить от знания ключа хеширования. Тогда, зачем вообще использовать хеширование в ИОК?
Получается, backdoor?


В ИОК хеширование используется для сжатия сообщения и далее использовать ЭЦП ( X.509 или O'zDSt 1108-2006). Сжатие используется для того чтобы алгоритм ЭЦП быстро ставил подпись и для обеспечения сервиса безотказность от авторства (non-repudiation).



4. Зависит ли от ключа хеширования конечный результат?
Да. Конечный результат хеширования зависит от ключа хеширования. При изменении хотя бы одного бита ключа хеширования полностью меняется хешированное сообщение то есть должен происходить "лавинный эффект".

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

Скорость алгоритма хеширования достаточна для использования в любых системах применяющих хеширование информации. Это доказано на практике во времы аппробации принятых алгоритмов криптографической защиты информации.
Алгоритм хеширования модифицирован и внего внесены изменения повышающие его стойкость к коллизии.
Информацию можно получить в статье опубликованной в журнале Инфокоммуникации: Сети, Технологии, Решения №3, 2007 г. авторами функции хеширования.


Пожалуйста формулируйте вопросы корректно чтобы не было недоразумений в будущем.

[shumbola]

Вы наверняка ошибаетесь такого требования к алгоритмам хеширования не существует и тем более простое число не может быть четным. :-)
Ранее было сказано когда хеширование используется в ИОК ключ выдается на определнный срок и нет
необходимости генерации ключа при каждом сеансе (см. далее).


Да согласен, считайте что ошибка вкралась. Конечно, я имел ввиду четное натуральное число. Вот цитата непосредственно из стандарта:

5.1.2 Первоначальный этапный ключ ke формируется из линейного массива
ключа хэширования k на полубайт(байт)овом уровне второй полубайт(байт) которого
должен быть четным натуральным числом.

[RustamQE]

Ключи хеширования могут генерироваться с помощью какого либо генератора случайных чисел или в качестве ключа хеширования можно взять результат шифрования хешируемого сообщения.



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

Как мне известно в стандарте не описан процесс генерации ключа. Ключ генерируется один раз и действителен до истечении срока действия сертификата (в случае ИОК). И Вам не стоит каждый раз генерировать новые ключи.


3. От знания ключа хеширования меняется защищенность функции хеширования? (Перефразируем вопрос: Зависит ли стойкость функции хеширования от знания ключа хеширования?)
Это зависит от того где и в каких целях используется хеширование.
Если хеширование используется в парольной защите, то ключ хеширования не должен быть известен.
Если хеширование используется в ИОК, то ключ хеширования устанавливается с сертификате открытого ключа то есть известен всем.
и т.д.


А где хранить ключ хеширования в парольной защите? Не удобно ей богу, недобно :(

Т.е., стойкость функции хеширования зависить от знания ключа хеширования. Тогда, зачем вообще использовать хеширование в ИОК?
Получается, backdoor?


Где Вы хотели бы хранить свои ключи ? В стандарте не описаны методы хранения ключей. Кроме того ключ хеширования это открытый ключ и как его хранить - зависить от создаваемой системы, как выше ответил Юнусов. Стойкость к коллизиям функции хеширования в первую очередь оценивается при известном ключе хеширования. Конечно область применения функции очень широка. В каждом случае свой подход и для генерации (сколько раз) и для хранения (где).


4. Зависит ли от ключа хеширования конечный результат?
Да. Конечный результат хеширования зависит от ключа хеширования. При изменении хотя бы одного бита ключа хеширования полностью меняется хешированное сообщение то есть должен происходить "лавинный эффект".

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

Зачем изменять ключ хеширования он же открытый. Но при изменении ключа так и должно быть, должен изменятся значении хеш функции. Наша компания впервые в Уз разработала систему на основе национальных алгоритмов. Скорость ФХ около 80 Мбит/сек, при Селерон 1.7 256 МБ ОЗУ. Но мы не выставили его на продажу, так как функцией хеширования не доконца все решена. Но на основе национальных стандартов шифрования (18 Мбит/сек) и ЭЦП мы реализовали проекты для ГНК, внедрили криптопровайдер для защищенной электронной почты и электронного документооборота.

[shumbola]

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

А теперь прочитайте ваш ответ:

2. Можно ли использовать постоянный ключ?
Можно. В инфраструктуре открытых ключей (ИОК) используется хеширования со сроком действия не менее пяти лет.

[shumbola]

А где хранить ключ хеширования в парольной защите? Не удобно ей богу, недобно

Ключ хеширования не обязательно где-то хранить. Существуют много подходов для получения ключа
хеширования. Один из этих подходов это в качестве ключа хеширования использовать сам пароль и с помощью него же хешировать пароль и полученное хеш значение сравнивать с хранимым в компьютере хеш-значением.

Подходы существуют, но кто дасть гарантию, того что в обе стороны пользователи используют один и тот же способ?

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

[shumbola]

В ИОК хеширование используется для сжатия сообщения и далее использовать ЭЦП ( X.509 или O'zDSt 1108-2006). Сжатие используется для того чтобы алгоритм ЭЦП быстро ставил подпись и для обеспечения сервиса безотказность от авторства (non-repudiation).

А вы уверены в этом? Вообще, non-repudiation немного другое понятие, и она базируется на факте что, только один единственный пользователь секретного ключа имеет доступ к этому ключу.

[shumbola]

Алгоритм хеширования модифицирован и внего внесены изменения повышающие его стойкость к коллизии.
Информацию можно получить в статье опубликованной в журнале Инфокоммуникации: Сети, Технологии, Решения №3, 2007 г. авторами функции хеширования.

А где можно получить доступ к этому журналу? Есть в Сети электронный вариант?

[shumbola]

Пожалуйста формулируйте вопросы корректно чтобы не было недоразумений в будущем.

Взаимно.

[shumbola]

Как мне известно в стандарте не описан процесс генерации ключа. Ключ генерируется один раз и действителен до истечении срока действия сертификата (в случае ИОК). И Вам не стоит каждый раз генерировать новые ключи.

Вы о каком стандарте говорите? Я говорю про стандарт, где описывается алгоритм хеширования.


Где Вы хотели бы хранить свои ключи ? В стандарте не описаны методы хранения ключей. Кроме того ключ хеширования это открытый ключ и как его хранить - зависить от создаваемой системы, как выше ответил Юнусов. Стойкость к коллизиям функции хеширования в первую очередь оценивается при известном ключе хеширования. Конечно область применения функции очень широка. В каждом случае свой подход и для генерации (сколько раз) и для хранения (где).

Если ключ хеширования открытый ключ, то мне нечего скрывать информацию об этом ключе? Верно?


Зачем изменять ключ хеширования он же открытый. Но при изменении ключа так и должно быть, должен изменятся значении хеш функции. Наша компания впервые в Уз разработала систему на основе национальных алгоритмов. Скорость ФХ около 80 Мбит/сек, при Селерон 1.7 256 МБ ОЗУ. Но мы не выставили его на продажу, так как функцией хеширования не доконца все решена. Но на основе национальных стандартов шифрования (18 Мбит/сек) и ЭЦП мы реализовали проекты для ГНК, внедрили криптопровайдер для защищенной электронной почты и электронного документооборота.

Поздравляю! Раз вы уже прошли этот этап, я лично всячески поддерживаю ваше присутствии и участии в дискуссиях наряду с разработчиками алгоритма.

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

[RustamQE]

А где хранить ключ хеширования в парольной защите? Не удобно ей богу, недобно

Ключ хеширования не обязательно где-то хранить. Существуют много подходов для получения ключа
хеширования. Один из этих подходов это в качестве ключа хеширования использовать сам пароль и с помощью него же хешировать пароль и полученное хеш значение сравнивать с хранимым в компьютере хеш-значением.

Подходы существуют, но кто дасть гарантию, того что в обе стороны пользователи используют один и тот же способ?

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


Для чего тогда протоколы существуют. Стандарты это только начало работ. Хоть американские хоть российские, все стандарты используют как минимум два параметра: входные данные (блок), и ключ. Но вопрос формирования ключа это уже второй вопрос. Точно также можно использовать и нац.стандарт. Это зависить от используемого протокола. Ключ можно также сформировать на основе входных данных.

[shumbola]

Ключ хеширования не обязательно где-то хранить. Существуют много подходов для получения ключа
хеширования. Один из этих подходов это в качестве ключа хеширования использовать сам пароль и с помощью него же хешировать пароль и полученное хеш значение сравнивать с хранимым в компьютере хеш-значением.

Подходы существуют, но кто дасть гарантию, того что в обе стороны пользователи используют один и тот же способ?

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


Для чего тогда протоколы существуют. Стандарты это только начало работ. Хоть американские хоть российские, все стандарты используют как минимум два параметра: входные данные (блок), и ключ. Но вопрос формирования ключа это уже второй вопрос. Точно также можно использовать и нац.стандарт. Это зависить от используемого протокола. Ключ можно также сформировать на основе входных данных.

Я потерялся. Не уточните какой стандарт вы имеете ввиду, когда говорите "Хоть американские хоть российские, все стандарты используют как минимум два параметра: входные данные (блок), и ключ"?

В зависимости от этого будем двигаться дальше...

[RustamQE]

Где Вы хотели бы хранить свои ключи ? В стандарте не описаны методы хранения ключей. Кроме того ключ хеширования это открытый ключ и как его хранить - зависить от создаваемой системы, как выше ответил Юнусов. Стойкость к коллизиям функции хеширования в первую очередь оценивается при известном ключе хеширования. Конечно область применения функции очень широка. В каждом случае свой подход и для генерации (сколько раз) и для хранения (где).

Если ключ хеширования открытый ключ, то мне нечего скрывать информацию об этом ключе? Верно?


Зачем изменять ключ хеширования он же открытый. Но при изменении ключа так и должно быть, должен изменятся значении хеш функции. Наша компания впервые в Уз разработала систему на основе национальных алгоритмов. Скорость ФХ около 80 Мбит/сек, при Селерон 1.7 256 МБ ОЗУ. Но мы не выставили его на продажу, так как функцией хеширования не доконца все решена. Но на основе национальных стандартов шифрования (18 Мбит/сек) и ЭЦП мы реализовали проекты для ГНК, внедрили криптопровайдер для защищенной электронной почты и электронного документооборота.

Поздравляю! Раз вы уже прошли этот этап, я лично всячески поддерживаю ваше присутствии и участии в дискуссиях наряду с разработчиками алгоритма.

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

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

[shumbola]

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

Всячески приветствую нац. стандарты, но они должны быть хотябы не хуже других. А было ли широкое обсуждение (среди специалистов, конечно), прежде чем принимались в качестве нац. стандартов? Я извиняюсь, если такое было и я не заметил.

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

[Eldar Ishimbaev]

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

[RustamQE]

Подходы существуют, но кто дасть гарантию, того что в обе стороны пользователи используют один и тот же способ?

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


Для чего тогда протоколы существуют. Стандарты это только начало работ. Хоть американские хоть российские, все стандарты используют как минимум два параметра: входные данные (блок), и ключ. Но вопрос формирования ключа это уже второй вопрос. Точно также можно использовать и нац.стандарт. Это зависить от используемого протокола. Ключ можно также сформировать на основе входных данных.

Я потерялся. Не уточните какой стандарт вы имеете ввиду, когда говорите "Хоть американские хоть российские, все стандарты используют как минимум два параметра: входные данные (блок), и ключ"?

В зависимости от этого будем двигаться дальше...

Я имел ввиду в целом всех стандартов по крипто. Но если конкретно к SHA-1 , то здесь в качестве ключа используется постоенное число К. Просто его не называют ключом, а просто константой.
Что мешает например группе пользователей использовать один и тот же ключ хеширования в нац. стандарте, эффект тот же как и в SHA.

[shumbola]

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

[RustamQE]

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

Всячески приветствую нац. стандарты, но они должны быть хотябы не хуже других. А было ли широкое обсуждение (среди специалистов, конечно), прежде чем принимались в качестве нац. стандартов? Я извиняюсь, если такое было и я не заметил.

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

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

[shumbola]

Я имел ввиду в целом всех стандартов по крипто. Но если конкретно к SHA-1 , то здесь в качестве ключа используется постоенное число К. Просто его не называют ключом, а просто константой.
Что мешает например группе пользователей использовать один и тот же ключ хеширования в нац. стандарте, эффект тот же как и в SHA.

Ок, теперь понятно. Скажите, а от использования одного и того же ключа хеширования не меняеться криптостойкость функции хеширования?
Если указывать в сертификате ключа, ключ хеширования, как было сказано выше, где именно указывать его? Я что-то не увидел ничего насчет этого в стандарте ЭЦП.

И еще, маленькая просьба :icon_wink: Не могли ли вы для ознакомления прислать мне тестовый сертификат, который выдан вашей программой?

Но на основе национальных стандартов шифрования (18 Мбит/сек) и ЭЦП мы реализовали проекты для ГНК, внедрили криптопровайдер для защищенной электронной почты и электронного документооборота.

[shumbola]

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

[RustamQE]

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

Обсуждения этих стандартов (проектов) идет уже в течении 5 лет. Три раза был сделан доклад в Санкт -Петербурге перед сильными специалистами. Многократно в Уз, публиковались в различных специализированных журналах. Но если Вы считаете себя специалистом криптографом и можете дать конкретные предложения рекомендую Вам обращаться к проф. Хасанова П. Он работает в ЦНТМИ адрес: Напротив государственного тестового Центра недоезжая мачети Бадамзор.

[RustamQE]

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

Я такой же разработчик как Вы. Все инфо про диаматрицу получил от проф. Хасанова. Но могу сказать что в Журнале Инфоком , Проблемы Кибернетики, Алока дунёси и др есть очень интересные материалы. В сети раньше встречал но сейчась незнаю надо искать по ключевым словам. Я находил раньше и в российских сайтах тоже. А насчет сертификата куда отправить? Данный сертификат тестовый и в нем непредусмотрен нац. алгоритм хеширования. В наших системах внедрен российский ГОСТ. Если будет дан добро от соответствующего органа то ключ будем размещать где указан параметр "Открытый ключ". При этом разработчики должны знать какая часть ключа используется для ЭЦП а какая для хеширования.

[shumbola]

Я такой же разработчик как Вы. Все инфо про диаматрицу получил от проф. Хасанова. Но могу сказать что в Журнале Инфоком , Проблемы Кибернетики, Алока дунёси и др есть очень интересные материалы. В сети раньше встречал но сейчась незнаю надо искать по ключевым словам. Я находил раньше и в российских сайтах тоже.

Что-то ничего толкового не могу найти.

А насчет сертификата куда отправить? Данный сертификат тестовый и в нем непредусмотрен нац. алгоритм хеширования. В наших системах внедрен российский ГОСТ. Если будет дан добро от соответствующего органа то ключ будем размещать где указан параметр "Открытый ключ". При этом разработчики должны знать какая часть ключа используется для ЭЦП а какая для хеширования.

Спасибо, но я хотел бы получить тестовый сертификат именно с узбекским стандартом. ГОСТ и др. не интерсны. :) Если что, отправьте на shumbola2004 sobachka yahoo.com

[RustamQE]

Я такой же разработчик как Вы. Все инфо про диаматрицу получил от проф. Хасанова. Но могу сказать что в Журнале Инфоком , Проблемы Кибернетики, Алока дунёси и др есть очень интересные материалы. В сети раньше встречал но сейчась незнаю надо искать по ключевым словам. Я находил раньше и в российских сайтах тоже.

Что-то ничего толкового не могу найти.


А насчет сертификата куда отправить? Данный сертификат тестовый и в нем непредусмотрен нац. алгоритм хеширования. В наших системах внедрен российский ГОСТ. Если будет дан добро от соответствующего органа то ключ будем размещать где указан параметр "Открытый ключ". При этом разработчики должны знать какая часть ключа используется для ЭЦП а какая для хеширования.

Спасибо, но я хотел бы получить тестовый сертификат именно с узбекским стандартом. ГОСТ и др. не интерсны. :) Если что, отправьте на shumbola2004 sobachka yahoo.com

На счет источников посмотрю

ЭЦП и шифрования на основе нац. стандарта и сертификат тоже, только хеш российский.

[RustamQE]

Я имел ввиду в целом всех стандартов по крипто. Но если конкретно к SHA-1 , то здесь в качестве ключа используется постоенное число К. Просто его не называют ключом, а просто константой.
Что мешает например группе пользователей использовать один и тот же ключ хеширования в нац. стандарте, эффект тот же как и в SHA.

Ок, теперь понятно. Скажите, а от использования одного и того же ключа хеширования не меняеться криптостойкость функции хеширования?
Если указывать в сертификате ключа, ключ хеширования, как было сказано выше, где именно указывать его? Я что-то не увидел ничего насчет этого в стандарте ЭЦП.

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

В стандартах ЭЦП это непредусматривается. Но в стандарте Х.809 (Состав сертификата ключа) указаны как необходимо представить открытые ключи в сертификатах.

[shumbola]

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

В стандартах ЭЦП это непредусматривается. Но в стандарте Х.809 (Состав сертификата ключа) указаны как необходимо представить открытые ключи в сертификатах.

Скорее всего опечатка и вы имели ввиду Х509.

Хмм...мне кажется мы до сих пор друг-друга не поняли. Я говорю про ключ хеширования, который приведен в нац. стандарте хеширования, а вы мне про открытый ключ ЭЦП.

[Erkin Kuchkarov]

Хмм...мне кажется мы до сих пор друг-друга не поняли. Я говорю про ключ хеширования, который приведен в нац. стандарте хеширования, а вы мне про открытый ключ ЭЦП.
Тема Вас интересует как разработчика или любопытства для? ;)

[shumbola]

Хмм...мне кажется мы до сих пор друг-друга не поняли. Я говорю про ключ хеширования, который приведен в нац. стандарте хеширования, а вы мне про открытый ключ ЭЦП.
Тема Вас интересует как разработчика или любопытства для? ;)

Ну вы же понимаете, без любопытства и разработки нет. ;)

[RustamQE]

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

В стандартах ЭЦП это непредусматривается. Но в стандарте Х.809 (Состав сертификата ключа) указаны как необходимо представить открытые ключи в сертификатах.

Скорее всего опечатка и вы имели ввиду Х509.

Хмм...мне кажется мы до сих пор друг-друга не поняли. Я говорю про ключ хеширования, который приведен в нац. стандарте хеширования, а вы мне про открытый ключ ЭЦП.

Я Вас понимаю, но Вы не до конца разобрались составом сертификата ключа. В сертификате ключа имеется инфо не только об открытых ключах ЭЦП, там также отображаются открытые ключи для системы обмена ключами (например DH) и для функции хеширования.

[RustamQE]

Что-то ничего толкового не могу найти.
Вот то что у меня имеется, мне представил проф. Хасанов П. Самое главное хорошие намерения, после чего он не откажет помогать.
Рекомендую начинать с первого источника:

1. Хасанов П.Ф. Фигурно-точечные модели и диаопределители матриц 1975
2. Исаев Р.И., Хасанов П.Ф., Хасанов Х.П. О государственном стандарте Республики Узбекистан О’z Dst 1092:2005 Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи// Актуальные проблемы создания системы удостоверяющих центров России. Аспекты международного сотрудничества в области ЭЦП: Тез. докл. международной научно – практическая конференции PKI Forum- 2005, Санкт-Петербург 8-10 ноября. (в Инете есть )
3. Хасанов Х. Диаматрица устунлар ва параметрлар алгебраси. Кибернетика масалалари. 173-сон, 2006 . 93-100 б.
4. Хасанов Х. Махсус ва содда тузилмали диаматрицалар. Информатика ва энергетика муаммолари. 4-5 сон, 2005, 71-76 б.
5. Хасанов Х. Такомиллаштирилган диаматрицалар алгебраси. Infocom.uz. 9-сон 2005, 68-70 бетлар.
6. Хасанов Х.П. Диаматрицалар алгебралари асосида симметрик ва носимметрик криптотизимлар яратиш усуллари ва алгоритмлари// Состояние и перспективы развития связи и информационных технологий Узбекистана: Доклады и тезисы междунар.конференции 11-12 мая 2005 г. Ташкент -2005. -50 б.
7. Хасанов Х.П. Мавжуд криптоалгоритмларни параметрлар алгебраси асосида такомиллаштиришнинг умумий усули // Информационная безопасность в сфере связи и информатизации: Тезисы докл. респ. сем. 24 ноября 2005. – Ташкент 2005. 22-24 б.

[shumbola]

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

В стандартах ЭЦП это непредусматривается. Но в стандарте Х.809 (Состав сертификата ключа) указаны как необходимо представить открытые ключи в сертификатах.

Скорее всего опечатка и вы имели ввиду Х509.

Хмм...мне кажется мы до сих пор друг-друга не поняли. Я говорю про ключ хеширования, который приведен в нац. стандарте хеширования, а вы мне про открытый ключ ЭЦП.

Я Вас понимаю, но Вы не до конца разобрались составом сертификата ключа. В сертификате ключа имеется инфо не только об открытых ключах ЭЦП, там также отображаются открытые ключи для системы обмена ключами (например DH) и для функции хеширования.

Ну вот поэтому я вас прошу прислать мне пример, тестовый сертификат. Все мои вопросы отпали бы ;)

[RustamQE]

Скорее всего опечатка и вы имели ввиду Х509.

Хмм...мне кажется мы до сих пор друг-друга не поняли. Я говорю про ключ хеширования, который приведен в нац. стандарте хеширования, а вы мне про открытый ключ ЭЦП.

Я Вас понимаю, но Вы не до конца разобрались составом сертификата ключа. В сертификате ключа имеется инфо не только об открытых ключах ЭЦП, там также отображаются открытые ключи для системы обмена ключами (например DH) и для функции хеширования.

Ну вот поэтому я вас прошу прислать мне пример, тестовый сертификат. Все мои вопросы отпали бы ;)
Отправил