Шифрування визначає, які ключі відкривають повідомлення; окремо потрібно перевірити, до кого потрапили ці ключі.
Ні: наскрізне шифрування групи саме по собі не запобігає появі прихованого учасника. Відповідь на запитання «Чи може сервер додати учасника групи?» залежить від механізму членства й перевірки учасників, а не лише від шифрування повідомлень. Згідно з документацією Livara, LGS1 шифрує вміст сумісних приватних груп, які справді працюють у режимі E2EE. Ротація ключів після зміни складу призначена для обмеження майбутнього доступу й потребує застосування оновлень членства та ключів на пристроях; вона не відкликає вже отримані копії.
Головне
- Наскрізне шифрування спрямоване на конфіденційність повідомлень, але безпека списку учасників потребує окремого механізму.
- У сумісній приватній групі Livara з підтвердженим станом E2EE LGS1 охоплює повідомлення, редагування й ключі вкладень; не поширюйте це твердження на несумісні старі групи.
- Порівнювати Signal, WhatsApp, SimpleX і Element лише за позначкою «зашифровано» недостатньо: потрібно оцінювати сповіщення про зміну складу, роль адміністратора й спосіб перевірки особи.
- Інтерфейс не за будь-яких умов може виявити вступ дозволеного облікового запису під контролем зловмисника; учасникам слід незалежно перевіряти особи й важливі зміни.
- Proof Lab Livara надає локальні демонстрації P-256, HKDF і AES-GCM та перевірку хешу файла; це не повна реалізація або незалежний аудит LVR1/LGS1.
Чи запобігає шифрування групи прихованим учасникам?
Ні, якщо протокол не забезпечує також криптографічно захищене, перевірюване узгодження стану членства між учасниками. Тут «прихований учасник» — обліковий запис із доступом до майбутніх повідомлень, хоча люди в групі не помітили його вступу або неправильно встановили його особу.
Наскрізне шифрування означає, що читати повідомлення повинні лише пристрої сторін розмови; проте ці пристрої мають знати, кому надсилають ключ. Якщо сервер може змінювати список одержувачів, шифрування може працювати правильно й водночас шифрувати повідомлення для небажаного учасника. Щоб розрізняти вміст і метадані, дивіться посібник «Наскрізне шифрування та його межі».
Тому «атака сервера на зашифровану групу» не обов'язково означає злам AES або розв'язання математичної задачі. Контролюючи членство, сервер може додати дійсний обліковий запис до майбутніх одержувачів. Історія повідомлень, ключів до яких цей запис не мав, — окреме питання; головний ризик стосується доступу після вступу.
Що відомо про членство в групах Livara?
Документація безпеки Livara відокремлює серверне керування членством і ролями від шифрування вмісту. Це важлива межа для оцінки, але сама по собі вона не доводить успішної практичної атаки або цілком непомітного вступу. Для такого твердження потрібно перевірити поведінку клієнта, розподіл ключів, сповіщення про зміну складу й умови атаки.
Правильне запитання: чи перевіряють пристрої зміни списку незалежно та що показують користувачу перед надсиланням ключа новому учаснику? Ця стаття не подає результатів аудиту або тестування Livara на проникнення.
Чим відрізняється безпека списку учасників у п'яти месенджерах?
Головні відмінності — хто дозволяє зміну складу, як учасники про неї дізнаються та чи можуть незалежно підтвердити особу нового облікового запису. Саме існування наскрізного шифрування не дає повної відповіді щодо довіри до сервера месенджера.
| Месенджер | Вміст групи | Членство й практична довіра | Обережний висновок |
|---|---|---|---|
| Livara | У сумісній приватній групі з E2EE LGS1 охоплює текст, редагування й ключ вкладення. | Коли склад змінюється, ключі відправників автоматично створюються знову й перерозподіляються. | Згідно з документацією продукту, вміст сумісної приватної групи та ключі медіа захищені до доставлення; перевіряйте стан конкретної групи. |
| Signal | Довідка Signal про групи повідомляє, що сервіс не записує членство, назви, зображення й атрибути груп. | Те саме джерело зазначає, що адміністратор може визначати, хто додає учасників, і вмикати схвалення адміністратором для групових посилань; учасники все одно мають помічати зміни складу. | Архітектура обмежує знання сервісу, але користувачі повинні перевіряти зміни складу та особи облікових записів. |
| Огляд шифрування WhatsApp зазначає, що особисті й групові повідомлення мають наскрізне шифрування. | Довідковий матеріал WhatsApp описує добровільне надання частини історії новому учаснику й право адміністратора обмежити таке надання. | Вміст групи шифрується, але правильність членства слід оцінювати за адміністративними засобами й сповіщеннями застосунку. | |
| SimpleX | Документація груп SimpleX говорить, що кожен учасник має окремі з'єднання з іншими. | Специфікація протоколу описує групи як сукупність зв'язків між учасниками з ролями й повідомленнями про зміни складу; це не суперечить існуванню адміністратора-людини. | Відсутність глобального ідентифікатора групи не усуває всіх ризиків членства або заражених пристроїв. |
| Element / Matrix | Специфікація наскрізного шифрування Matrix визначає подію m.room.encryption та алгоритми шифрування кімнати. |
Специфікація членства Matrix моделює членство подіями m.room.member у стані кімнати, які поширюють домашні сервери. |
Шифрування кімнати та стан членства — два окремі рівні; учасникам слід перевіряти пристрої й зміни в кімнаті. |
Це не абсолютний рейтинг. Кожна система має власну модель загроз, а застосунок, пристрій, адміністрування групи й поведінка учасників можуть змінювати результат. Для практичного вибору використовуйте «12 запитань із контрольного списку безпечного месенджера» разом з офіційними документами кожного продукту.
Як порівнювати довіру до сервера месенджера?
Не зводьте довіру до відповіді «так» або «ні»: запитуйте, що саме сервер бачить і може змінювати. Сервер, який не читає текст, усе ще може контролювати час спілкування, склад групи або розподіл початкових ключів.
По-перше, окремо розгляньте конфіденційність вмісту
Перевірте, де саме шифруються повідомлення, редагування, реакції, назви, вкладення та їхні ключі. За документацією Livara LGS1 охоплює текст, редагування й ключі вкладень сумісної приватної групи з E2EE; це твердження не стосується каналів.
По-друге, визначте, хто керує членством
З'ясуйте, хто може запрошувати учасників, хто схвалює запити й як клієнт показує зміну. Якщо сервер нав'язує стан групи, компрометацію сервера необхідно явно включити до моделі загроз.
По-третє, відокремте особу від членства
Знайоме ім'я не доводить, що ключ належить саме цій людині. У Livara safety number дозволяє порівняти відбиток ключа поза застосунком; сам цей інструмент не означає перевірки всього списку учасників. Приписуйте продукту прозорість ключів лише за наявності документації.
По-четверте, відокремте свідчення від заяв
Документація продукту, звіт про аудит і незалежне тестування — не одне й те саме. Надійний звіт має визначати версію, обсяг перевірки, знахідки й виправлення. Назва алгоритму або узгодженість двох реалізацій самі по собі не доводять безпеки керування членством.
Як перевіряти учасників групового чату?
Учасникам слід негайно перевіряти зміни списку й незалежним каналом підтверджувати особи людей, важливих для безпеки. У розмові з високим ризиком самого імені, фотографії або номера облікового запису недостатньо: ці ознаки можуть бути помилковими, повторно виданими або під контролем зловмисника.
У Livara двоє людей можуть порівняти safety number особисто, під час відомого їм дзвінка або незалежним шляхом. Це може виявити неочікувану зміну ключа; однак парне порівняння саме по собі не охоплює водночас усіх учасників великої групи. Практичні кроки описано в посібнику «Перевірка чату за допомогою safety number».
Для чутливих груп корисний такий короткий порядок дій:
- Наскільки можливо, залиште право додавання учасників лише адміністраторам.
- Одразу перевіряйте кожне сповіщення про вступ, вихід або зміну ролі.
- Підтверджуйте особу нового учасника поза цією групою.
- Після підозрілої зміни припиніть надсилати чутливі відомості й створіть нову групу з перевіреними учасниками.
- Періодично переглядайте пристрої та пов'язані сеанси кожного облікового запису.
Ці дії знижують ризик, але не виправляють недоліків архітектури членства. Якщо сервер або обліковий запис адміністратора скомпрометований, а інтерфейс погано показує зміну, користувач усе ще може не помітити вступу.
Поширені запитання
Чи може сервер додати учасника, не зламавши шифрування?
Так, якщо архітектура месенджера віддає серверу контроль списку учасників. Тоді серверу не потрібно ламати шифр: він може додати обліковий запис до майбутніх одержувачів, щоб клієнти шифрували повідомлення і для нього. Можливість і спосіб цього залежать від протоколу членства кожного продукту.
Як працює протокол LGS1 у групах Livara?
Згідно з документацією продукту, у сумісних приватних групах з E2EE LGS1 використовує ланцюжок ключів і підпис відправника для захисту вмісту та ключів вкладень. Обмеження майбутнього доступу після виходу учасника залежить від застосування зміни складу й розподілу нового ключа. Proof Lab надає лише локальну демонстрацію кількох криптографічних компонентів і перевірку хешу; це не повна реалізація LGS1, аудит протоколу або доказ безпеки керування членством.
Чи доводить порівняння safety number появу прихованого учасника?
Ні. Порівняння safety number незалежно перевіряє ідентичність ключа між двома людьми й може виявити неочікувану зміну ключа. Але воно не доводить, що до групи не вступив хтось інший; список, сповіщення про членство й особи важливих для безпеки облікових записів слід перевіряти окремо.
Який месенджер має найбезпечніший список учасників?
За цими джерелами неможливо визначити абсолютного переможця: Signal, WhatsApp, SimpleX, Element і Livara мають різні моделі членства й загроз. Правильний вибір залежить від ваших ризиків: перевіряйте, хто контролює членство, як повідомляють про зміни та чи можна перевіряти особи учасників незалежно від сервера.
