Як працює Livara: Докладна версія.

01 · наскрізне шифрування

Що тут насправді означає наскрізне шифрування

У чаті Livara вміст повідомлення й будь-які медіа шифруються на вашому пристрої та відкриваються лише на пристрої одержувача. Сервер переміщує коробку, яку не може відкрити.

Кожен пристрій зберігає закритий ключовий матеріал P-256 і ML-KEM-768. Резервні копії для відновлення шифруються на пристрої до завантаження. Особисті чати встановлюють LVR1 із класичним і постквантовим внесками, а потім просувають ланцюжки надсилання й отримання під час обміну повідомленнями.

AES-256-GCM шифрує вміст і засвідчує його контекст. Вкладення отримують окремий випадковий файловий ключ до завантаження; він передається всередині зашифрованої розмови, а не розкривається серверу.

Під час захищеної доставки повідомлень сервер пересилає зашифрований вміст і обробляє метадані маршрутизації. Публічні канали й необов’язкова обробка ШІ мають інші правила доступу до даних; див. модель загроз і політику конфіденційності.

02 · охоплення

Як наскрізне шифрування захищає ваші чати

Особисті чати й сумісні приватні групи використовують наскрізне шифрування на вашому пристрої. Публічні канали доступні для читання; старі несумісні групи не входять до цього охоплення.

Текст особистих повідомлень, редагування, підписи, голосові нотатки й вкладення шифруються на клієнтському пристрої гібридним постквантовим механізмом LVR1 з оновленням ключів. Якщо ключів немає або вони недійсні, надсилання блокується, а не непомітно перемикається на відкритий текст.

Livara 0.2 використовує шифрування LGS1 із ключами відправників для сумісних приватних груп. Кожен учасник створює ланцюжок надсилання й шифрує текст, медіа та вкладення на своєму пристрої. Ключі змінюються зі складом групи; модель загроз пояснює залишкову довіру до керованого сервером списку учасників.

Особисті й групові дзвінки підтримують наскрізне шифрування аудіо, відео та демонстрації екрана. Необов’язковий запис на сервері використовує транспортне шифрування замість E2EE, поки активний стан REC. Публічні трансляційні канали залишаються читаними сервером.

03 · випуск

Примітки до випуску Livara 0.1.68

Історичні примітки до випуску. Поточну збірку застосунку Livara для Android і контрольну суму дивіться на сторінці завантаження.

Історичні примітки до випуску. Поточну збірку застосунку Livara для Android і контрольну суму дивіться на сторінці завантаження.

У перському інтерфейсі поле введення простого режиму відображає «AI».

Для функцій API ШІ потрібна Livara AI Pro.

04 · відновлення

Що відбувається в разі втрати пристрою

Фраза відновлення відкриває зашифровану резервну копію вашого ключового матеріалу узгодження, підпису й постквантової ідентичності. Це не резервна копія історії чатів.

Ваш ключ узгодження P-256, ключ підпису P-256 і початкове значення ML-KEM об’єднуються й шифруються на пристрої за допомогою випадкового 256-бітного ключа відновлення, HKDF-SHA-512 та AES-256-GCM, а потім завантажуються вже зашифрованими. Самого правильного пароля недостатньо, щоб відкрити цю копію.

Формат резервної копії v7 засвідчує версію, набір алгоритмів, епоху ідентичності й монотонно зростаюче покоління. Пристрій, що повертається до системи, може виявити старішу копію; новому пристрою для виявлення повного відкочування серверного знімка й далі потрібна прозорість ключів.

Можна порівняти відбитки відкритих ключів зі співрозмовником іншим каналом, щоб помітити ключ, який змінився без підстав.

Якщо втратити і пристрій, і фразу відновлення, старий шифротекст особистих чатів залишиться закритим. Звернення до підтримки цього не змінить. Така справжня ціна сервера, який не може читати ваші повідомлення.

05 · синхронізація

Навіщо живому з’єднанню потрібен журнал змін

Живе з’єднання повідомляє лише про те, що відбувається зараз. Індивідуальний номер послідовності користувача заповнює пропуски, поки потяг був у тунелі.

Живе з’єднання — лише частина надійного обміну повідомленнями. Важливо, як застосунок виявляє й відновлює зміни, пропущені під час розриву зв’язку.

Кожна значуща зміна також просуває безперервний індивідуальний номер послідовності користувача. Тому клієнт, що перепідключився, запитує саме пропущений діапазон, а не вгадує й не завантажує весь обліковий запис заново.

Клієнти усувають дублікати за сталими ID операцій і звіряють дані зі знімком сервера, перш ніж просунути збережений курсор. Тому одна думка, надіслана за поганого сигналу, не перетворюється на три бульбашки.