взять книгу Шнайера Прикладная криптография и прочитать там всё, что
про MAC и HMAC написано. Дабы представлять себе ограничения
применимости решений на их базе.
+1 Отличнейшая книга, присоединяюсь к совету. Правдо в своей второй(?)
книге он указал на массу её недостатков, но это отнюдь не
On 2007.06.22 at 20:02:58 +0400, Ed wrote:
меня вполне устраивает то, что никто кроме этих двух не мог
сгенерировать это сообщение
подводя итог - HMAC хороший выбор?
или смотреть на что-то другое? на что тогда?
Вполне приемлимый. TLS его используует, OpenVPN использует,
и ещё много
В сообщении от 22 Июнь 2007 10:49 Ed написал(a):
схема:
отправитель - небезопасный канал (интернет) - получатель
я контролирую и отправителя и получателя.
данные несекретные, шифровать их особого смысла нет. но получатель
должен убедиться, что данные отправил действительно отправитель.
Twas brillig at 11:11:44 22.06.2007 UTC+04 when Max Dmitrichenko did gyre and
gimble:
MD Ну и правильно. Получается, что ключ у тебя в открытом виде передается,
MD враг берет вставляет свое сообщение, приделывает этот же ключ и генерирует
MD по такому же алгоритму хэш. А теперь пойми где
В сообщении от 22 Июнь 2007 11:15 Mikhail Gusarov написал(a):
Twas brillig at 11:11:44 22.06.2007 UTC+04 when Max Dmitrichenko did gyre and
gimble:
MD Ну и правильно. Получается, что ключ у тебя в открытом виде передается,
MD враг берет вставляет свое сообщение, приделывает этот же ключ
В сообщении от 22 Июнь 2007 11:29 Ed написал(a):
Max Dmitrichenko wrote:
Ну и правильно. Получается, что ключ у тебя в открытом виде передается,
враг берет вставляет свое сообщение, приделывает этот же ключ и генерирует
по такому же алгоритму хэш. А теперь пойми где подделка.
я
On 6/22/07, Mikhail Gusarov [EMAIL PROTECTED] wrote:
Twas brillig at 11:11:44 22.06.2007 UTC+04 when Max Dmitrichenko did gyre and
gimble:
MD Ну и правильно. Получается, что ключ у тебя в открытом виде передается,
MD враг берет вставляет свое сообщение, приделывает этот же ключ и генерирует
Max Dmitrichenko wrote:
Даже если так, то получается, что реципиент может создавать сообщения от имени
автора. Что в общем не универсально, поскольку необходимость уверено получать
сообщения от всех абонентов возникает чаще, чем уверено получать сообщения от
абонента, который безусловно доверяет
On Fri, Jun 22, 2007 at 10:49:58AM +0400, Ed wrote:
из минусов пока вижу только
необходимость безопасно доставить ключ
на обе стороны - но в данном случае это
проблемы не представляет.
а с точки зрения криптостойкости - хуже
этот вариант обычной подписи (afaik
формируем хэш и
В сообщении от 22 Июнь 2007 14:28 Иван Лох написал(a):
On Fri, Jun 22, 2007 at 10:49:58AM +0400, Ed wrote:
из минусов пока вижу только
необходимость безопасно доставить ключ
на обе стороны - но в данном случае это
проблемы не представляет.
а с точки зрения криптостойкости - хуже
On Fri, Jun 22, 2007 at 03:20:42PM +0400, Max Dmitrichenko wrote:
В сообщении от 22 Июнь 2007 14:28 Иван Лох написал(a):
On Fri, Jun 22, 2007 at 10:49:58AM +0400, Ed wrote:
Для одноразового ключа и большого количества
сообщений IMHO хуже. С каждым перехваченным
сообщением ключ становится
Фигурный subject. Это интересно у меня evo чудит или kmail и так
кодировать не положено?
--
Alexander Vlasov
ZULU-UANIC
JID: zulu at jabber.kiev.ua
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Fri, 22 Jun 2007 10:49:58 +0400, Ed [EMAIL PROTECTED]:
схема:
отправитель - небезопасный канал (интернет) - получатель
я контролирую и отправителя и получателя.
данные несекретные, шифровать их особого смысла нет. но получатель
должен убедиться, что данные отправил действительно
On 2007.06.22 at 10:49:58 +0400, Ed wrote:
я контролирую и отправителя и получателя.
данные несекретные, шифровать их особого смысла нет. но получатель
должен убедиться, что данные отправил действительно отправитель.
чем плохо поступить так - заранее сгенерировать ключ (просто
jetxee wrote:
В этом случае вообще можно наладить полностью секретный
канал между отправителем и получателем средствами симметричного
шифрования, и считать всё, полученное по этому каналу, «надёжным».
Необходимость в подписях в этом случае отпадает.
по размышлению мне этот вариант нравится
15 matches
Mail list logo
