From 5b295cbf7d15da06519ada8ae8de164d2455ec34 Mon Sep 17 00:00:00 2001 From: Sergey Matveev Date: Tue, 29 Jan 2019 10:29:46 +0300 Subject: [PATCH] =?utf8?q?YA=20P2P=20IM=20=D1=81=20E2EE?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit https://habr.com/ru/post/437686/ Статья про то, как автор на Go легко написал peer-to-peer messenger с end-to-end шифрованием. Мне то конечно сразу интересно было посмотреть как он устроил шифрование. Вот честно -- лучше бы вообще не брался. Не знает базовых азов. * шифрование без аутентификации -- сразу просто выкинуть в помойку * обмен ключами, насколько вижу, тоже без аутентификации -- MitM легко * padding ориентируется на просто отрезание нулевых байт в конце -- накладывает ограничения на допустимый payload прикладного протокола. Зачем? Кроме того, это допускает "прохождение" изменённых пакетов, так как никакой аутентификации нет * curve25519 почему-то использует ключи сгенерированные ed25519 -- там генерация настолько простая и тривиальная (urandom(32)), что это просто глупость полная, но ok -- на безопасность не влияет * CBC-режим? Нет, ну он имеет право на существование, но должна быть веская причина. Если её нет, то плохой режим: требует padding, реализации и функции шифрования и дешифрования, не распараллеливается, относительно небольшое количество блоков может быть зашифровано на одном ключе И ведь он пишет на Go. Буквально достаточно было бы просто CBC поменять на GCM, который имеется в библиотеках и: аутентификация сообщения, отсутствие padding, распараллелизация возможна (хотя я не поклонник GCM). Вот и Дуров со своей командой как-то так и делали свой IM, хотя он получше всё же этого. Лучшим вариантом было бы использование Noise. Если не хочется, то уж хотя бы использовать golang.org/x/crypto/nacl/secretbox. -- 2.50.0