Реализовать SHiNE_DM v1 с E2EE и tombstone

Dev_Docs/Personal_Messages/Формат_DM_v1.md

@@ -6,9 +6,9 @@
 
 Важно:
 
-- это целевой формат следующего этапа;
-- в текущем коде он ещё реализован не полностью;
-- особенно это касается перехода всех типов `1..8` на единый контейнер `SHiNE_DM`.
+- это актуальный формат, реализованный в текущем коде;
+- контейнер `SHiNE_DM` используется для всех типов `1..8`;
+- при любых будущих изменениях DM этот документ обновляется одновременно с кодом.
 
 Логика протокола, API и поведение сервера описаны отдельно:
 
@@ -156,6 +156,19 @@ Nonce/IV для `AES-GCM`.
 
 Сервер не должен трактовать это поле как UTF-8 текст и не должен пытаться расшифровывать его в обычной DM-логике.
 
+### Точная схема для `cryptoMethod = 1`, `cryptoVersion = 0`
+
+- публичный ключ получателя для E2EE получается как стандартное преобразование `Ed25519 -> X25519`;
+- отправитель генерирует ephemeral `X25519` приватный ключ и кладёт соответствующий `ephemeralPubKey` в контейнер;
+- общий секрет вычисляется как `X25519(ephemeralPrivKey, recipientX25519PubKey)`;
+- `HKDF-SHA256` использует:
+  - `salt = ephemeralPubKey || recipientX25519PubKey`
+  - `info = "SHiNE_DM|1|0|X25519+HKDF-SHA256+AES-256-GCM"` в ASCII
+  - `outputLen = 32`
+- полученные `32` байта используются как ключ `AES-256-GCM`;
+- поле `cipherText` хранит стандартный результат библиотеки `AES-GCM` в виде:
+  - `ciphertext || tag`
+
 ## 6. Поле `body` для типов `3/4`
 
 Для read-receipt типов `3/4` поле `body` содержит открытый контейнер ссылки на исходное сообщение:
@@ -291,8 +304,6 @@ ReadReceiptBody_v1_0
 - ciphertext может различаться;
 - `reencryptedAtMs` при одной парной ревизии тоже должен совпадать.
 
-## 13. Примечание о текущем коде
+## 13. Примечание о поддержке
 
-В текущем коде типы `3/4` пока ещё реализованы старым контейнером `SHiNE_dm2`.
-
-Для версии протокола v1 целевой формат фиксируется уже как единый `SHiNE_DM` для всех типов `1..8`.
+В версии DM v1 все типы `1..8` используют единый контейнер `SHiNE_DM`.