Шифрование сообщений¶
Kaspeak SDK использует совокупность хорошо-изученных криптографических примитивов, обеспечивая конфиденциальность, целостность и компактность передаваемых данных.
- ECDH — получение общего секрета между двумя участниками без передачи приватных данных.
- 2 x SHA-256 — приведение точки ECDH к фиксированному 256-битному ключу.
- XChaCha20-Poly1305 — симметричное шифрование и аутентификация.
- CBOR + Zstandard — сериализация объекта и последующая компрессия.
Как использовать шифрование в приложении?¶
Kaspeak SDK автоматически управляет шифрованием и дешифрованием сообщений, если Ваш класс сообщения установлен с параметром requiresEncryption = true
. Вам нужно лишь указать общий секретный ключ (общий секрет), который вычисляется с помощью публичного ключа получателя.
Типичный процесс включает:
- создание класса зашифрованного сообщения;
- получение общего секрета (ключа) через
sdk.deriveConversationKeys
; - передачу этого ключа в методы
sdk.encode
иsdk.decode
.
Ниже приведён полный пример.
Полный пример¶
Создадим тип сообщения, который требует шифрования:
Данный пример демонстрирует отправку зашифрованного сообщения самому себе. Если сообщение предназначается для кого-то другого, вставьте в
deriveConversationKeys
публичный ключ получателя.
Как извлечь общий секрет для декодирования?¶
Общий секретный ключ формируется методом SDK deriveConversationKeys
, принимающим публичный ключ другого участника:
secret
— ключ шифрования, используемый для кодирования и декодирования сообщений.chainKey
— дополнительный идентификатор, используемый для генерации уникальных точек сообщений.
Дополнительный параметр в методах encode
и decode
¶
Методы encode
и decode
принимают второй необязательный аргумент — ключ шифрования:
Если ваш тип сообщения помечен флагом requiresEncryption
, ключ шифрования обязателен. Если флаг не установлен, передача ключа не имеет эффекта и будет проигнорирована.
Таким образом, SDK автоматически обеспечивает корректное шифрование и расшифровку ваших сообщений.
Как это работает внутри SDK?¶
1. Формирование симметричного ключа¶
Ключ, вычисленный обеими сторонами, полностью идентичен.
2. Сериализация и сжатие¶
CBOR даёт компактное бинарное представление;
Zstandard дополнительно уменьшает размер полезной нагрузки.
3. Шифрование¶
При расшифровке неверный ключ или искажённые данные приводят к ошибке, что позволяет надёжно отбраковать чужой или повреждённый трафик.
4. Расшифровка¶
5. Подтверждение подлинности¶
Перед отправкой весь payload подписывается Schnorr-подписью автора на уровне SDK.
Не отключая флаг setSignatureVerificationEnabled
, Вы можете быть уверены в том, что сообщение действительно принадлежит отправителю.
Любое изменение байтов приводит к отрицательному результату проверки на стороне SDK.