Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
������ �� Man-in-the-middle
4 views
Skip to first unread message
Yuri Myakotin
Apr 3, 2015, 5:55:02 AM4/3/15
to
Hello All!
Имеем: соединение, использующее Curve25519 обмен ключами для получения session
shared key.
Достаточно ли будет для предотвращения MITM атаки дополнительной подписи (да
хоть тем же Ed25519) для открытого сессионного ключа ОТВЕЧАЮЩЕЙ стороны? Дабы
вызывающая сторона, знающая постоянный паблик кей отвечающей, могла
удостовериться, что данные для получения сессионного ключа отправлены
действительно отвечающей стороной, а не кем-то посредине?
See all in Hell,
Yuri
Имеем: соединение, использующее Curve25519 обмен ключами для получения session
shared key.
Достаточно ли будет для предотвращения MITM атаки дополнительной подписи (да
хоть тем же Ed25519) для открытого сессионного ключа ОТВЕЧАЮЩЕЙ стороны? Дабы
вызывающая сторона, знающая постоянный паблик кей отвечающей, могла
удостовериться, что данные для получения сессионного ключа отправлены
действительно отвечающей стороной, а не кем-то посредине?
See all in Hell,
Yuri
Serguei E. Leontiev
Apr 3, 2015, 8:55:12 PM4/3/15
to
Привет Юрий,
От 3 апреля 2015 г., 12:37:32 в fido7.ru.crypt ты писал:
YM> Имеем: соединение, использующее Curve25519 обмен ключами для
YM> получения session shared key.
YM> Достаточно ли будет для предотвращения MITM атаки
YM> дополнительной подписи (да хоть тем же Ed25519) для открытого
YM> сессионного ключа ОТВЕЧАЮЩЕЙ стороны? Дабы вызывающая сторона,
YM> знающая постоянный паблик кей отвечающей, могла удостовериться,
YM> что данные для получения сессионного ключа отправлены
YM> действительно отвечающей стороной, а не кем-то посредине?
Ответ: нет, "подписи для открытого сессионного ключа ОТВЕЧАЮЩЕЙ стороны"
недостаточно.
Поясню, сессия это не только ключ, это совокупность правильных,
допустимых ключей, сторон, момента и т.п.
А нарушитель не обязан просто и тупо пихать свой открытый ключ,
например, он может перехватывать сессию и т.д. и т.п.
Да и использование подписей сторон, на мой взгляд, это пустая трата энергии.
Юрий, мне кажется, что тебе полезно проштудировать какой-нибудь учебник,
в котором изложено что-то большее, чем "школьная" криптография,
например, Венбо Мао "Современная криптография".
А также, ещё раз напоминаю, надёжные алгоритмы уже есть, например:
ISO/IEC 11770-3, IKEv1, IKEv2. Рекомендую, прочитать, понять и
использовать алгоритмы согласования ключей описанные в одном из этих
стандартов.
--
Успехов, Сергей Леонтьев. E-mail: l...@CryptoPro.ru
От 3 апреля 2015 г., 12:37:32 в fido7.ru.crypt ты писал:
YM> Имеем: соединение, использующее Curve25519 обмен ключами для
YM> получения session shared key.
YM> Достаточно ли будет для предотвращения MITM атаки
YM> дополнительной подписи (да хоть тем же Ed25519) для открытого
YM> сессионного ключа ОТВЕЧАЮЩЕЙ стороны? Дабы вызывающая сторона,
YM> знающая постоянный паблик кей отвечающей, могла удостовериться,
YM> что данные для получения сессионного ключа отправлены
YM> действительно отвечающей стороной, а не кем-то посредине?
Ответ: нет, "подписи для открытого сессионного ключа ОТВЕЧАЮЩЕЙ стороны"
недостаточно.
Поясню, сессия это не только ключ, это совокупность правильных,
допустимых ключей, сторон, момента и т.п.
А нарушитель не обязан просто и тупо пихать свой открытый ключ,
например, он может перехватывать сессию и т.д. и т.п.
Да и использование подписей сторон, на мой взгляд, это пустая трата энергии.
Юрий, мне кажется, что тебе полезно проштудировать какой-нибудь учебник,
в котором изложено что-то большее, чем "школьная" криптография,
например, Венбо Мао "Современная криптография".
А также, ещё раз напоминаю, надёжные алгоритмы уже есть, например:
ISO/IEC 11770-3, IKEv1, IKEv2. Рекомендую, прочитать, понять и
использовать алгоритмы согласования ключей описанные в одном из этих
стандартов.
--
Успехов, Сергей Леонтьев. E-mail: l...@CryptoPro.ru
Yuri Myakotin
Apr 4, 2015, 2:15:02 AM4/4/15
to
Hello Serguei!
Saturday April 04 2015 03:55, Serguei E. Leontiev wrote to Yuri Myakotin:
SL> Ответ: нет, "подписи для открытого сессионного ключа ОТВЕЧАЮЩЕЙ
SL> стороны" недостаточно.
SL> Поясню, сессия это не только ключ, это совокупность правильных,
SL> допустимых ключей, сторон, момента и т.п.
Речь идет о самом первом этапе сессии: две стороны "договариваются" о сеансовых
ключах шифрования. Вызывающая сторона знает, кого она вызывает, открытый ключ
сервера у нее есть. Соответственно, проверяется, подписаны ли передаваемые
сервером в самом начале данные его ключом, или кто-то влез посредине. Смысл в
том, что при наличии злоумышленника либо подпись будет неверной, либо
подмененные данные для ключа не совпадут и защищенной сессии все равно не
получится.
SL> А нарушитель не обязан просто и тупо пихать свой открытый ключ,
SL> например, он может перехватывать сессию и т.д. и т.п.
Вот как раз о перехвате сессии и речь.
Алгоритм сессии в моем случае:
1) стороны шлют друг другу информацию о используемых ими версиях протокола.
2) Каждая из сторон генерит рандомный ключ, получает из него открытый ключ и
отсылает этот открытый ключ другой стороне. Отвечающая сторона дополнительно
добавляет подпись этого открытого ключа своим постоянным ключом, открытая часть
которого известна вызывающей стороне.
3) Вызывающая сторона проверяет соответствие подписи, если она не соответствует
- обрывает соединение.
4) Стороны из своих секретных и и полученных от другой стороны ключей
генерируют общие ключи шифрования сессии и переходят в шифрованный режим.
5) дальше уже в шифрованном виде идет аутентификация/авторизация сторон и обмен
данными.
Влезание MITM в этой схеме приводит либо к непрохождению проверки в пункте 3,
либо к тому, что в пункте 4 ключи у сервера и клиента окажутся разными, т.е.
сесии все равно не получится, вместо данных в пункте 5 одна из сторон получит
абракадабру и оборвет соединение. Либо к тому, что MITM вынужден будет просто
ретранслировать данные пунктов 1-2 без изменений, и, начиная с пункта 5 -
прочитать ничего не сможет :)
Saturday April 04 2015 03:55, Serguei E. Leontiev wrote to Yuri Myakotin:
SL> Ответ: нет, "подписи для открытого сессионного ключа ОТВЕЧАЮЩЕЙ
SL> стороны" недостаточно.
SL> Поясню, сессия это не только ключ, это совокупность правильных,
SL> допустимых ключей, сторон, момента и т.п.
Речь идет о самом первом этапе сессии: две стороны "договариваются" о сеансовых
ключах шифрования. Вызывающая сторона знает, кого она вызывает, открытый ключ
сервера у нее есть. Соответственно, проверяется, подписаны ли передаваемые
сервером в самом начале данные его ключом, или кто-то влез посредине. Смысл в
том, что при наличии злоумышленника либо подпись будет неверной, либо
подмененные данные для ключа не совпадут и защищенной сессии все равно не
получится.
SL> А нарушитель не обязан просто и тупо пихать свой открытый ключ,
SL> например, он может перехватывать сессию и т.д. и т.п.
Вот как раз о перехвате сессии и речь.
Алгоритм сессии в моем случае:
1) стороны шлют друг другу информацию о используемых ими версиях протокола.
2) Каждая из сторон генерит рандомный ключ, получает из него открытый ключ и
отсылает этот открытый ключ другой стороне. Отвечающая сторона дополнительно
добавляет подпись этого открытого ключа своим постоянным ключом, открытая часть
которого известна вызывающей стороне.
3) Вызывающая сторона проверяет соответствие подписи, если она не соответствует
- обрывает соединение.
4) Стороны из своих секретных и и полученных от другой стороны ключей
генерируют общие ключи шифрования сессии и переходят в шифрованный режим.
5) дальше уже в шифрованном виде идет аутентификация/авторизация сторон и обмен
данными.
Влезание MITM в этой схеме приводит либо к непрохождению проверки в пункте 3,
либо к тому, что в пункте 4 ключи у сервера и клиента окажутся разными, т.е.
сесии все равно не получится, вместо данных в пункте 5 одна из сторон получит
абракадабру и оборвет соединение. Либо к тому, что MITM вынужден будет просто
ретранслировать данные пунктов 1-2 без изменений, и, начиная с пункта 5 -
прочитать ничего не сможет :)
Alexey Vissarionov
Apr 4, 2015, 3:05:02 AM4/4/15
to
Доброго времени суток, Yuri!
03 Apr 2015 12:37:32, ты -> All:
YM> Имеем: соединение, использующее Curve25519
Не самый мудрый выбор.
YM> обмен ключами для получения session shared key. Достаточно ли будет
YM> для предотвращения MITM атаки дополнительной подписи (да хоть тем же
YM> Ed25519) для открытого сессионного ключа ОТВЕЧАЮЩЕЙ стороны?
Эээээ... И что это даст?
YM> Дабы вызывающая сторона, знающая постоянный паблик кей отвечающей,
YM> могла удостовериться, что данные для получения сессионного ключа
YM> отправлены действительно отвечающей стороной, а не кем-то посредине?
Проще всего сделать, как в SSH (файл known_hosts). Разумеется, останется
проблема первичного подтверждения подлинности, но ты же не от спецслужб
защищаешься, ага?
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Я не злопамятный, но логи веду
03 Apr 2015 12:37:32, ты -> All:
YM> Имеем: соединение, использующее Curve25519
YM> обмен ключами для получения session shared key. Достаточно ли будет
YM> для предотвращения MITM атаки дополнительной подписи (да хоть тем же
YM> Ed25519) для открытого сессионного ключа ОТВЕЧАЮЩЕЙ стороны?
Эээээ... И что это даст?
YM> Дабы вызывающая сторона, знающая постоянный паблик кей отвечающей,
YM> могла удостовериться, что данные для получения сессионного ключа
YM> отправлены действительно отвечающей стороной, а не кем-то посредине?
Проще всего сделать, как в SSH (файл known_hosts). Разумеется, останется
проблема первичного подтверждения подлинности, но ты же не от спецслужб
защищаешься, ага?
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Я не злопамятный, но логи веду
Serguei E. Leontiev
Apr 4, 2015, 4:23:59 AM4/4/15
to
Привет Юрий,
От 4 апреля 2015 г., 9:03:54 в fido7.ru.crypt ты писал:
...
YM> Вот как раз о перехвате сессии и речь.
YM> Алгоритм сессии в моем случае:
YM> 1) стороны шлют друг другу информацию о используемых ими
YM> версиях протокола.
YM> 2) Каждая из сторон генерит рандомный ключ,
YM> получает из него открытый ключ и отсылает этот открытый ключ
YM> другой стороне. Отвечающая сторона дополнительно добавляет
YM> подпись этого открытого ключа своим постоянным ключом, открытая
YM> часть которого известна вызывающей стороне.
YM> 3) Вызывающая
YM> сторона проверяет соответствие подписи, если она не
YM> соответствует - обрывает соединение.
Hу недостаточно же :) Я же даже пояснил, почему недостаточно, думать
лениво? :)
1001-ое пояснение от нормального параноика:
1. Hет проверки на принадлежность, как эфемерных открытых ключей
группе Curve25519, так и долговременных открытых ключей соответствующей
группе;
2. Контролю на долговременных ключах обеих сторон с помощью ДХ+MAC,
ДХ+HMAC или подписи должно подлежать (что б потом у сторон не возникали
разночтения):
а) идентификаторы сторон;
б) случайные числа обеих сторон, идентифицирующие сессию;
в) эфемерные открытые ключи;
г) долговременные открытые ключи или сертификаты;
3. Если хочется работать с нарушителем (со стороной, которая не
аутентифицируется), то он должна предоставить ту же самую информацию на
ДХ+MAC или ДХ+HMAC.
Читать, например, Венбо Мао "Современная криптография" до просветления.[#]
От 4 апреля 2015 г., 9:03:54 в fido7.ru.crypt ты писал:
SL>> Ответ: нет, "подписи для открытого сессионного ключа
SL>> ОТВЕЧАЮЩЕЙ стороны" недостаточно.
SL>> Поясню, сессия это не только ключ, это совокупность
SL>> правильных, допустимых ключей, сторон, момента и т.п.
...
SL>> А нарушитель не обязан просто и тупо пихать свой открытый
SL>> ключ, например, он может перехватывать сессию и т.д. и т.п.
YM> Вот как раз о перехвате сессии и речь.
YM> Алгоритм сессии в моем случае:
YM> 1) стороны шлют друг другу информацию о используемых ими
YM> версиях протокола.
YM> 2) Каждая из сторон генерит рандомный ключ,
YM> получает из него открытый ключ и отсылает этот открытый ключ
YM> другой стороне. Отвечающая сторона дополнительно добавляет
YM> подпись этого открытого ключа своим постоянным ключом, открытая
YM> часть которого известна вызывающей стороне.
YM> 3) Вызывающая
YM> сторона проверяет соответствие подписи, если она не
YM> соответствует - обрывает соединение.
Hу недостаточно же :) Я же даже пояснил, почему недостаточно, думать
лениво? :)
1001-ое пояснение от нормального параноика:
1. Hет проверки на принадлежность, как эфемерных открытых ключей
группе Curve25519, так и долговременных открытых ключей соответствующей
группе;
2. Контролю на долговременных ключах обеих сторон с помощью ДХ+MAC,
ДХ+HMAC или подписи должно подлежать (что б потом у сторон не возникали
разночтения):
а) идентификаторы сторон;
б) случайные числа обеих сторон, идентифицирующие сессию;
в) эфемерные открытые ключи;
г) долговременные открытые ключи или сертификаты;
3. Если хочется работать с нарушителем (со стороной, которая не
аутентифицируется), то он должна предоставить ту же самую информацию на
ДХ+MAC или ДХ+HMAC.
Читать, например, Венбо Мао "Современная криптография" до просветления.[#]
Yuri Myakotin
Apr 4, 2015, 7:15:02 AM4/4/15
to
Hello Serguei!
Saturday April 04 2015 11:23, Serguei E. Leontiev wrote to Yuri Myakotin:
YM>> соответствует - обрывает соединение.
SL> Hу недостаточно же :) Я же даже пояснил, почему недостаточно, думать
SL> лениво? :)
SL> 1001-ое пояснение от нормального параноика:
SL> 1. Hет проверки на принадлежность, как эфемерных открытых ключей
SL> группе Curve25519,
Если ключи неправильны из-за подмены - не сойдется shared key у клиента и
сервера, т.е. при расшифровке пойдет абракадабра.
А что до группы - так в том и фишка 25519, что ключом могут служить ЛЮБЫЕ 64
байта. Диапазон значений и секретного, и открытого ключей - 256 бит.
SL> так и долговременных открытых ключей
SL> соответствующей группе;
Долговременный открытый ключ создается при создании сервера и общедоступен.
SL> 2. Контролю на долговременных ключах обеих
SL> сторон с помощью ДХ+MAC, ДХ+HMAC или подписи должно подлежать (что б
SL> потом у сторон не возникали разночтения):
SL> а) идентификаторы сторон;
SL> б) случайные числа обеих сторон, идентифицирующие сессию;
Это уже дальше. Hа этапе 5, когда шифрование уже установлено. Стороны посылают
друг другу свои идентефикаторы и случайные NN байт, которые другая сторона
должна подписать и прислать подпись. Соответственно, любое несовпадение -
Socket.Close().
SL> в) эфемерные открытые ключи;
SL> г) долговременные открытые ключи или сертификаты;
Г) - у сервера есть полный список открытых ключей клиентов, и наоборот, у
клиента есть полный список серверов и их открытых ключей.
SL> Читать, например, Венбо Мао "Современная криптография" до
SL> просветления.[#]
Спасибо. Скачал, на досуге займусь прочтением.
Saturday April 04 2015 11:23, Serguei E. Leontiev wrote to Yuri Myakotin:
YM>> соответствует - обрывает соединение.
SL> лениво? :)
SL> 1001-ое пояснение от нормального параноика:
SL> 1. Hет проверки на принадлежность, как эфемерных открытых ключей
SL> группе Curve25519,
Если ключи неправильны из-за подмены - не сойдется shared key у клиента и
сервера, т.е. при расшифровке пойдет абракадабра.
А что до группы - так в том и фишка 25519, что ключом могут служить ЛЮБЫЕ 64
байта. Диапазон значений и секретного, и открытого ключей - 256 бит.
SL> так и долговременных открытых ключей
SL> соответствующей группе;
Долговременный открытый ключ создается при создании сервера и общедоступен.
SL> 2. Контролю на долговременных ключах обеих
SL> сторон с помощью ДХ+MAC, ДХ+HMAC или подписи должно подлежать (что б
SL> потом у сторон не возникали разночтения):
SL> а) идентификаторы сторон;
SL> б) случайные числа обеих сторон, идентифицирующие сессию;
Это уже дальше. Hа этапе 5, когда шифрование уже установлено. Стороны посылают
друг другу свои идентефикаторы и случайные NN байт, которые другая сторона
должна подписать и прислать подпись. Соответственно, любое несовпадение -
Socket.Close().
SL> в) эфемерные открытые ключи;
SL> г) долговременные открытые ключи или сертификаты;
Г) - у сервера есть полный список открытых ключей клиентов, и наоборот, у
клиента есть полный список серверов и их открытых ключей.
SL> Читать, например, Венбо Мао "Современная криптография" до
SL> просветления.[#]
Спасибо. Скачал, на досуге займусь прочтением.
Yuri Myakotin
Apr 4, 2015, 7:15:02 AM4/4/15
to
Hello Alexey!
Saturday April 04 2015 09:37, Alexey Vissarionov wrote to Yuri Myakotin:
YM>> обмен ключами для получения session shared key. Достаточно ли
YM>> будет для предотвращения MITM атаки дополнительной подписи (да
YM>> хоть тем же Ed25519) для открытого сессионного ключа ОТВЕЧАЮЩЕЙ
YM>> стороны?
AV> Эээээ... И что это даст?
Гарантию, что отвечает сервер, а не ретранслятор посредине, присылающий свои
байтики для генерации сессионного ключа _вместо_ тех, которые ему послал
сервер.
YM>> Дабы вызывающая сторона, знающая постоянный паблик кей
YM>> отвечающей, могла удостовериться, что данные для получения
YM>> сессионного ключа отправлены действительно отвечающей стороной, а
YM>> не кем-то посредине?
AV> Проще всего сделать, как в SSH (файл known_hosts).
Так примерно это и предполагается. У клиента список серверов с их паблик
ключами, сервер подписывает вышеупомянутые данные своим секретным ключом,
клиент проверяет подпись известным ему пабликом этого сервера.
AV> Разумеется, останется проблема первичного подтверждения подлинности,
AV> но ты же не от спецслужб защищаешься, ага?
Спецслужбам вскрытие сетевого шифрования даст только возможность видеть, что
некие абоненты с цифровыми идентификаторами переписываются меж собой, но
содержание переписки прочесть не получится.
Saturday April 04 2015 09:37, Alexey Vissarionov wrote to Yuri Myakotin:
YM>> обмен ключами для получения session shared key. Достаточно ли
YM>> хоть тем же Ed25519) для открытого сессионного ключа ОТВЕЧАЮЩЕЙ
YM>> стороны?
AV> Эээээ... И что это даст?
Гарантию, что отвечает сервер, а не ретранслятор посредине, присылающий свои
байтики для генерации сессионного ключа _вместо_ тех, которые ему послал
сервер.
YM>> Дабы вызывающая сторона, знающая постоянный паблик кей
YM>> сессионного ключа отправлены действительно отвечающей стороной, а
YM>> не кем-то посредине?
AV> Проще всего сделать, как в SSH (файл known_hosts).
Так примерно это и предполагается. У клиента список серверов с их паблик
ключами, сервер подписывает вышеупомянутые данные своим секретным ключом,
клиент проверяет подпись известным ему пабликом этого сервера.
AV> Разумеется, останется проблема первичного подтверждения подлинности,
AV> но ты же не от спецслужб защищаешься, ага?
Спецслужбам вскрытие сетевого шифрования даст только возможность видеть, что
некие абоненты с цифровыми идентификаторами переписываются меж собой, но
содержание переписки прочесть не получится.
Yuri Myakotin
Apr 4, 2015, 8:15:03 AM4/4/15
to
Hello Alexey!
Saturday April 04 2015 13:51, Yuri Myakotin wrote to Alexey Vissarionov:
YM>>> хоть тем же Ed25519) для открытого сессионного ключа ОТВЕЧАЮЩЕЙ
YM>>> стороны?
AV>> Эээээ... И что это даст?
YM> Гарантию, что отвечает сервер, а не ретранслятор посредине,
YM> присылающий свои байтики для генерации сессионного ключа _вместо_ тех,
YM> которые ему послал сервер.
Подумалось. Добавить еще и защиту от подсовывания верных, но старых данных
сервера. Т.е. клиент в самом начале присылает серверу дополнительные NN байт,
которые вместе с сессионными паблик ключами сервер должен подписать.
Saturday April 04 2015 13:51, Yuri Myakotin wrote to Alexey Vissarionov:
YM>>> хоть тем же Ed25519) для открытого сессионного ключа ОТВЕЧАЮЩЕЙ
YM>>> стороны?
AV>> Эээээ... И что это даст?
YM> присылающий свои байтики для генерации сессионного ключа _вместо_ тех,
YM> которые ему послал сервер.
Подумалось. Добавить еще и защиту от подсовывания верных, но старых данных
сервера. Т.е. клиент в самом начале присылает серверу дополнительные NN байт,
которые вместе с сессионными паблик ключами сервер должен подписать.
Serguei E. Leontiev
Apr 4, 2015, 10:10:14 AM4/4/15
to
Привет Юрий,
От 4 апреля 2015 г., 13:56:45 в fido7.ru.crypt ты писал:
YM>>> соответствует - обрывает соединение.
SL>> Hу недостаточно же :) Я же даже пояснил, почему
SL>> недостаточно, думать лениво? :)
YM> Если ключи неправильны из-за подмены - не сойдется shared key у
YM> клиента и сервера, т.е. при расшифровке пойдет абракадабра.
YM> А что до группы - так в том и фишка 25519, что ключом могут
YM> служить ЛЮБЫЕ 64 байта. Диапазон значений и секретного, и
YM> открытого ключей - 256 бит.
32 байта наверное, и не любые, ибо таки, и здесь, как и везде, есть
неопределённые значения.
SL>> 2. Контролю на долговременных ключах обеих
SL>> сторон с помощью ДХ+MAC, ДХ+HMAC или подписи должно
SL>> подлежать (что б потом у сторон не возникали разночтения):
YM> Это уже дальше. Hа этапе 5, когда шифрование уже установлено.
Hу-ну, настоящие параноики не любят использовать ключи созданные как
попало. При неизбежных ошибках везде, где только можно, дальше будет
поздняк метаться :)
SL>> г) долговременные открытые ключи или сертификаты;
YM> Г) - у сервера есть полный список открытых ключей клиентов, и
YM> наоборот, у клиента есть полный список серверов и их открытых
YM> ключей.
Списки? Пусть списки, но и они меняются.
От 4 апреля 2015 г., 13:56:45 в fido7.ru.crypt ты писал:
YM>>> соответствует - обрывает соединение.
SL>> Hу недостаточно же :) Я же даже пояснил, почему
SL>> 1001-ое пояснение от нормального параноика:
SL>> 1. Hет проверки на принадлежность, как эфемерных открытых
SL>> ключей группе Curve25519,
SL>> 1. Hет проверки на принадлежность, как эфемерных открытых
YM> Если ключи неправильны из-за подмены - не сойдется shared key у
YM> клиента и сервера, т.е. при расшифровке пойдет абракадабра.
YM> А что до группы - так в том и фишка 25519, что ключом могут
YM> служить ЛЮБЫЕ 64 байта. Диапазон значений и секретного, и
YM> открытого ключей - 256 бит.
32 байта наверное, и не любые, ибо таки, и здесь, как и везде, есть
неопределённые значения.
SL>> 2. Контролю на долговременных ключах обеих
SL>> сторон с помощью ДХ+MAC, ДХ+HMAC или подписи должно
SL>> а) идентификаторы сторон;
SL>> б) случайные числа обеих сторон, идентифицирующие
SL>> сессию;
SL>> б) случайные числа обеих сторон, идентифицирующие
YM> Это уже дальше. Hа этапе 5, когда шифрование уже установлено.
Hу-ну, настоящие параноики не любят использовать ключи созданные как
попало. При неизбежных ошибках везде, где только можно, дальше будет
поздняк метаться :)
SL>> г) долговременные открытые ключи или сертификаты;
YM> наоборот, у клиента есть полный список серверов и их открытых
YM> ключей.
Списки? Пусть списки, но и они меняются.
Serguei E. Leontiev
Apr 4, 2015, 10:10:14 AM4/4/15
to
Привет Юрий,
От 4 апреля 2015 г., 15:02:50 в fido7.ru.crypt ты писал:
YM> Подумалось. Добавить еще и защиту от подсовывания верных, но
YM> старых данных сервера. Т.е. клиент в самом начале присылает
YM> серверу дополнительные NN байт, которые вместе с сессионными
YM> паблик ключами сервер должен подписать.
Подумалось :) Тебе же сразу перечисли, что надо. И это тоже надо, но
этого тоже недостаточно. Hу, думай дальше :)
От 4 апреля 2015 г., 15:02:50 в fido7.ru.crypt ты писал:
YM>>>> хоть тем же Ed25519) для открытого сессионного
YM>>>> ключа ОТВЕЧАЮЩЕЙ стороны?
AV>>> Эээээ... И что это даст?
YM>> Гарантию, что отвечает сервер, а не ретранслятор посредине,
YM>> присылающий свои байтики для генерации сессионного ключа
YM>> _вместо_ тех, которые ему послал сервер.
YM>> Гарантию, что отвечает сервер, а не ретранслятор посредине,
YM>> присылающий свои байтики для генерации сессионного ключа
YM> Подумалось. Добавить еще и защиту от подсовывания верных, но
YM> старых данных сервера. Т.е. клиент в самом начале присылает
YM> серверу дополнительные NN байт, которые вместе с сессионными
YM> паблик ключами сервер должен подписать.
Подумалось :) Тебе же сразу перечисли, что надо. И это тоже надо, но
этого тоже недостаточно. Hу, думай дальше :)
Yuri Myakotin
Apr 4, 2015, 11:45:02 AM4/4/15
to
Hello Serguei!
Saturday April 04 2015 17:10, Serguei E. Leontiev wrote to Yuri Myakotin:
YM>> Если ключи неправильны из-за подмены - не сойдется shared key у
YM>> клиента и сервера, т.е. при расшифровке пойдет абракадабра.
YM>> А что до группы - так в том и фишка 25519, что ключом могут
YM>> служить ЛЮБЫЕ 64 байта. Диапазон значений и секретного, и
YM>> открытого ключей - 256 бит.
SL> 32 байта наверное,
Угу не то написал.
SL> и не любые, ибо таки, и здесь, как и везде, есть
SL> неопределённые значения.
Именно любые.
SL>>> 2. Контролю на долговременных ключах обеих
SL>>> сторон с помощью ДХ+MAC, ДХ+HMAC или подписи должно
SL>>> подлежать (что б потом у сторон не возникали разночтения):
SL>>> а) идентификаторы сторон;
SL>>> б) случайные числа обеих сторон, идентифицирующие
SL>>> сессию;
YM>> Это уже дальше. Hа этапе 5, когда шифрование уже установлено.
SL> Hу-ну, настоящие параноики не любят использовать ключи созданные как
SL> попало. При неизбежных ошибках везде, где только можно, дальше будет
SL> поздняк метаться :)
SL>>> г) долговременные открытые ключи или сертификаты;
YM>> Г) - у сервера есть полный список открытых ключей клиентов, и
YM>> наоборот, у клиента есть полный список серверов и их открытых
YM>> ключей.
SL> Списки? Пусть списки, но и они меняются.
Для приватного сервера менять особо ничего не требуется.
А если делать паблик сервера, связывающиеся между собой - да, так или иначе
придется приходить к варианту трастед серверов, с которых остальные обновления
списков берут. Как сейчас с сертификатами.
Saturday April 04 2015 17:10, Serguei E. Leontiev wrote to Yuri Myakotin:
YM>> Если ключи неправильны из-за подмены - не сойдется shared key у
YM>> клиента и сервера, т.е. при расшифровке пойдет абракадабра.
YM>> А что до группы - так в том и фишка 25519, что ключом могут
YM>> служить ЛЮБЫЕ 64 байта. Диапазон значений и секретного, и
YM>> открытого ключей - 256 бит.
Угу не то написал.
SL> и не любые, ибо таки, и здесь, как и везде, есть
SL> неопределённые значения.
Именно любые.
SL>>> 2. Контролю на долговременных ключах обеих
SL>>> сторон с помощью ДХ+MAC, ДХ+HMAC или подписи должно
SL>>> подлежать (что б потом у сторон не возникали разночтения):
SL>>> а) идентификаторы сторон;
SL>>> б) случайные числа обеих сторон, идентифицирующие
SL>>> сессию;
YM>> Это уже дальше. Hа этапе 5, когда шифрование уже установлено.
SL> попало. При неизбежных ошибках везде, где только можно, дальше будет
SL> поздняк метаться :)
SL>>> г) долговременные открытые ключи или сертификаты;
YM>> Г) - у сервера есть полный список открытых ключей клиентов, и
YM>> наоборот, у клиента есть полный список серверов и их открытых
YM>> ключей.
Для приватного сервера менять особо ничего не требуется.
А если делать паблик сервера, связывающиеся между собой - да, так или иначе
придется приходить к варианту трастед серверов, с которых остальные обновления
списков берут. Как сейчас с сертификатами.
Serguei E. Leontiev
Apr 4, 2015, 1:49:56 PM4/4/15
to
Привет Юрий,
От 4 апреля 2015 г., 18:26:32 в fido7.ru.crypt ты писал:
YM>>> пойдет абракадабра. А что до группы - так в том и фишка
YM>>> 25519, что ключом могут служить ЛЮБЫЕ 64 байта.
YM>>> Диапазон значений и секретного, и открытого ключей -
YM>>> 256 бит.
SL>> 32 байта наверное,
YM> Угу не то написал.
Мозг включаем, рекламу и маркетинг перестаём читать:
y^2 = x^3 + 486662x^2 + x mod p
p = 2^255 \xE2\x88\x92 19
G = (9, ...)
q = 2^252 + 27742317777372353535851937790883648493
Сжатое представление: 255 бит координаты x и бит "знака" координаты y.
Соответственно, не определены следующие представления:
1. "отрицательный знак" y для x = 0;
2. 2^255 \xE2\x88\x92 19 <= x < 2^255;
Hо это ж не самое главное. Бернштейн утверждал только за то, что всё
должно быть хорошо для открытых ключей вида nG, которые образуют группу
порядка q. А вот за остальные точки, IMHO, никто ничего не обещал. :)
От 4 апреля 2015 г., 18:26:32 в fido7.ru.crypt ты писал:
YM>>> Если ключи неправильны из-за подмены - не сойдется
YM>>> shared key у клиента и сервера, т.е. при расшифровке
YM>>> пойдет абракадабра. А что до группы - так в том и фишка
YM>>> 25519, что ключом могут служить ЛЮБЫЕ 64 байта.
YM>>> Диапазон значений и секретного, и открытого ключей -
YM>>> 256 бит.
SL>> 32 байта наверное,
YM> Угу не то написал.
SL>> и не любые, ибо таки, и здесь, как и везде, есть
SL>> неопределённые значения.
YM> Именно любые.
SL>> неопределённые значения.
Мозг включаем, рекламу и маркетинг перестаём читать:
y^2 = x^3 + 486662x^2 + x mod p
p = 2^255 \xE2\x88\x92 19
G = (9, ...)
q = 2^252 + 27742317777372353535851937790883648493
Сжатое представление: 255 бит координаты x и бит "знака" координаты y.
Соответственно, не определены следующие представления:
1. "отрицательный знак" y для x = 0;
2. 2^255 \xE2\x88\x92 19 <= x < 2^255;
Hо это ж не самое главное. Бернштейн утверждал только за то, что всё
должно быть хорошо для открытых ключей вида nG, которые образуют группу
порядка q. А вот за остальные точки, IMHO, никто ничего не обещал. :)
0 new messages