Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| |
Там же еще вопрос про ЭЦП был. 12.11.03 08:43 Число просмотров: 1338
Автор: cybervlad <cybervlad> Статус: Elderman
|
> А вот почему во многих системах электронная подпись
> интересно реализована, меня самого вопрос давно мучил. То
> есть почему ЭЦП накладывается не на весь текст, а только на
> хеш и приписывается в конце открытого сообщения?
Дополню объяснение dl.
Кроме скорости у несимметричных алгоритмов есть еще одни грабли: они работают с данными фиксированного размера, а файл (пакет, сообщение и т.п.) в общем случае имеет размер произвольный. Посему перед вычислением ЭЦП от сообщения считают хеш (hash), который из набора данных произвольной длины делает число фиксированной длины. Для отечественных ГОСТов Р 34.10/34.11 размерность хеша - 256 бит (32 байта).
Кстати, она "волшебным образом" совпадает с длиной ключа для ГОСТ 28147, что позволяет легко формировать ключ шифрования из пароля путем его (пароля) хеширования.
Обязательным свойством такого (криптографического) хеша является хорошая зависимость (т.е. даже небольшое изменение в хешируемом файле должно повлечь сильные изменения в хеше) и устойчивость к колиизиям (подобрать исходный текст под заданный хеш можно только полным перебором, хотя очевидно, что при размере текста превышающем размер хеша, для одного хеша в природе существует несколько текстов).
Часто задаваемые вопросы конференции RU.CRYPT (формат ZIP, кодировка текста DOS, cp866).
|
|
<miscellaneous>
|
RSA, novell etc (2 whiletrue) 11.11.03 16:12
Автор: cybervlad <cybervlad> Статус: Elderman
|
> "... Alice computes private_key=R2 XOR Z. This key is used to sign packets... "
> Не знал. Ошибку свою понял.
> Хотя в RSA подпись - это же зашифрованный дайджест. Почему бы и не
> шифровать все сообщение?! Скорость?
В ncp packet signature работает не RSA, а симметричный алгоритм, т.е. это фактически HMAC (контрольная сумма с секретом).
Насчет шифрования всего сообщения. Во-первых, нафиг делать это на уровне прикладного протокола, когда гораздо проще это делать на уровне IP? Во-вторых, когда этот протокол был придуман, у компов еще не хватало мощи шифровать весть трафик. Ну, и в-третьих, нетварь все-таки родилась как файловый сервер для ЛВС, so необходимость в шифровании там сомнительна. А сейчас уже есть куча VPN-решений, нафига встраивать это в прикладной протокол ОС?
|
|
10x за разъяснения. 11.11.03 20:51
Автор: whiletrue <Роман> Статус: Elderman
|
|
Только вот насчет шифрования внутри локалки: Если данные не шифровать. А зачем тогда все эти пароли? Зачем сохранность паролей? Вумный юзер также поснифает трафик, получит доступ к закрытым данным, продаст секреты конкурирующей фирме... Какой вообще смысел в этих наворотах, почему пароли и плайн-текстом не передавать? Если уж додумаются снифать, то, наверняка и дальше пойдут...
|
| |
10x за разъяснения. 12.11.03 08:51
Автор: cybervlad <cybervlad> Статус: Elderman
|
> Только вот насчет шифрования внутри локалки: Если данные не
> шифровать. А зачем тогда все эти пароли? Зачем сохранность
> паролей? Вумный юзер также поснифает трафик, получит доступ
> к закрытым данным, продаст секреты конкурирующей фирме...
> Какой вообще смысел в этих наворотах, почему пароли и
> плайн-текстом не передавать? Если уж додумаются снифать,
> то, наверняка и дальше пойдут...
Даю справку ;)
При снифаньи нелояльный сотрудник может только читать информацию, но не может ее подменить/исправить. Если же он отловит пароль, он может зайти с правами соответствующего юзера и информацию поправить/попортить/удалить. Причем, в логах все стрелки будут на юзера, с чьим именем он заходил. Если же не передавать пароль в открытом виде, а использовать 3-шаговый хендшейк, то сниффер получит лишь данные для криптоанализа, с которыми будет возиться очень долго, если пароль выбран правильный. Для версии NetWare 3.х я делал анализ:
http://www.free-unices.org/~cybervlad/nwpass/index.html (версия для журнала)
или
http://www.free-unices.org/~cybervlad/nwpass/netware.pdf (полная версия с текстом программы).
С версии 4 и выше все это дополнительно прикрывается сверху RSA, но это не страшно для аналитика, поскольку используются не сертификаты, а ключи, соответственно, можно реализовать MiTM и свести сложность задачи к вскрытию хендшейка nw3.x
|
|
Там же еще вопрос про ЭЦП был. 11.11.03 16:25
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 11.11.03 16:26 Количество правок: 1
|
> > "... Alice computes private_key=R2 XOR Z. This key is
> used to sign packets... "
> > Не знал. Ошибку свою понял.
> > Хотя в RSA подпись - это же зашифрованный дайджест.
> Почему бы и не
> > шифровать все сообщение?! Скорость?
> В ncp packet signature работает не RSA, а симметричный
> алгоритм, т.е. это фактически HMAC (контрольная сумма с
> секретом).
Про то, что сетевой операционке совершенно не надо шифровать трафик в локалке, это понятно. Типа шифруем сви данные от себя самого и, при этом, сильно тормозим.
А вот почему во многих системах электронная подпись интересно реализована, меня самого вопрос давно мучил. То есть почему ЭЦП накладывается не на весь текст, а только на хеш и приписывается в конце открытого сообщения?
|
| |
Там же еще вопрос про ЭЦП был. 12.11.03 08:43
Автор: cybervlad <cybervlad> Статус: Elderman
|
> А вот почему во многих системах электронная подпись
> интересно реализована, меня самого вопрос давно мучил. То
> есть почему ЭЦП накладывается не на весь текст, а только на
> хеш и приписывается в конце открытого сообщения?
Дополню объяснение dl.
Кроме скорости у несимметричных алгоритмов есть еще одни грабли: они работают с данными фиксированного размера, а файл (пакет, сообщение и т.п.) в общем случае имеет размер произвольный. Посему перед вычислением ЭЦП от сообщения считают хеш (hash), который из набора данных произвольной длины делает число фиксированной длины. Для отечественных ГОСТов Р 34.10/34.11 размерность хеша - 256 бит (32 байта).
Кстати, она "волшебным образом" совпадает с длиной ключа для ГОСТ 28147, что позволяет легко формировать ключ шифрования из пароля путем его (пароля) хеширования.
Обязательным свойством такого (криптографического) хеша является хорошая зависимость (т.е. даже небольшое изменение в хешируемом файле должно повлечь сильные изменения в хеше) и устойчивость к колиизиям (подобрать исходный текст под заданный хеш можно только полным перебором, хотя очевидно, что при размере текста превышающем размер хеша, для одного хеша в природе существует несколько текстов).
Часто задаваемые вопросы конференции RU.CRYPT (формат ZIP, кодировка текста DOS, cp866).
|
| | |
Понял, понял. 12.11.03 10:03
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 12.11.03 10:05 Количество правок: 1
|
> Дополню объяснение dl.
Про скорость в общем-то понятно. Я, правда, думал про подпись электронных документов, а не трафика, для которого скорость особенно критична, но все-равно это весомый аргумент.
> Кроме скорости у несимметричных алгоритмов есть еще одни
> грабли: они работают с данными фиксированного размера, а
> файл (пакет, сообщение и т.п.) в общем случае имеет размер
> произвольный. Посему перед вычислением ЭЦП от сообщения
> считают хеш (hash), который из набора данных произвольной
> длины делает число фиксированной длины. Для отечественных
Подобное и хотелось услышать. Правда можно выравнивать данные в сторону бОльшего размера добавляя что-нибудь в конец. Я думал, что могут быть еще какие-нибудь веские причины. Впрочем и этих двух достаточно.
> является хорошая зависимость (т.е. даже небольшое изменение
> в хешируемом файле должно повлечь сильные изменения в хеше)
> и устойчивость к колиизиям (подобрать исходный текст под
> заданный хеш можно только полным перебором, хотя очевидно,
> что при размере текста превышающем размер хеша, для одного
> хеша в природе существует несколько текстов).
Ну да, вероятность подбора второго текста для этого же хеша слишком мала. Поэтому этот контраргумент просто невелируется увеличением скорости и упрощением подгонки размера блока.
|
| |
Там же еще вопрос про ЭЦП был. 11.11.03 19:34
Автор: dl <Dmitry Leonov>
|
> Про то, что сетевой операционке совершенно не надо
> шифровать трафик в локалке, это понятно. Типа шифруем сви
> данные от себя самого и, при этом, сильно тормозим.
> А вот почему во многих системах электронная подпись
> интересно реализована, меня самого вопрос давно мучил. То
> есть почему ЭЦП накладывается не на весь текст, а только на
> хеш и приписывается в конце открытого сообщения?
Асимметричные алгоритмы вообще очень медленно работают, поэтому всегда стараются сократить объем данных, которые им подсовывают. Собсно говоря, в чистом виде шифрование открытым ключомсообщенийпочти никогда не используется - открытым ключом шифруется сессионный ключ для какого-нибудь симметричного алгоритма, который потом передается вместе с сообщением. С подписью аналогичная ситуация.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
