Comments 15
Довольно интересный получился кейс! После этого стоит задуматься на тему «А стоит ли продолжать использовать тот же любимый многими параноиками Tox?»
Активно используем libsodium в некоторых проектах, приходилось даже перекапывать сырцы вдоль и поперек, дело в том, что в данной библиотеке реализовано несколько алгоритмов и кривых. Для вашего кейса подходит crypto_sign — это реализация Ed25519, она же Эдвардовская кривая. Это также имплементация ассиммтричного шифрования и она является достаточно уровень надежности для шифрования пересылаемых сообщений.
Спасибо. После такой оплошности, я тоже полез в исходники. Думаю использовать Sealed box — шифрование по той же схеме, что рассмотрена в статье, но с эфемерными ключами. Закрытый ключ после шифрования уничтожается и расшифровать сообщение может только получатель.
Проблема 1-2 надумана — Алиса и Боб прекрасно знают, какое сообщение они получили, а какое — отправили, а остальных это не касается.
Проблема 3-4 решается генерацией новых ключей на каждый сеанс связи.
Для меня проблема 1 и 2 состоит в том, что если был скомпрометирован закрытый ключ Боба, то злоумышленник может посылать ему сообщения якобы от Алисы даже не зная ее закрытого ключа. И Боб не сможет это узнать.
Насчет проблемы 3-4 совершенно согласен с Вами (об этом выше написал). Спасибо
Насчет проблемы 3-4 совершенно согласен с Вами (об этом выше написал). Спасибо
Нет, проблема 1-2 в общем случае не надумана.
Например, если эти сообщения — финансовые распоряжения вида «Боб, я тебе обещаю перевести денег. Алиса», а Алиса отказывается выполнять распоряжение, мотивируя это тем, что сообщение было сгенерировано самим Бобом. В этом случае стороны могут обратиться в суд, и криптографический протокол должен позволить доказать авторство («невозможность отказа с доказательством»).
Тип протоколов, которые позволяют это делать, называется арбитражными протоколами (см начало 2-ой главы Брюса Шнайера ).
Например, если эти сообщения — финансовые распоряжения вида «Боб, я тебе обещаю перевести денег. Алиса», а Алиса отказывается выполнять распоряжение, мотивируя это тем, что сообщение было сгенерировано самим Бобом. В этом случае стороны могут обратиться в суд, и криптографический протокол должен позволить доказать авторство («невозможность отказа с доказательством»).
Тип протоколов, которые позволяют это делать, называется арбитражными протоколами (см начало 2-ой главы Брюса Шнайера ).
Так бывает, если читать документацию между строк.
1) Public-key authenticated encryption (ваша же ссылка) раздел Precalculation interface — явно указывает, что, вызывая специальные функции, ОБЩИЙ ключ можно подсчитать единожды (из контекста вполне следует, что это указано в противовес постоянному вычислению).
2) Раздел Sealed boxes в той же главе (Public-key cryptography) что и Public-key authenticated encryption — прямо в разделе Purpose явно написано это используя данные функции даже отправитель не сможет расшифровать свое послание.
Спорить не буду — можно было явно указать использование общего ключа в описаниях, но все предпосылки дял понимания этого сделаны.
1) Public-key authenticated encryption (ваша же ссылка) раздел Precalculation interface — явно указывает, что, вызывая специальные функции, ОБЩИЙ ключ можно подсчитать единожды (из контекста вполне следует, что это указано в противовес постоянному вычислению).
2) Раздел Sealed boxes в той же главе (Public-key cryptography) что и Public-key authenticated encryption — прямо в разделе Purpose явно написано это используя данные функции даже отправитель не сможет расшифровать свое послание.
Спорить не буду — можно было явно указать использование общего ключа в описаниях, но все предпосылки дял понимания этого сделаны.
Согласен. Ошибка в том и заключалась, что по каком-то причинам я торопился и читал документацию невнимательно. В последнем разделе действительно есть то, что должно было натолкнуть меня на понимание работы. Кроме информации в «Precalculation interface», то ниже есть раздел «Algorithm details», в котором явно указано на использование симметричного шифра.
Публикацию я как раз и писал под впечатлением от своей ошибки и самоуверенности что я все прекрасно понимаю, хотя это было не так, и я надеюсь это будет лишним предостережением для других разработчиков (ну и усвоенным уроком для меня). Спасибо
Публикацию я как раз и писал под впечатлением от своей ошибки и самоуверенности что я все прекрасно понимаю, хотя это было не так, и я надеюсь это будет лишним предостережением для других разработчиков (ну и усвоенным уроком для меня). Спасибо
Вся статья про то, что автор невнимательно прочитал документацию. Отлично
Если бы автор пошёл дальше, то там граблей было бы ещё больше. Неудачный padding, подход с authenticate then encrypt или ещё что-нибудь.
Есть прекрасная статья The Cryptographic Doom Principle:
When it comes to designing secure protocols, I have a principle that goes like this: if you have to perform any cryptographic operation before verifying the MAC on a message you’ve received, it will somehow inevitably lead to doom.
Спасибо за наводку, очень познавательно. Что касается «Vaudenay Attack» и проблем с padding. Алгоритм Salsa20 — это поточный шифр и длина зашифрованного сообщения всегда равна длине исходного (по крайней мере в реализации libsodium), так что проблемы с выравниванием там отсутствуют. Кроме того, ситуация, описанная в «SSH Plaintext Recovery» тут тоже не повторяется, так как длина открытого текста вычисляется из длины зашифрованного текста (нужно вычесть длину MAC) и не передается в самом сообщении
Статья о том, что автор не читает документацию и не понимает приципов шифрования.
UFO just landed and posted this here
Sign up to leave a comment.
libsodium: Public-key authenticated encryption или как я расшифровал сообщение без закрытого ключа