Concepts/OpenPGP For Beginners/uk: Difference between revisions

From KDE Wiki Sandbox
(Created page with "У OpenPGP використовуються пари ключів. Це означає, що завжди є пара ключів, яка складається з «закр...")
No edit summary
 
(28 intermediate revisions by the same user not shown)
Line 13: Line 13:
У OpenPGP використовуються пари ключів. Це означає, що завжди є пара ключів, яка складається з «закритого ключа» і «відкритого ключа». На відміну від дуже простої концепції симетричного шифрування (тобто використання того самого пароля для шифрування та розшифровування даних), концепцію пари ключів зрозуміти складніше. Втім, цим можна не перейматися, просто прийміть це як даність: математична основа такого способу шифрування є доволі складною, отже, для більшості людей пояснення цієї основи буде складним і не дуже потрібним для користування завданням.
У OpenPGP використовуються пари ключів. Це означає, що завжди є пара ключів, яка складається з «закритого ключа» і «відкритого ключа». На відміну від дуже простої концепції симетричного шифрування (тобто використання того самого пароля для шифрування та розшифровування даних), концепцію пари ключів зрозуміти складніше. Втім, цим можна не перейматися, просто прийміть це як даність: математична основа такого способу шифрування є доволі складною, отже, для більшості людей пояснення цієї основи буде складним і не дуже потрібним для користування завданням.


As the names suggest: The secret key is to be known to its owner only, and the public key should be known to everyone ideally. With symmetric encryption the problem was to safely share the password with the recipient of a message. With public keys the problem has changed: Now the hard part is to be sure that you are using the correct public key (and not a forged one an attacker tries to trick you into using).
Як можна зрозуміти з назв, закритий ключ має бути відомим лише його власнику, а відкритий ключ, за ідеальних умов, має бути відомим усім. У разі використання симетричного шифрування завжди виникає проблема безпечного передавання пароля справжньому отримувачеві повідомлення. Перед користувачами відкритих ключів постає інша проблема: як переконатися у тому, що використовується належний відкритий ключ, а не ключ, підроблений зловмисником, який намагається змусити вас ним скористатися.


== Шифрування ==
== Шифрування ==


One of the two functions of OpenPGP is encryption. You encrypt data to one ore more public keys (symmetric encryption i.e. using a password instead is possible but rarely used). For decrypting the data the secret key of one of the recipient keys is needed.  
Одним із двох призначень OpenPGP є шифрування. Ви шифруєте дані одним або декількома відкритими ключами (тут можливе і симетричне шифрування, тобто шифрування за допомогою пароля, але таке шифрування використовується не часто). Для розшифровування ж зашифрованих даних потрібен буде закритий ключ одного з отримувачів даних.  


Except for the already mentioned problem "Which is the right key to encrypt for?" encryption - decryption is a quite simple operation because there is no room for misunderstanding: You encrypt something and nobody except the owner(s) of the recipient key(s) can read it. And you can either decrypt data or you can't. The decrypted data itself may be hard to understand but the decryption operation is not. But: Part of the "Which is the right key to encrypt for?" question is not only "Who is the owner of this key?" but also "Is this key secure enough for the data to be encrypted?". This is not about key length or similar but about key handling. Thus at least before sending critical information: Ask the key owner about the security level of the key!
Окрім вже згаданої проблеми «Яким є належний ключ для шифрування?», шифрування-дешифрування є доволі простою дією, оскільки тут усе однозначно: ви щось шифруєте, і ніхто, окрім власників ключа отримування, не може це прочитати. Ви або можете розшифрувати дані або не можете цього зробити. Розшифровані дані може бути важко зрозуміти, але зрозуміти саму дію з дешифрування просто. Втім, частиною питання «Яким є належний ключ для шифрування?» є не лише «Хто власник цього ключа?», але і «Чи є цей ключ достатньо безпечним для того, щоб шифрувати ним дані?». І тут йдеться не лише про довжину ключа або іншій його технічні характеристики, але про те, як поводяться з цим ключем. Тому, просте правило, яким слід користуватися перед надсиланням дуже важливих даних: попросіть власника ключа підтвердити рівень захисту ключа!


== Цифрові підписи ==
== Цифрові підписи ==


The encryption of data can be kind of reversed: Instead of creating data which only one key can understand you can create data which everyone can understand but which only one key can have created. This impossibility to create the same data without access to the respective secret key makes this data a signature. Once again: Don't ask for how this is possible unless you really like math.  
Шифрування даних можна певним чином виконати у зворотному напрямку: замість створення даних, які можна зрозуміти лише за допомогою одного ключа, ви можете створити дані, які зможе зрозуміти кожен, але які можна створити лише за допомогою єдиного ключа. Ця неможливість створення тих самих даних без доступу до закритого ключа робить ці дані придатними для підписування. І знову ж таки: не запитуйте, чому це так, якщо не хочете мати справу з математичними доведеннями.  


One of the great things about digital cryptography is: In contrast to a handwritten signature it is very easy for everyone (OK: for everyone's computer) to check that this signature was made by a certain key. If you can relate a certain key to a person then you can also relate a digital signature to this person – unless, of course, the key has been compromised. You may have noticed: At this point the task becomes an organizational and legal one.  
Однією з величезних переваг цифрової криптографії є те, що, на відміну від рукописного підпису, кожен може доволі просто (гаразд, доволі просто за допомогою комп’ютера) перевірити те, чи було створено підпис за допомогою певного ключа. Якщо ви можете пов’язати певну особу з певним ключем, ви також можете пов’язати цифровий підпис з тією самою особою, — звичайно ж, якщо цей ключ не було певним чином скомпрометовано. Як ви певне вже зауважили, на цьому кроці питання переходить до організаційної або юридичної площини.  


Technology does not solve all of your problems. And it is extremely important that you are always aware where the border between the technical and organizational problems is.
Технологія не здатна розв’язати усі ваші проблеми. Тому дуже важливо, щоб ви завжди розуміли, де проходить межа між технічними і організаційними проблемами.


And relating a key to a person is not the hard part! That is: "What does the signature mean?" Is your interpretation of a signature legally binding for its creator? The meaning can be as low as a timestamp (which is a perfectly valid an serious application for crypto signatures!), proving nothing more than that a certain document existed at a certain time (and was not created later).  
Пов’язування ключа з особою не є важким завданням! Тобто, важливим є розуміння того, що означає певний підпис. Чи точно пов’язує ваша інтерпретація підпису з особою, яка поставила цей підпис? Сам підпис може містити таку саму інформацію як і часова позначка (це особливо важливо для серйозних застосувань криптографічних підписів!), така позначка означає не більше того, що документ було створено у певний момент часу (а не пізніше).  


If somebody signs all his emails (to prevent address forgery) then the pure fact that he sent a certain document within such a signed email does not mean anything except for that he probably wanted to offer you a look at it. If the email (the signed part, not the unsigned subject) says something like "I accept the attached agreement" then the meaning is clear and the remaining risk of the recipient is mainly a technical one (compromised low security key).  
Якщо хтось підписує усі свої повідомлення електронної пошти (для запобігання шахрайському використанню адреси), сам факт надсилання певного документа у такому підписаному повідомленні не означає нічого, окрім того, що ця особа хоче, щоб ви ознайомилися з документом. Якщо у повідомленні (його підписаній частині, а не непідписаному вмісті) написано щось подібне до «Я погоджуюся з долученою угодою», значення долученого документа є зрозумілим, — решту захисту має забезпечити технологічна частина проекту (ключ для підписування має бути достатньо стійким і перебувати у надійних руках).  


Thus it makes sense to have different keys at different security levels: One for reasonably securing everyday tasks and another one for signing agreements (where the key policy documents explain the limits and privileges of the respective key).
Таким чином, доцільно мати різні ключі для різних рівнів захисту: один для забезпечення помірного рівня захисту для щоденних дій і інший для підписування угод (де документи з правил поводження з ключами роз’яснюють обмеження та права, що відповідають кожному з ключів).


In contrast to encryption the signature of data does not (technically) have an addressee. Everyone with access to the public key can check the signature. In many cases that is not a problem (or in contrast: It may even be a requirement). Instead of selecting an addressee you select the secret key which shall be used to create the signature (if you have more than one).
На відміну від шифрування, підписування даних (технічно) не має адресата. Перевірити підпис можна кожен, хто має доступ до відкритого ключа. У багатьох випадках така перевірка є безпроблемною (вона може бути навіть обов’язковою). Замість вибору адресата ви вибираєте закритий ключ, яким слід скористатися для створення підпису (якщо у вас декілька таких ключів).


The big "Which is the right public key?" problem occurs with signatures, too. Not with creating signatures but when interpreting a successful signature validation. The real life question is: "What does a signature mean?" Obviously a signature by "any" key does not mean anything. Everyone can have created it. The signature itself does not state more than: "Somebody with access to the secret key decided to create this signature." This is a technical fact without relevance in real life.
Велика проблема «Яким є належний відкритий ключ?» є актуальною і для підписів. Проблему пов’язано не зі створенням підписів, а з інтерпретацією успішної перевірки чинності підпису. Насправді, питання можна сформулювати так: «Що означає певний підпис?» Звичайно ж, підписування довільним ключем не означає нічого. Такий ключ може створити будь-хто. Сам підпис не означає нічого, окрім того, що хтось з доступом до закритого ключа вирішив створити цей підпис. Це просто технічний факт, який не пов’язано зі справжнім життям.




== Пов’язування ключів з людьми ==
== Пов’язування ключів з людьми ==


This is another hard and complicated part. And because only few people do this correctly the whole system is much less secure than most people believe. You have to tell apart four components of this check. The first is the easiest: the key itself. You have to be sure that you are using the right key material (just the huge random number itself).  
Це ще одна складна і заплутана частина. Оскільки лише деякі користувачі виконують її коректно, сама система є набагато менш захищеною, ніж багато хто думає. Вам слід переконатися у виконанні чотирьох окремих частин перевірки. Першою є сам ключ. Вам слід використовувати достатньо стійкий ключ (просто дуже велике випадкове просте число).  


As keys are to big to be compared manually a secure hash is used instead. Once again: Evil math stuff you fortunately need not understand. A hash function does this: You throw any kind and amount of data at it (from a single digit to a DVD image file) and it outputs a "number" of fixed length. If it is (considered) impossible to create two different inputs which create the same output then the hash function is secure.  
Оскільки самі ключі є надто великими для порівняння вручну, замість них використовується певна безпечна хеш-сума. І знову, математичні аспекти обчислення цієї суми, на щастя, розуміти не потрібно. Функція хешування працює так: ви передаєте їй довільний об’єм даних (від однієї цифри до вмісту цілого образу DVD), і функція виводить «число» фіксованої довжини. Якщо, як вважається, за двома різними вхідними наборами даних неможливо отримати однаковий результат, функція хешування вважається безпечною.  


OpenPGP currently uses the hash function [https://en.wikipedia.org/wiki/Secure_Hash_Algorithm SHA-1] for identifying keys. SHA-1 has security issues but they do not affect the usage in OpenPGP. A SHA-1 value looks like this:
У поточній версії OpenPGP для ідентифікації ключів використовується функція хешування [https://en.wikipedia.org/wiki/Secure_Hash_Algorithm SHA-1]. У SHA-1 є певні вади захисту, але вони не стосуються використання цієї функції у OpenPGP. Значення SHA-1 виглядає десь так:


     7D82 FB9F D25A 2CE4 5241  6C37 BF4B 8EEF 1A57 1DF5
     7D82 FB9F D25A 2CE4 5241  6C37 BF4B 8EEF 1A57 1DF5


This is called the fingerprint of the key. There are two ways of being safe about the identity of a key (the raw key material) without third parties involved: You get either the key itself from a secure source (USB stick handed over by the key owner) or you get the fingerprint from a secure source (which is obviously much easier as you can print is on small pieces of paper, even on your business card, and spread them).  
Подібний рядок називається відбитком ключа. Існує два способи переконатися у ідентичності ключа (необроблених даних ключа) без використання послуг сторонніх служб: ви можете отримати сам ключ з безпечного джерела (флеш-картки USB, переданої вам власником ключа) або отримати відбиток ключа з безпечного джерела (що, звичайно ж, набагато простіше, оскільки цей невеличкий рядок з цифр та літер можна надрукувати на шматочку паперу, навіть на вашій візитівці, а потім віддати його відповідній особі).  


Your OpenPGP application shows you the fingerprint of the key you got from an insecure source and you compare "what is" with "what it should be". If that is the same then you can be sure about the key itself. Thus: Always have small slips of paper with your fingerprint with you.
Ваша програма для роботи з OpenPGP покаже вам відбиток ключа, який ви отримали із якогось сумнівного джерела і ви зможете порівняти цей відбиток з еталонним. Якщо відбитки виявляться однаковими, ви можете бути певні щодо ідентичності ключа. Звідси висновок: завжди варто мати з собою папірці з надрукованим відбитком ключа.


A public OpenPGP key (a "certificate") consists of two parts: the key material and the user IDs. A user ID is just a text string. The typical usage of this string is:
Відкритий ключ OpenPGP («сертифікат») складається з двох частин: самих даних ключа та ідентифікаторів користувача ключа. Ідентифікатор користувача є простим текстовим рядком. Типовий приклад:


     Ім’я Прізвище (коментар) <адреса електронної пошти>
     Ім’я Прізвище (коментар) <адреса електронної пошти>


Many user IDs do not have a comment, some do not have an email address and there are keys without a (real) name, too (e.g. for anonymous usage). Even if you are sure about the fingerprint the name, email, and comment can be wrong.  
У багатьох ідентифікаторах користувачів немає коментаря, у деяких немає адреси електронної пошти, а для деяких ключів взагалі не вказують (справжнього) імені власника ключа (наприклад, для анонімного використання). Навіть якщо ви певні щодо ідентичності відбитка, ім’я, адреса електронної пошти та коментар можуть бути помилковими.  


Email is rather easy to check (send an encrypted message to the address and wait for a response which guarantees your message to be decrypted).  
Адресу електронної пошти можна легко перевірити. Надішліть зашифроване повідомлення на цю адресу і зачекайте на відповідь, яка гарантуватиме, що ваше повідомлення було розшифровано.  


Checking the identity of unknown persons is not easy. At keysigning parties this is done by checking passports and the like. But would you recognize a well forged passport?  
Перевірка ідентичності невідомих вам осіб є непростим завданням. На зустрічах з підписування ключів ця процедура виконується за допомогою перевірки паспортів та інших документів, які ідентифікують особу. Але чи здатні ви відрізнити якісну підробку паспорта від справжнього документа?  


Fortunately for your own purposes the identity is usually not so important. "The one I met on that event who calls himself Peter" is usually enough. So this is more a problem for the web of trust (see below).  
На щастя, для ваших особистих потреб ідентифікація, зазвичай, не є важливою. «Це той чоловік, якого я бачив на тій зустрічі, він назвався Петром,» — такої ідентифікації достатньо. Отже, це більше питання мережі довіри (див. нижче).  


Comments can be critial, too: The comment "CEO of whatever inc." may make a real difference (if not to you then to somebody else). The question when to accept (and certify) a user ID is a really complicated one.  
Коментарі також можуть бути важливими: коментар «Директор Компанії inc.» може бути доволі вирішальним (якщо не для вас, то для когось іншого). Питання підтвердження (і сертифікації) ідентифікатора користувача може бути вирішене на основі багатьох факторів.  


Most people don't understand this problem and thus reduce their own security and that of others. You can make this decision for others easier by having user IDs which consist of just your name or just your email address. This may be easier acceptable by someone checking your user IDs.
Більшість людей не розуміє цієї проблеми, знижуючи рівень захищеності власних даних та даних інших людей. Ви можете спростити рішення щодо ідентифікації для всіх, якщо вкажете у ідентифікаторі користувача ваше справжнє ім’я і вашу електронну адресу. Перевірка ваших ідентифікаторів користувача може спростити прийняття ваших ключів.


If you are sure about a user ID you should certify it. This means that you make a digital signature over the public key and this user ID. You can make this certification for yourself only (called a "local signature") or for the public (the "web of trust"). If a key has several user IDs then you can decide which ones you certify.  
Якщо ви певні у відповідності ідентифікатора користувача певній особі, вам слід сертифікувати ключ. Це означає, що ви створите цифровий підпис до відкритого ключа і ідентифікатора користувача. Ви можете виконати таку сертифікацію лише для себе (так званий «локальний підпис») або для усіх («мережа довіри»). Якщо з ключем пов’язано декілька ідентифікаторів користувачів, ви можете визначити той з них, який ви бажаєте сертифікувати.  


You can give a rough hint how well you have checked the user ID and key, too. It makes a big difference to OpenPGP applications (and so should it to you!) whether they recognize a key as "valid" or not.  
Також передбачено загальну оцінку того, наскільки ретельно було перевірено ідентифікатор користувача і ключ. Така оцінка має значний вплив на визначення програмами з підтримкою OpenPGP (а отже і вами!) того, чи слід вважати ключ «чинним».  


The keys you have the secret key for are considered valid automatically. The others can become valid by signatures of your own keys. And by keys of others.
Якщо ви є власником парного до ключа закритого ключа, ключ вважається чинним автоматично. Інші ключі набувають чинності після підписування їх вашими власними ключами або ключами інших довірених користувачів.


== Мережа довіри ==
== Мережа довіри ==


In connection with OpenPGP you will often hear about the web of trust. This in an indirect method for relating people to keys, a mighty but complicated technology. Beginners should not use the web of trust but first become familiar with verifying and certifying keys directly. The WoT is explained in the article [[Special:myLanguage/Concepts/OpenPGP_For_Advanced_Users|OpenPGP For Advanced Users]].
У обговореннях ключів OpenPGP часто згадується мережа довіри. Така мережа є непрямим способом пов’язування певних осіб з ключами, потужною, але складною технологією. Початківцям, перш ніж користуватися мережами довіри, варто добре ознайомитися з методиками безпосередньої перевірки і сертифікації ключів. Докладніший опис мережі довіри можна знайти у статті [[Special:myLanguage/Concepts/OpenPGP_For_Advanced_Users|OpenPGP для досвідчених користувачів]].




Line 97: Line 97:


|-
|-
| rowspan="2"| ваші закриті підключі
| rowspan="2"| ваш закритий підключ
| розшифровувати дані, які було зашифровано для вас
| розшифровувати дані, які було зашифровано для вас



Latest revision as of 18:41, 12 July 2013

Other languages:

Вступ

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

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

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

Асиметричний ключ

У OpenPGP використовуються пари ключів. Це означає, що завжди є пара ключів, яка складається з «закритого ключа» і «відкритого ключа». На відміну від дуже простої концепції симетричного шифрування (тобто використання того самого пароля для шифрування та розшифровування даних), концепцію пари ключів зрозуміти складніше. Втім, цим можна не перейматися, просто прийміть це як даність: математична основа такого способу шифрування є доволі складною, отже, для більшості людей пояснення цієї основи буде складним і не дуже потрібним для користування завданням.

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

Шифрування

Одним із двох призначень OpenPGP є шифрування. Ви шифруєте дані одним або декількома відкритими ключами (тут можливе і симетричне шифрування, тобто шифрування за допомогою пароля, але таке шифрування використовується не часто). Для розшифровування ж зашифрованих даних потрібен буде закритий ключ одного з отримувачів даних.

Окрім вже згаданої проблеми «Яким є належний ключ для шифрування?», шифрування-дешифрування є доволі простою дією, оскільки тут усе однозначно: ви щось шифруєте, і ніхто, окрім власників ключа отримування, не може це прочитати. Ви або можете розшифрувати дані або не можете цього зробити. Розшифровані дані може бути важко зрозуміти, але зрозуміти саму дію з дешифрування просто. Втім, частиною питання «Яким є належний ключ для шифрування?» є не лише «Хто власник цього ключа?», але і «Чи є цей ключ достатньо безпечним для того, щоб шифрувати ним дані?». І тут йдеться не лише про довжину ключа або іншій його технічні характеристики, але про те, як поводяться з цим ключем. Тому, просте правило, яким слід користуватися перед надсиланням дуже важливих даних: попросіть власника ключа підтвердити рівень захисту ключа!

Цифрові підписи

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

Однією з величезних переваг цифрової криптографії є те, що, на відміну від рукописного підпису, кожен може доволі просто (гаразд, доволі просто за допомогою комп’ютера) перевірити те, чи було створено підпис за допомогою певного ключа. Якщо ви можете пов’язати певну особу з певним ключем, ви також можете пов’язати цифровий підпис з тією самою особою, — звичайно ж, якщо цей ключ не було певним чином скомпрометовано. Як ви певне вже зауважили, на цьому кроці питання переходить до організаційної або юридичної площини.

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

Пов’язування ключа з особою не є важким завданням! Тобто, важливим є розуміння того, що означає певний підпис. Чи точно пов’язує ваша інтерпретація підпису з особою, яка поставила цей підпис? Сам підпис може містити таку саму інформацію як і часова позначка (це особливо важливо для серйозних застосувань криптографічних підписів!), така позначка означає не більше того, що документ було створено у певний момент часу (а не пізніше).

Якщо хтось підписує усі свої повідомлення електронної пошти (для запобігання шахрайському використанню адреси), сам факт надсилання певного документа у такому підписаному повідомленні не означає нічого, окрім того, що ця особа хоче, щоб ви ознайомилися з документом. Якщо у повідомленні (його підписаній частині, а не непідписаному вмісті) написано щось подібне до «Я погоджуюся з долученою угодою», значення долученого документа є зрозумілим, — решту захисту має забезпечити технологічна частина проекту (ключ для підписування має бути достатньо стійким і перебувати у надійних руках).

Таким чином, доцільно мати різні ключі для різних рівнів захисту: один для забезпечення помірного рівня захисту для щоденних дій і інший для підписування угод (де документи з правил поводження з ключами роз’яснюють обмеження та права, що відповідають кожному з ключів).

На відміну від шифрування, підписування даних (технічно) не має адресата. Перевірити підпис можна кожен, хто має доступ до відкритого ключа. У багатьох випадках така перевірка є безпроблемною (вона може бути навіть обов’язковою). Замість вибору адресата ви вибираєте закритий ключ, яким слід скористатися для створення підпису (якщо у вас декілька таких ключів).

Велика проблема «Яким є належний відкритий ключ?» є актуальною і для підписів. Проблему пов’язано не зі створенням підписів, а з інтерпретацією успішної перевірки чинності підпису. Насправді, питання можна сформулювати так: «Що означає певний підпис?» Звичайно ж, підписування довільним ключем не означає нічого. Такий ключ може створити будь-хто. Сам підпис не означає нічого, окрім того, що хтось з доступом до закритого ключа вирішив створити цей підпис. Це просто технічний факт, який не пов’язано зі справжнім життям.


Пов’язування ключів з людьми

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

Оскільки самі ключі є надто великими для порівняння вручну, замість них використовується певна безпечна хеш-сума. І знову, математичні аспекти обчислення цієї суми, на щастя, розуміти не потрібно. Функція хешування працює так: ви передаєте їй довільний об’єм даних (від однієї цифри до вмісту цілого образу DVD), і функція виводить «число» фіксованої довжини. Якщо, як вважається, за двома різними вхідними наборами даних неможливо отримати однаковий результат, функція хешування вважається безпечною.

У поточній версії OpenPGP для ідентифікації ключів використовується функція хешування SHA-1. У SHA-1 є певні вади захисту, але вони не стосуються використання цієї функції у OpenPGP. Значення SHA-1 виглядає десь так:

   7D82 FB9F D25A 2CE4 5241  6C37 BF4B 8EEF 1A57 1DF5

Подібний рядок називається відбитком ключа. Існує два способи переконатися у ідентичності ключа (необроблених даних ключа) без використання послуг сторонніх служб: ви можете отримати сам ключ з безпечного джерела (флеш-картки USB, переданої вам власником ключа) або отримати відбиток ключа з безпечного джерела (що, звичайно ж, набагато простіше, оскільки цей невеличкий рядок з цифр та літер можна надрукувати на шматочку паперу, навіть на вашій візитівці, а потім віддати його відповідній особі).

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

Відкритий ключ OpenPGP («сертифікат») складається з двох частин: самих даних ключа та ідентифікаторів користувача ключа. Ідентифікатор користувача є простим текстовим рядком. Типовий приклад:

   Ім’я Прізвище (коментар) <адреса електронної пошти>

У багатьох ідентифікаторах користувачів немає коментаря, у деяких немає адреси електронної пошти, а для деяких ключів взагалі не вказують (справжнього) імені власника ключа (наприклад, для анонімного використання). Навіть якщо ви певні щодо ідентичності відбитка, ім’я, адреса електронної пошти та коментар можуть бути помилковими.

Адресу електронної пошти можна легко перевірити. Надішліть зашифроване повідомлення на цю адресу і зачекайте на відповідь, яка гарантуватиме, що ваше повідомлення було розшифровано.

Перевірка ідентичності невідомих вам осіб є непростим завданням. На зустрічах з підписування ключів ця процедура виконується за допомогою перевірки паспортів та інших документів, які ідентифікують особу. Але чи здатні ви відрізнити якісну підробку паспорта від справжнього документа?

На щастя, для ваших особистих потреб ідентифікація, зазвичай, не є важливою. «Це той чоловік, якого я бачив на тій зустрічі, він назвався Петром,» — такої ідентифікації достатньо. Отже, це більше питання мережі довіри (див. нижче).

Коментарі також можуть бути важливими: коментар «Директор Компанії inc.» може бути доволі вирішальним (якщо не для вас, то для когось іншого). Питання підтвердження (і сертифікації) ідентифікатора користувача може бути вирішене на основі багатьох факторів.

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

Якщо ви певні у відповідності ідентифікатора користувача певній особі, вам слід сертифікувати ключ. Це означає, що ви створите цифровий підпис до відкритого ключа і ідентифікатора користувача. Ви можете виконати таку сертифікацію лише для себе (так званий «локальний підпис») або для усіх («мережа довіри»). Якщо з ключем пов’язано декілька ідентифікаторів користувачів, ви можете визначити той з них, який ви бажаєте сертифікувати.

Також передбачено загальну оцінку того, наскільки ретельно було перевірено ідентифікатор користувача і ключ. Така оцінка має значний вплив на визначення програмами з підтримкою OpenPGP (а отже і вами!) того, чи слід вважати ключ «чинним».

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

Мережа довіри

У обговореннях ключів OpenPGP часто згадується мережа довіри. Така мережа є непрямим способом пов’язування певних осіб з ключами, потужною, але складною технологією. Початківцям, перш ніж користуватися мережами довіри, варто добре ознайомитися з методиками безпосередньої перевірки і сертифікації ключів. Докладніший опис мережі довіри можна знайти у статті OpenPGP для досвідчених користувачів.


Резюме щодо використання ключа

вам потрібен для того, щоб
відкритий ключ іншої особи зашифрувати дані для неї
перевірити підписи цим ключем (технічну правильність, але не чинність ключа)
ваш закритий підключ розшифровувати дані, які було зашифровано для вас
створювати підписи даних
ваш закритий основний ключ керувати вашим ключем (додавати ідентифікатори користувачів або підключі, змінювати параметри ключа, наприклад строк його дії)
сертифікувати інші ключі (тобто деякі або всі ідентифікатори користувачів цих ключів)
відбиток ключа іншої особи переконатися, що імпортовано належний ключ (перед сертифікацією ключа локально або для інших користувачів)


Інші корисні статті