Моё меню Общее меню Пользователи Правила форума Все прочитано
Вернуться   uForum.uz > ИКТ и телеком > Информационная безопасность > ЭЦП
Знаете ли Вы, что ...
...нарушения правил форума наказываются. Старайтесь их не нарушать.
<< Предыдущий совет - Случайный совет - Следующий совет >>

ЭЦП Электронно-цифровая подпись. Вопросы криптографии тоже пока сюда. Pki.uz


Ответить

 
Опции темы Опции просмотра
Старый 03.12.2007 16:36   #21  
Аватар для shumbola
Оффлайн
Сообщений: 3,327
+ 337  892/590
– 3  31/25

Uzbekistan
Цитата:
Вы наверняка ошибаетесь такого требования к алгоритмам хеширования не существует и тем более простое число не может быть четным. :-)
Ранее было сказано когда хеширование используется в ИОК ключ выдается на определнный срок и нет
необходимости генерации ключа при каждом сеансе (см. далее).
Да согласен, считайте что ошибка вкралась. Конечно, я имел ввиду четное натуральное число. Вот цитата непосредственно из стандарта:
Цитата:
5.1.2 Первоначальный этапный ключ ke формируется из линейного массива
ключа хэширования k на полубайт(байт)овом уровне второй полубайт(байт) которого
должен быть четным натуральным числом.
Ответить 
Реклама и уведомления
Старый 03.12.2007 16:52   #22  
Аватар для RustamQE
Оффлайн
IntSoft Service
Manager
Сообщений: 29
+ 0  2/2
– 0  0/0

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

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

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

Цитата:
Сообщение от Rustam Yunusov Посмотреть сообщение
4. Зависит ли от ключа хеширования конечный результат?
Да. Конечный результат хеширования зависит от ключа хеширования. При изменении хотя бы одного бита ключа хеширования полностью меняется хешированное сообщение то есть должен происходить "лавинный эффект".
Цитата:
Сообщение от shumbola Посмотреть сообщение
А есть ли какие-либо результаты по скорости алгоритма функции хеширования? Есть ли исследования на предмет колллизий? И где обо всем этом можно почитать? Кроме как в стандарте, где мне кажется имеются неточности с примерами.
Зачем изменять ключ хеширования он же открытый. Но при изменении ключа так и должно быть, должен изменятся значении хеш функции. Наша компания впервые в Уз разработала систему на основе национальных алгоритмов. Скорость ФХ около 80 Мбит/сек, при Селерон 1.7 256 МБ ОЗУ. Но мы не выставили его на продажу, так как функцией хеширования не доконца все решена. Но на основе национальных стандартов шифрования (18 Мбит/сек) и ЭЦП мы реализовали проекты для ГНК, внедрили криптопровайдер для защищенной электронной почты и электронного документооборота.
Ответить 
Старый 03.12.2007 16:52   #23  
Аватар для shumbola
Оффлайн
Сообщений: 3,327
+ 337  892/590
– 3  31/25

Uzbekistan
Цитата:
Вопрос сформулирован не правильно и могут быть недоразумения при формулировке ответа на данный вопрос, поэтому прошу Вас правильно сформулировать вопрос и мы постараемся удовлетворить Ваши требования.
А теперь прочитайте ваш ответ:
Цитата:
2. Можно ли использовать постоянный ключ?
Можно. В инфраструктуре открытых ключей (ИОК) используется хеширования со сроком действия не менее пяти лет.
Ответить 
Старый 03.12.2007 16:58   #24  
Аватар для shumbola
Оффлайн
Сообщений: 3,327
+ 337  892/590
– 3  31/25

Uzbekistan
Цитата:
Цитата:
А где хранить ключ хеширования в парольной защите? Не удобно ей богу, недобно
Ключ хеширования не обязательно где-то хранить. Существуют много подходов для получения ключа
хеширования. Один из этих подходов это в качестве ключа хеширования использовать сам пароль и с помощью него же хешировать пароль и полученное хеш значение сравнивать с хранимым в компьютере хеш-значением.
Подходы существуют, но кто дасть гарантию, того что в обе стороны пользователи используют один и тот же способ?

Заметьте, для к примеру, SHA1 я ничего нигде не храню. Я подаю во вход данные и в выходе получаю фиксированное значение хеша (20байт). А тут мне еще и нужно подумать о ключе хеширования.
Ответить 
Старый 03.12.2007 17:11   #25  
Аватар для shumbola
Оффлайн
Сообщений: 3,327
+ 337  892/590
– 3  31/25

Uzbekistan
Цитата:
В ИОК хеширование используется для сжатия сообщения и далее использовать ЭЦП ( X.509 или O'zDSt 1108-2006). Сжатие используется для того чтобы алгоритм ЭЦП быстро ставил подпись и для обеспечения сервиса безотказность от авторства (non-repudiation).
А вы уверены в этом? Вообще, non-repudiation немного другое понятие, и она базируется на факте что, только один единственный пользователь секретного ключа имеет доступ к этому ключу.
Ответить 
Старый 03.12.2007 17:16   #26  
Аватар для shumbola
Оффлайн
Сообщений: 3,327
+ 337  892/590
– 3  31/25

Uzbekistan
Цитата:
Алгоритм хеширования модифицирован и внего внесены изменения повышающие его стойкость к коллизии.
Информацию можно получить в статье опубликованной в журнале Инфокоммуникации: Сети, Технологии, Решения №3, 2007 г. авторами функции хеширования.
А где можно получить доступ к этому журналу? Есть в Сети электронный вариант?
Ответить 
Старый 03.12.2007 17:17   #27  
Аватар для shumbola
Оффлайн
Сообщений: 3,327
+ 337  892/590
– 3  31/25

Uzbekistan
Цитата:
Пожалуйста формулируйте вопросы корректно чтобы не было недоразумений в будущем.
Взаимно.
Ответить 
Старый 03.12.2007 17:24   #28  
Аватар для shumbola
Оффлайн
Сообщений: 3,327
+ 337  892/590
– 3  31/25

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

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

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

И не могли бы здесь уточнить, что именно не решено "функцией хеширования не доконца все решена"? Спасибо.
Ответить 
Реклама и уведомления
Старый 03.12.2007 17:34   #29  
Аватар для RustamQE
Оффлайн
IntSoft Service
Manager
Сообщений: 29
+ 0  2/2
– 0  0/0

Uzbekistan
Цитата:
Сообщение от shumbola Посмотреть сообщение
Цитата:
Цитата:
А где хранить ключ хеширования в парольной защите? Не удобно ей богу, недобно
Ключ хеширования не обязательно где-то хранить. Существуют много подходов для получения ключа
хеширования. Один из этих подходов это в качестве ключа хеширования использовать сам пароль и с помощью него же хешировать пароль и полученное хеш значение сравнивать с хранимым в компьютере хеш-значением.
Подходы существуют, но кто дасть гарантию, того что в обе стороны пользователи используют один и тот же способ?

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

Для чего тогда протоколы существуют. Стандарты это только начало работ. Хоть американские хоть российские, все стандарты используют как минимум два параметра: входные данные (блок), и ключ. Но вопрос формирования ключа это уже второй вопрос. Точно также можно использовать и нац.стандарт. Это зависить от используемого протокола. Ключ можно также сформировать на основе входных данных.
Ответить 
Старый 03.12.2007 17:47   #30  
Аватар для shumbola
Оффлайн
Сообщений: 3,327
+ 337  892/590
– 3  31/25

Uzbekistan
Цитата:
Сообщение от RustamQE Посмотреть сообщение
Цитата:
Сообщение от shumbola Посмотреть сообщение
Цитата:

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

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

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

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




Powered by vBulletin® Version 3.8.5
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. Перевод: zCarot
Advertisement System V2.5 By Branden
OOO «Единый интегратор UZINFOCOM»


Новые 24 часа Кто на форуме Новички Поиск Кабинет Все прочитано Вверх