Home Docs Security Privacy Music Use Support
Обновлено: 28.06.2026

Прозрачность безопасности и исходного кода

На этой странице мы фиксируем, что именно можно проверить технически, какие части архитектуры Kasty раскрываются публично и где проходят границы между прозрачностью, безопасностью и закрытой эксплуатационной логикой.

1) Статус документа

2) Что можно проверить уже сейчас

  • Транспорт: клиент-серверные каналы защищаются через TLS/WSS; сетевой уровень при этом по-прежнему раскрывает метаданные соединений, но не должен раскрывать plaintext E2E-полезной нагрузки.
  • Границы сервера: сервер обрабатывает маршрутизацию, доставку, авторизацию и метаданные, но при корректной модели ключей не должен иметь технической возможности читать E2E-контент в plaintext.
  • Криптографическая модель сообщений KSMP Whisper Ultra OOB основана на Signal Protocol (адаптированная реализация) с семантикой Double Ratchet.
  • Обычные чаты, создаваемые через профиль или токен, не относятся к KSMP Whisper E2E; автоматическая модерация применяется к открытому контенту, а не к plaintext содержимому E2E-коммуникаций.
  • Криптомодель сообщений и звонков, включая ограничения, описана на странице Безопасность.
  • Подробные технические спецификации публикуются в разделе Документация.

3) Публичные репозитории для аудита

  • whisper-chatstore: клиентский слой KSMP Whisper Ultra OOB, включая модели, локальное хранилище и связанную key-transparency логику. Репозиторий: github.com/8dch4vtp24-boop/whisper-chatstore.
  • ksmp-whisper-core: криптографический и медиаслой профиля KSMP Whisper / WhisperStreamVoice, включая модели звонков, медиапоток, кодеки и связанную transport-adjacent часть. Репозиторий: github.com/8dch4vtp24-boop/ksmp-whisper-core.
  • ksmp-server-boundary: минимальный публичный набор для аудита серверной границы доверия, включая bootstrap public keys, hash-only room auth token, key transparency и E2E boundary excerpt для звонка. Репозиторий: github.com/8dch4vtp24-boop/ksmp-server-boundary.
  • Все репозитории опубликованы в режиме публичной технической доступности для аудита и проверки совместимости, но не как лицензия на свободное повторное использование кода в продуктах.
  • Для воспроизводимой проверки в каждом репозитории есть `MANIFEST.sha256`, `SNAPSHOT_METADATA.md`, `TEST_PLAN.md` и sanity-check скрипты.
  • Текущие ограничения лицензии: запрещены распространение, перепродажа, интеграция в сторонние продукты (включая open-source проекты) и эксплуатационное использование кода без отдельного письменного разрешения правообладателя Kasty Vladimir Usanov.

4) Что остается закрытым

  • Мы не раскрываем антизлоупотребительные механики, антиспам-эвристики и внутренние правила риск-скоринга.
  • Мы не раскрываем операционные секреты, ключевой материал окружений, детали защиты инфраструктуры и внутренние планы реагирования на инциденты.
  • Мы не публикуем те части кода и логики, раскрытие которых существенно повышает риск обхода защит без эквивалентного роста проверяемости криптографической модели.

5) Аудиты и disclosure-практика

  • Мы планируем внешние аудиты, сфокусированные на криптографических инвариантах и корректности ключевых протокольных состояний.
  • После завершения аудита мы публикуем публичное резюме: область проверки, методологию, критичные выводы и статус исправлений.
  • Сообщения об уязвимостях и подозрительном поведении принимаются через поддержку с пометкой Security.
Статус на 28.06.2026: публичные репозитории для аудита уже опубликованы. Мы продолжаем обновлять эту страницу по мере публикации новых ревизий спецификаций, исходных снимков для аудита и внешних отчетов.
Updated: 2026-06-28

Security and Source Transparency

This page records what can be verified technically, which parts of Kasty are disclosed publicly, and where the boundary sits between transparency, security, and non-public operational logic.

1) Document status

2) What is verifiable now

  • Transport: client-server channels are protected with TLS/WSS; the network layer can still expose connection metadata, but should not expose plaintext E2E payload content.
  • Server boundary: our servers process routing, delivery, authorization, and metadata, but under the intended key model they should not have technical access to E2E plaintext.
  • KSMP Whisper Ultra OOB message cryptography is based on Signal Protocol (Kasty-adapted implementation) with Double Ratchet semantics.
  • Regular chats created via profile or token are not KSMP Whisper E2E mode; automated moderation applies to open content rather than plaintext E2E content.
  • The message and call crypto model, including limitations, is described on our Security page.
  • Detailed technical specifications are published in the Documentation section.

3) Public audit repositories

  • whisper-chatstore: client-side KSMP Whisper Ultra OOB layer, including models, local storage, and related key-transparency logic. Repository: github.com/8dch4vtp24-boop/whisper-chatstore.
  • ksmp-whisper-core: cryptographic and media layer for KSMP Whisper / WhisperStreamVoice, including call models, media stream, codecs, and related transport-adjacent logic. Repository: github.com/8dch4vtp24-boop/ksmp-whisper-core.
  • ksmp-server-boundary: minimal public material for server trust-boundary review, including bootstrap public keys, hash-only room auth token, key transparency, and a call E2E boundary excerpt. Repository: github.com/8dch4vtp24-boop/ksmp-server-boundary.
  • All repositories are published in a public technical-access mode for audit and interoperability review, not as a license for unrestricted code reuse in products.
  • Each repository contains `MANIFEST.sha256`, `SNAPSHOT_METADATA.md`, `TEST_PLAN.md`, and sanity-check scripts for reproducible review.
  • Current license restrictions: redistribution, resale, integration into third-party products (including open-source projects), and operational usage are prohibited without separate written permission from the rights holder Kasty Vladimir Usanov.

4) What remains closed

  • We do not disclose anti-abuse mechanisms, anti-spam heuristics, or internal risk-scoring rules.
  • We do not disclose operational secrets, environment key material, infrastructure-hardening details, or internal incident-response plans.
  • We do not publish code or logic where publication would materially increase bypass risk without a comparable gain in cryptographic verifiability.

5) Audits and disclosure practice

  • We plan independent audits focused on cryptographic invariants and correctness of critical protocol states.
  • After each audit, we publish a public summary covering scope, methodology, critical findings, and remediation status.
  • Vulnerability and suspicious-activity reports are accepted through support with the Security label.
Status as of 2026-06-28: public audit repositories are available. We continue updating this page as new specification revisions, audit-source snapshots, and external reports are released.