Если там есть NOBUS, то на его разработку было потрачено усилий и средств сильно больше, чем позволяют какие-то ни было личные интересы. Очевидно, что никто в здравом смысле по собственному желанию не будет использовать ГОСТы. Так зачем тратить столько усилий? Как может окупиться работающий бекдор в ГОСТовском алгоритме?
Изобретать очередной E2E протокол для общения конечно прикольно, но только давайте не будем называть его безопасным. В то время как уже давно есть и Double Ratchet и Noise Protocol это моветон.
Что касается конкретно вашей реализации:
1) ID пира должен быть хэшем от его статического публичного ключа, иначе MITM
2) Эфемерные ключи не подписаны. Тоже MITM
2) Вместо AES-CBC лучше использовать AES-GCM/AES-GCM-SIV, либо добавить HMAC. У вас нет никакой проверки корректности расшифрованного текста, можно напихать туда что угодно и собеседник ничего не заподозрит
Наука не стоит на месте и со слабыми паролями научились бороться с помощью «удалённой» соли и других гораздо более изощренных техник вроде Pythia и PHE. Пора их внедрять. Вот конспект моего доклада на эту тему.
Конечно мы планируем опубликовать SLA после полноценного релиза, но для тех кто переживает всегда есть возможность написать сервис самим и разместить на своих мощностях. Пока что цель — дать людям попробовать протокол, API, собрать отзывы, сделать больше документации, мануалов по миграции и т п.
Что значит «почти в открытом виде»? Насколько мне известно, TLS пока не взломан.
Так же при SCRAM сервер отправляет клиенту соль, позволяя выполнить precomputation атаку в случае, если злоумышленник её получит.
Современные решения не страдают этими болячками, но их надо имплементить и на клиентской и на серверной стороне, а делать этого никто не хочет
Я не упоминал протоколы, которые требуют работы на клиенте, потому что ну, они требуют работы на клиенте. Если всякие PAKE в приложения еще можно встроить, то в вебе этого никто делать не будет
Что касается конкретно вашей реализации:
1) ID пира должен быть хэшем от его статического публичного ключа, иначе MITM
2) Эфемерные ключи не подписаны. Тоже MITM
2) Вместо AES-CBC лучше использовать AES-GCM/AES-GCM-SIV, либо добавить HMAC. У вас нет никакой проверки корректности расшифрованного текста, можно напихать туда что угодно и собеседник ничего не заподозрит
Это только то, что сразу бросилось в глаза
Так же при SCRAM сервер отправляет клиенту соль, позволяя выполнить precomputation атаку в случае, если злоумышленник её получит.
Современные решения не страдают этими болячками, но их надо имплементить и на клиентской и на серверной стороне, а делать этого никто не хочет
www.youtube.com/watch?v=y1MQyl13ssc