# Наскрізне шифрування, пояснене по-справжньому > Cuadernos Lacre · Концепція · 18 травня 2026 > https://solo2.net/uk/notebooks/articulos/end-to-end-encryption-actually-explained.html Що кажуть провайдери, коли кажуть про E2EE, і про що вони замовчують. Дидактичне пояснення механізму та його меж без рекламної упаковки. --- > Давайте прояснимо: WhatsApp каже, що ваші повідомлення захищені наскрізним шифруванням. Це правда — і цього недостатньо. Якщо резервна копія відправляється в iCloud або Google Drive без додаткового шифрування, шифрування ламається на вашому власному телефоні. Оперативне питання полягає не в тому, чи зашифровано повідомлення, а в тому, де знаходяться ключі. ## Що шифрування означає насправді Зашифрувати повідомлення — значить перетворити його на щось, що виглядає як шум для будь-кого, хто не володіє певною інформацією, яка називається ключем. Операція виконується на пристрої відправника і за допомогою правильного ключа скасовується на пристрої одержувача. У проміжку повідомлення передається як послідовність байтів без видимого сенсу. Це проста ідея. Решта статті присвячена нюансам, які перетворюють її, залежно від випадку, на реальну гарантію або лише на маркетинговий ярлик. Прикметник *наскрізне* — англійською *end-to-end*, скорочено E2EE — додає точності. Шифрування виконується не для того, щоб проміжний сервер міг його прочитати та доставити. Воно виконується для того, щоб тільки обидві сторони — пристрій відправника та пристрій одержувача — володіли ключем. Будь-який сервер, через який проходить повідомлення, бачить шум, а не повідомлення. У цьому полягає технічна відмінність від шифрування *при транзиті*, коли контент передається у зашифрованому вигляді від одного сервера до іншого, але кожен сервер, через який він проходить, розшифровує його для пересилання, тимчасово відновлюючи відкритий текст. ## Парадокс спільного секрету Існує очевидна проблема. Щоб дві людини могли шифрувати та розшифровувати повідомлення один одного, обом потрібен один і той самий ключ. Але як домовитися про цей ключ, якщо все, що вони надсилають один одному, за визначенням проходить через канал, де хтось може підслуховувати? Домовитися про ключ у тому самому каналі, де вони пізніше будуть його використовувати, здається неможливим: якщо зловмисник почує його при узгодженні, він зможе розшифрувати все подальше. Протягом десятиліть класична криптографія вирішувала це жорстким способом: ключі передавалися особисто, до початку використання, при фізичних зустрічах. Посли носили портфелі з ключами, вшитими в підкладку пальто. У сучасній електронній пошті таке рішення не масштабується. Якби нам довелося фізично йти додому до кожної людини, з якою ми маємо намір спілкуватися у зашифрованому вигляді, ми б ні з ким не встигли поговорити. Питання, поставлене п'ятдесят років тому криптографічною спільнотою, звучало так: чи можливо, щоб дві людини, які не знають одна одну і які ділять тільки відкритий канал, домовилися у цьому самому відкритому каналі про секрет, який ніхто, хто слухає канал, не зможе дізнатися? ## Елегантність Diffie-Hellman У 1976 році два математики, Уітфілд Діффі та Мартін Хеллман, довели щось на перший погляд неможливе: що дві людини, розмовляючи тільки через відкритий канал — канал, де будь-хто може чути все, що вони говорять, — можуть домовитися про секретний пароль так, щоб жоден слухач не міг його розкрити. Це звучить як магія. Але це не так: це математика. Обмін ключами Діффі-Хеллмана, як він відомий відтоді, є основою практично всього зашифрованого зв'язку в інтернеті, і півстоліття інтенсивного використання та всесвітнього академічного аналізу підтверджують його надійність. Той, хто хоче побачити візуальну інтуїцію або математику, може читати далі. Той, хто воліє вірити, що це працює, також може продовжити, не втрачаючи нитки статті. Для тих, хто хоче уявити це наочно, існує відома аналогія з кольорами. Уявіть, що Аліса та Бруно відкрито домовляються про базовий колір — скажімо, жовтий — на очах у Єви, яка їх підслуховує. Кожен з них таємно вибирає другий секретний колір і змішує свій секрет із жовтим. Аліса отримує особливий помаранчевий; Бруно отримує особливий зелений. Вони обмінюються результатами на очах у Єви. Тепер кожен змішує отриманий колір зі своїм секретом, і обидва приходять до одного й того самого кінцевого кольору, оскільки порядок змішування не має значення. Єва бачила жовтий і дві проміжні суміші, але не секрети; без одного із секретів вона не зможе отримати кінцевий колір. Реальна математика замінює кольори піднесенням до степеня у модулярних групах або на еліптичних кривих, але ідея та сама: спільний секрет створюється публічно без можливості його відновлення будь-ким у каналі. ## Від Diffie-Hellman до протоколу Signal Наскрізне шифрування, яке використовують сьогодні професійні додатки для обміну повідомленнями, майже без винятку спирається на елегантну та посилену версію обміну Діффі-Хеллмана. Протокол Signal, розроблений Тревором Перріном та Моксі Марлінспайком у період з 2013 по 2016 рік, є еталоном. Він поєднує в собі дві ключові ідеї. Перша — обмін ключами на еліптичних кривих (X25519), який створює початковий спільний секрет між двома пристроями. Друга — так званий Double Ratchet — подвійний храповик, — який автоматично оновлює ключі з кожним повідомленням, так що компрометація пристрою сьогодні не дозволяє розшифрувати повідомлення з минулого, так само як і повідомлення з майбутнього після повороту храповика. ## Що захищає наскрізне шифрування Що E2EE захищає добре, за умови правильної реалізації, — це вміст повідомлення при транзиті. Проміжний сервер, що приймає та пересилає зашифровані дані, побачить послідовність незрозумілих байтів. Зловмисник із доступом до кабелю, роутера, точки доступу Wi-Fi побачить те саме. Провайдер послуг, що зберігає копії трафіку, не зможе прочитати його згодом. Уряд, що наказав оператору зв'язку видати вміст, отримає ті самі незрозумілі байти, які сервер мав спочатку. Це, у практичному плані, дуже багато. Це різниця між написанням листа всередині непрозорого конверта та написанням його на листівці. І те, і інше доходить до адресата. Але тільки одне зберігає вміст у таємниці від листоноші. ## Що не захищає наскрізне шифрування Це варто знати так само добре. E2EE не захищає метадані: сервер все одно знає, що користувач А надсилає дані користувачу Б, о котрій годині, з якою частотою і звідки, хоча й не знає, що саме він каже. Ці метадані, як ми вже аргументували у статті *Шифрувати — не означає бути приватним*, часто є більш показовими, ніж сам контент. Знання того, що хтось телефонував до адвокатської контори, яка спеціалізується на розлученнях, у п'ятницю о 22:00 протягом тридцяти хвилин, розповідає історію, яку зміст дзвінка ніколи б не розповів. Це та сама ситуація, що й спостереження за людиною, яка кілька разів входить і виходить з онкологічної клініки: не потрібно чути нічого з того, про що говорять всередині, щоб уявити, що відбувається. Один ізольований метаданий може нічого не значити; кілька перехресних даних малюють щось занадто схоже на правду. E2EE не захищає кінцеві пристрої: якщо пристрій одержувача скомпрометований шкідливою програмою, повідомлення розшифровується для цього одержувача у звичайному режимі, і шкідлива програма його читає. E2EE не захищає від підміни особи співрозмовника як такої: якщо Аліса вірить, що розмовляє з Бруно, але зловмисник вклинився на самому початку (атака *man in the middle*), а протокол не передбачає незалежної перевірки, обидві сторони в результаті розмовляють із непроханим гостем, думаючи, що говорять одна з одною. Є четверта річ, яку варто сформулювати недвозначно. E2EE не заважає провайдеру, який стверджує, що він його пропонує, додатково зберігати копію незашифрованого повідомлення у своїх власних системах. Твердження «мої повідомлення зашифровані наскрізним шифруванням» і твердження «провайдер не зберігає мій контент» — не одне й те саме. Додаток може виконувати перше, порушуючи друге; ми неодноразово бачили це у заголовках газет з 2018 року. Користувач, якщо тільки код клієнта не є таким, що можна перевірити, не має технічного способу відрізнити один випадок від іншого без експертного розслідування. Найвідоміший випадок серед широкої публіки: WhatsApp шифрує повідомлення наскрізним шифруванням при транзиті, але якщо користувач активує резервне копіювання в iCloud або Google Drive без додаткового шифрування, ця копія зберігається у придатному для читання вигляді в інфраструктурі третьої сторони, і шифрування порушується на стороні самого користувача. ## Питання, яке оператор не хоче чути Додаток, що стверджує, що він шифрує наскрізним шифруванням, технічно може робити одну з трьох реćей щодо ключів: Отже, оперативне питання полягає не в тому, чи зашифровано щось, а в тому, хто контролює пристрій і програмне забезпечення, що керує ключами. У Solo2 ключі зберігаються виключно у вашому «Сейфі» (IndexedDB, зашифрована вашим паролем), а програмне забезпечення є відкритим вихідним кодом, що підлягає перевірці. ## Для професійного читача Наскрізне шифрування — це інструмент цифрового суверенітету. Але, як і будь-який інstrument, його ефективність залежить від руки, яка його тримає, і ґрунту, на якому він стоїть. 1. Де генеруються криптографічні ключі і де вони фізично знаходяться? Якщо оператор може отримати до них доступ (навіть тимчасово, навіть під виглядом відновлення), то E2EE є лише номінальним. 2. Чи існує незалежна перевірка співрозмовника (коди безпеки, QR-коди, порівняння поза каналом), яка запобігає атаці man-in-the-middle під час встановлення розмови? 3. Чи підлягає код клієнта аудиту — чи є він відкритим, опублікованим, відтворюваним — або ж він вимагає довіри слову провайдера про те, що клієнт робить насправді? 4. Які метадані генерує та зберігає сервіс, і як довго? Навіть якщо контент є непрозорим, метадані можуть відновити значну частину конфіденційної інформації. Ці чотири питання не вимагають складної технічної інформації; вони запитують інформацію, на яку будь-який чесний оператор може відповісти у своїй публічній документації. Якість і точність відповіді говорять про продукт не менше, ніж сама відповідь. --- *Наскрізне шифрування, якщо воно виконане правильно, є однією з найвитонченіших конструкцій, які сучасна криптографія принесла в повсякденну практику. Оригінальна ідея — двоє людей можуть домовитися про секрет через відкритий канал — належить Whitfield Diffie та Martin Hellman, 1976 рік; через півстоліття ми продовжуємо жити в її наслідках. Але, як і з будь-якою технічною обіцянкою, її цінність залежить від реального виконання, а не від ярлика. Питання чесного професіонала не в тому, «чи це зашифровано?», а в тому, «у кого ключі?». Відповіді мають різні наслідки. Варто їх знати.* ## Джерела та додаткова література - Diffie, W.; Hellman, M. — *New Directions in Cryptography*, IEEE Transactions on Information Theory, листопад 1976 р. Основоположна стаття з криптографії з відкритим ключем. - Perrin, T.; Marlinspike, M. — *The Double Ratchet Algorithm*, публічна специфікація від Open Whisper Systems, редакція 2016 р. Основа протоколу Signal та його промислових похідних. - RFC 7748 — Elliptic Curves for Security (IETF, січень 2016 р.). Нормативна специфікація кривих X25519 та X448, що використовуються у сучасних обмінах ключами. - Ferguson, N.; Schneier, B.; Kohno, T. — *Cryptography Engineering: Design Principles and Practical Applications* (Wiley, 2010). Розділи про обмін ключами та протоколи автентифікованого шифрування. - Регламент (ЄС) 2024/1183 про європейську систему цифрової ідентифікації (eIDAS 2) — встановлює рамки, в яких незалежна перевірка співрозмовника набуває інституційної підтримки, і де відмінність між номінальним та реальним шифруванням має різні юридичні наслідки. --- *Cuadernos Lacre · Видання Menzuri Gestión S.L. · автор R.Eugenio · під редакцією команди Solo2.* *https://solo2.net/uk/notebooks/*