Gpg ключ что это

What is GPG / PGP

GnuPG (more commonly known as GPG) is an implementation of a standard known as PGP (Pretty Good Privacy). It uses a system of «public» and «private» keys for the encryption and signing of messages or data.

Understanding public vs. private keys

Private keys are the first half of a GPG key which is used to decrypt messages that are encrypted using the public key, as well as signing messages — a technique used to prove that you own the key. As the name implies, this part of the key should never be shared.

Public keys are the second half of a key which is used to encrypt messages for the owner of the private key. As the name implies, this part of the key is safe to give out to the public, as it can only be used to encrypt messages or data for the private key owner.

You can download GnuPG (including graphical versions for those uncomfortable with command line) for various platforms, including Windows and macOS / OSX from the GnuPG Website.

On most Linux distributions, GnuPG is included by default as the command line utility gpg , or is available in your package manager.

For our usage examples, we only cover the command line version of GPG. If you’re using a GUI version, you should be able to find guides online on how to use them.

Looking to buy a Virtual or Dedicated server? Do you like privacy and low prices? Try Privex!

We have virtual servers starting from just US$0.99/mo, and dedicated servers starting from as low as US$50/mo

Unlike other hosts, we don’t ask for any personal details — only a name (can be an alias / username), and an e-mail address so we can send you your server details and renewal invoices.

We also accept several different cryptocurrencies with our own in-house payment processor — no third parties involved in processing your payments.

At the time of writing, we currently accept: Bitcoin (BTC), Litecoin (LTC), Monero (XMR), Dogecoin (DOGE), HIVE, and HBD

Order a server TODAY! Privacy is affordable™

Generating a key pair and exporting the public key

To use GPG to send and receive messages securely, first you must generate a key pair.

NOTE: If you want to be able to add a comment to the key, change the bit size (e.g. RSA 2048 or 4096) or algo, or other extra key options you might wish to adjust, you should use gpg —full-generate-key instead:

After creating a key pair, you’ll want to export the public key to share with others.

In the above example, the public key was exported to john_doe.asc , you should open the file in a text editor such as Notepad, and make sure the first line shows:

This is to make sure you haven’t accidentally exported your private key.

Importing a public key from a key server

Next, you’ll want to import the public key of the person/organization you want to send and encrypted message to.

The below example imports the Privex Support key (key ID 288D D163 2F6E 8951) from a key server.

DISCLAIMER: The Privex Support key is occasionally rotated. For the latest key fingerprint, you should check the Contact Us page

Change the default key server in your config to prevent issues with —recv-keys

A lot of systems are pre-configured to use unreliable / broken GPG key servers, which can cause problems when using —recv-keys . You can resolve most problems with —recv-keys / —search-keys by adding a reliable key server to your GPG config:

Commands to fix keyserver config

Once you’ve added the keyserver setting to your config, you should now be able to use —recv-keys and —search-keys without issues 🙂

Retrieve a key from a specific key server for just one command

You can use the —keyserver flag to manually specify a key server to use, which will only be used for that one command. This can be useful if you can’t find a key on your default keyserver, and need to temporarily try downloading the key from a different keyserver.

Retrieve 288D D163 2F6E 8951 from keys.openpgp.org

Searching for keys on a key server (e.g. by name or email)

If we search for privex.io on keys.openpgp.org — it’ll come back with nothing. This is because keys.openpgp.org does not allow searching by names / domains / comments.

However, if we search for an exact email, it will return results if they’re found:

If we enter the number 1 and hit enter, then it will import the first key that it found

Other keyservers, such as hkps://keyserver.ubuntu.com support searching by name / domain etc. — if we search for privex.io — we can see 4 different keys are available, which you can select and download.

Searching keyserver.ubuntu.com for privex.io:

If we enter the value 1 2 3 4 — it will import the keys 1, 2, 3, and 4:

Encrypting and sending your message

Now, write your message in a plain text editor such as Notepad (Windows) or Textedit (Mac). You may want to put your public key at the end of the message if you want it to be sent encrypted, otherwise you’ll have to send your public key as an attachment or unencrypted text in the message.

Let’s assume you saved your message as message.txt . Now let’s encrypt it for Privex Support.

The above command should’ve encrypted the file message.txt for the public key with the ID 2E833D27B0E01433 (Privex Support), and outputted the encrypted version as message.txt.asc

Now just open up the .asc file, you should see it starts with

Simply copy and paste the contents of this file (including the BEGIN and END lines) into an email or other form of message, and make sure you’ve included your public key in some form — either in the encrypted message, or sent in plain text with the message (e.g. pasted at the end, or attached to an email). Finally, send the message.

Decrypting an encrypted message sent to you

To decrypt a message sent to you, assuming it’s saved as reply.txt.asc , simply run the following command, gpg will automatically select the correct private key to decrypt the message and output it to the terminal.

Decrypt an encrypted message

You can also pipe the encrypted message into GPG. This is very useful for interacting with the clipboard — e.g. the pbpcopy and pbpaste commands on macOS (you can also setup pbpaste/copy on Linux, by installing some extra packages and adding some aliases)

Piping pbpaste into gpg -d (decrypt)

If you want to save the message / data instead of outputting it to the terminal, use shell redirection.

The below example outputs the message to reply.txt :

Trust a GPG key to stop getting asked whether you’re sure you want to use a certain key

By default, GPG will assume imported public keys are unsafe, and will nag you to confirm that you’re absolutely certain you want to sign/verify/decrypt/encrypt something for a certain key. For example, if you try to encrypt a message for Privex Support, you’ll likely see something like this:

To fix this issue, you need to sign the public key which GPG is complaining about, which acts as a statement to GPG «I, john@example.com [ABCD1234] — am 100% certain that key DE12FABC belongs to the person I believe it does.»

Sign the Privex Support key to tell GPG you trust it

Once you run this command, you’ll be shown information about the key you’re signing, and the default key which GPG will use to sign the key:

Now, if we try to encrypt a message for Privex Support — GPG won’t bother us with an «are you SURE this is the right key?» prompt, and just encrypt the message immediately:

Signing and verifying a file / message to show that you approve a message, or verify the authenticity of a file

Clearsign (GPG signature as part of the file/message)

For signing simple text messages, clearsign is usually used, as they’re often intended for humans to read, thus the visible signature won’t cause much of an issue

First let’s create a file message.txt

Now, we’ll sign it with our John Doe key

Sign the file with the john@example.org private key

If we now read the file message.txt.asc — we can see both the original message, and the signature:

Verify a clear-signed message

Verify the message.txt.asc file’s signature

NOTE A user needs the GPG public key for john@example.com to be able to verify the signature, while you require the private key to be able to make a signature.

Output from the command:

Detached Signature (separate signature file)

Detached signatures are very common for signing files where the signature would prevent the file from being able to be read, or where you don’t have the ability to / don’t want to distribute the original file with your signature.

They’re most common for verifying software, to ensure that nobody has tampered with the application other than the actual developer(s) who’ve signed it.

First we’ll remove the previous clearsign signature

Now we’ll use the -b flag to create a detached signature (alternatively you can use —detach-sign for clarity)

If we cat message.txt.asc — we can see this time that it’s JUST the signature, not the original contents. This means the person verifying the signature, needs both the original file, and the signature file (.asc)

Verifying a detached signature

There are two ways to verify a detached signature.

1) Ensure the signature file has the same filename as the file being verified, but ends in either .asc (ASCII Armoured) or .gpg (raw binary)

If the original file has the same name, minus the .asc / .gpg extension, then you can simply pass the signature’s name to gpg, and it will auto-detect the original filename

This would output:

2) Manually specify both the signature filename and the original filename

If the original file has a different name to the signature, OR the signature and file are in different locations, then you should specify both filenames to GPG, placing the signature’s file name after —verify , and then the original filename after that.

This would output:

Looking to buy a Virtual or Dedicated server? Do you like privacy and low prices? Try Privex!

We have virtual servers starting from just US$0.99/mo, and dedicated servers starting from as low as US$50/mo

Unlike other hosts, we don’t ask for any personal details — only a name (can be an alias / username), and an e-mail address so we can send you your server details and renewal invoices.

We also accept several different cryptocurrencies with our own in-house payment processor — no third parties involved in processing your payments.

At the time of writing, we currently accept: Bitcoin (BTC), Litecoin (LTC), Monero (XMR), Dogecoin (DOGE), HIVE, and HBD

GPG. Шифрование в линуксе. Лучшее из Open Source.

Вообще у нас есть совсем небольшое количество программ, которым можно доверять шифровать свои данные.

Так, например, раньше была очень популярна программа для шифрования, которая называлась TrueCrypt. Она имела очень большое количество пользователей и этой программе доверяли.

Но в один момент с ней произошла очень интересная вещь. Эта вещь называется “Свидетельство канарейки”

Свидетельство канарейки

Этот термин произошел совсем недавно, когда шахтеры начали брать с собой канарейку при добыче угля. В шахтах большой риск отравиться угарным газом, а канарейка испытывала действие газа намного раньше человека и умолкала.

Фактически этот термин означает передачу информации через молчание или отрицание.

Согласно “Патриотическому акту”, правительство США может направить секретный ордер интернет-компании на слежку за пользователем. Закон запрещает компании разглашать факт слежки. Но некоторые компании могут отправить вам имейл: “Уважаемый юзер, уведомляем вас о том, что в период с 2008 года по 5 октября 2017 года за вами не велось скрытое наблюдение. С уважением”.

TrueCrypt до 2014 года был очень надежной программой для шифрования, а в 2014 году проект был закрыт из-за давления на разработчиков. Все старые версии удалены, репозиторий очищен. А разработчики настоятельно рекомендовали переходить на программу BitLocker. Все сообщество сразу поняло сообщение разработчиков без лишних слов, так как ранее они высмеивали безопасность BitL ocker, то есть намёк на неискренность собственных слов и попытку сказать нечто важное.

Как и всегда я рекомендую использовать для шифрования только ПО с открытым исходным кодом.

Один из самых классных проектов для шифрования данных это GPG. Про который я и буду рассказывать.

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

Будет так же круто, если кто-то сделает комментарий с таймингами, я его закреплю первым.

Симметричное и асимметричное шифрование

Для начала нужно понимать, что бывает два вида шифрования — Симметричное и асимметричное.

• Симметричное шифрование использует один и тот же ключ и для зашифровывания, и для расшифровывания.
• Асимметричное шифрование использует два разных ключа: один для зашифровывания (который также называется открытым), другой для расшифровывания (называется закрытым).

Эти методы решают определённые задачи и обладают как достоинствами, так и недостатками. Конкретный выбор применяемого метода зависит от целей, с которыми информация подвергается шифрованию.

Симметричное шифрование

В симметричных криптосистемах Алгоритм и ключ выбирается заранее и известен обеим сторонам. Сохранение ключа в секретности является важной задачей для установления и поддержки защищённого канала связи. В связи с этим, возникает проблема начальной передачи ключа (синхронизации ключей).

Симметричные, а конкретнее, алфавитные алгоритмы шифрования были одними из первых алгоритмов. Позднее было изобретено асимметричное шифрование, в котором ключи у собеседников разные.

Самые популярные алгоритмы: AES, Blowfish, Twofish.

Недостатки

Недостатками симметричного шифрования является проблема передачи ключа собеседнику и невозможность установить подлинность или авторство текста. Поэтому, например, в основе технологии цифровой подписи лежат асимметричные схемы. В остальном же алгоритм симметричного шифрования можно считать достаточно проработанным и эффективным, с минимальным количеством недостатков, особенно на фоне асимметричного шифрования

Достоинства:

• скорость
• простота реализации (за счёт более простых операций)
• меньшая требуемая длина ключа для сопоставимой стойкости
• изученность (за счёт большего возраста)

Асимметричное шифрование

Как уже было сказано, достоинство в том, что вы можете свой публичный ключ отдать через незащищенный канал. Так как этим ключом человек сможет только шифровать что-то. Но не сможет расшифровывать.

Криптографические системы с открытым ключом в настоящее время широко применяются в различных сетевых протоколах: TLS, SSL, HTTPS, SSH, PGP.

Первый недостаток асимметричного шифрования заключается в низкой скорости выполнения операций зашифровки и расшифровки, что обусловлено необходимостью обработки ресурсоемких операций. Как следствие, требования к аппаратной составляющей такой системы часто бывают неприемлемы.

Вообще принцип асимметричного шифрования можно очень просто выразить одной фразой: “Можно сгенерировать пару очень больших чисел так, чтобы, зная одно, нельзя было вычислить другое за разумный срок. При этом механизм генерации является общеизвестным.”

Все асимметричные алгоритмы можно описать очень кратко. Должно быть всего одно свойство. Если известно x то f(x) вычислить довольно просто. Если известно y=f(x) , то для вычисления x нет простого пути.

Один из самых популярных алгоритмов является алгоритм RSA

RSA (Алгоритм работы)

Алгоритм работает довольно просто. Мы просто берем два простых числа P и Q .

Умножим их друг на друга и в результате получим N .

Потом выберем случайное число D . Оно должно быть взаимно простым с (P-1)*(Q-1) .

И определим число E , для которого будет истиной (E*D) mod ((P-1)*(Q-1))=1

И у нас открытый ключ это числа E и N , а приватный — числа D и N

Теперь, чтоб нам зашифровать что-нибудь нашим открытым ключом нам надо разбить наш шифруемый текст на блоки, каждый из которых можно представить в виде числа M(I)=0,1,2. N-1

И зашифровать, как последовательность M(I) по формуле C(I)=(M(I)^e)mod N .

А чтобы потом расшифровать это, просто используем секретный ключ , по формуле M(I) = (C(I)^D) mod N

В результате получим исходный текст.

О длине ключа RSA

Алгоритм RSA он один, но мы можем использовать ключ разной длины. Когда ты создаешь RSA пару, то ты указываешь длину ключа в битах. Эта длина определяет количество бит в модуле.

Короче, для того чтобы хранить ваши данные в безопасности в течение двух десятилетий рекомендуется использовать RSA2048.

Два десятилетия это потому, что у нас до сих пор существует закон Мура. Некоторые говорят, что он уже не работает, вроде это говорил директор NVidia. Но не знаю откуда у него такая информация. По информации всех остальных людей в этом мире закон Мура работает и будет работать дальше.

И фактически сейчас взломать RSA2048 невозможно. Но через 20 лет это будет возможно.

Вы можете спросить, а почему не взять просто самый большой из возможных.

И с точки зрения безопасности естественно лучше выбирать тот, который больше. Так как он будет наиболее безопасным. И причем тут зависимость не линейная.

То есть 2048 не в 2 раза безопаснее чем 1024. А во много раз. И так же 4096 во много раз безопаснее чем 2048.

Но при этом сам процесс шифрования и процесс расшифровки он у нас естественно требует нашего с вами процессорного времени. И тут тоже большая разница. Каждое увеличение ключа в два раза увеличивает процессорное время примерно в 6-7 раз. Ну вот условно если ваш процессор будет расшифровывать rsa1024 одну минуту. То rsa2048 он будет расшифровывать 7 минут. А RSA4096 он уже будет расшифровывать 49 минут.

Насколько безопасен каждый из вариантов?

RSA-числа — это множество больших полупростых чисел (чисел, представимых в виде произведения двух простых чисел), используемых в конкурсе RSA Factoring Challenge. Конкурс заключался в нахождении простых множителей предложенных чисел

RSA Laboratories опубликовала 54 полупростых числа длиной от 100 до 617 десятичных знаков. За факторизацию некоторых из них были предложены денежные призы. Наименьшее RSA-число было разложено за несколько дней. Большинство чисел до сих пор не разложены и предполагается, что многие из них останутся неразложенными ещё довольно долгое время.

RSA Challenge официально закончился в 2007 году, но люди до сих пор пытаются раскладывать числа, к марту 2017 года было разложено 19 из 54 чисел. Первые RSA-числа, от RSA-100 до RSA-500, были пронумерованы в соответствии с числом десятичных знаков. Более поздняя нумерация отражает число битов

RSA-230 имеет 230 десятичных знаков (762 бита). Факторизовано 15 августа 2018 в Noblis

RSA-232 имеет 232 десятичных знака (768 бит), и пока что не факторизовано

RSA-768 имеет 768 бит (232 десятичных знака) и было разложено 12 декабря 2009 года Торстеном Клейнжунгом, Казумаро Аоки, Йенсом Франке, Арьеном Ленстрой, Эммануилом Томе, П. Годри, Александром Круппа, Питером Монтгомери, Д. В. Босом, Д. А. Освиком, Г. Рилем, Андреем Тимофеевым и Полем Циммерманном.

RSA-1024 имеет 1024 бита (309 десятичных знаков), и пока что не факторизовано. За факторизацию был объявлен денежный приз в 100000 долларов США.

Успешная факторизация RSA-1024 имеет важное значение для многих пользователей алгоритма RSA аутентификации с открытым ключом, т.к. наиболее часто используемая длина ключа — 1024 бита.

RSA-2048 имеет 2048 битов (617 десятичных знаков). Это наибольшее из RSA-чисел и за него положен приз в 200000 долларов США.

Наибольшее факторизованное RSA-число имеет длину 768 бит (232 десятичных знака) и RSA-2048 может не быть разложено в течение долгих лет, до значительного улучшения вычислительных мощностей и продвижений в факторизации целых чисел.

AHTUNG! Биты!

Важно понимать одну вещь!

RSA Security рекомендует использовать ключи 2048 бит, когда большинство алгоритмов симметричного шифрования используют 112 или 256 бит.

Тут прям принципиальная разница. Для того чтобы взломать RSA нужно найти сомножитель определенной длины. И это такая задача, которую нельзя усложнить очень сильно, иначе для зашифровки и расшифровки у нас будет требоваться очень много времени.

А чтобы взломать симметричный ключ нам надо перебрать 2 в степени N комбинаций, где N — длина ключа. И имея симметричный ключ у нас как шифрование так и расшифровка делается прям мгновенно.

Так что симметричный ключ в 256 бит примерно равен ассиметричному ключу в 15360 бит.

ПРАКТИКА

Ладно, давайте уже перейдем к практике.

Для шифрования мы будем использовать пакет gpg это программа для асимметричного шифрования с открытым кодом, которая очень популярна. С помощью нее вы можете шифровать данные, подписывать свои файлы.

Подпись нужна для того чтобы в сети знали, что это вы. Программисты, например, часто используют gpg для того чтобы подписывать им свои программы. Просто чтобы вы были уверены, что программа именно от программиста, а не кто-то внедрил в программу вирус и подменил файл.

Или, например, создатель биткоина писал сообщения сообществу и подписывал их своим ключом.

Мы все знаем что его ключ

И если мы видим такую подпись, то мы скорее будем доверять ей. Чем какому-то сообщению без подписи.

Так же с помощью gpg мы можем авторизоваться на SSH серверах.

Короче говоря, очень крутая программа, которой пользуются просто все. Вы если про нее не знаете, то рекомендую узнать о ней побольше.

Как я уже сказал, она может шифровать, подписывать и авторизовывать.

Давайте же начнем ее использовать.

Для начала установим пакет gpg

Проверим, что версия актуальная.

У меня, например версия 2.2.13.

Давайте проверим так же, что у нас нет ключей. Я свои удалил, чтобы показать вам весь процесс создания ключей с самого начала.

Для того чтобы посмотреть наши публичные ключи есть команда

gpg —list-keys —keyid-format LONG (Мы так же можем использовать эту команду если нам нужно видеть ключи)

А для того чтобы увидеть приватные ключи есть команда:

gpg —list-secret-keys —keyid-format LONG (Мы так же можем использовать эту команду если нам нужно видеть ключи)

Мы убедились, что у нас нет ключей. Теперь давайте мы их создадим. Делается это командой:

Как я уже говорил, мы можем выбрать любой из вариантов. RSA Lab нам рекомендует 2048 . Лично я выберу 4096 , если ваш компьютер мощный, то я и вам его рекомендую.

Так, теперь мы можем опять выполнить команды gpg -k и gpg -K

И теперь мы видим, что у нас есть наш ключ.

Давайте теперь я кратко расскажу о том, как это читается.

• sec – это primary private часть нашего ключа
• 4096R – это собственно алгоритм и количество бит
• 920B1221 – это айди ключа, ну вернее последняя его часть, на самом деле он немного длиннее.
• 2013-12-01 – дата создания ключа
• [expires: 2014-12-01] – когда истекает ключ

• uid – это что-то вроде идентификатора
• Dmitriy Kovalev – Это имя, которое мы задавали
• 123 – Это наш комментарий
• « – имейл

• ssb – Это наш сабкей в приватной части нашего ключа
• 2048R – его алгоритм
• 2AB141A0 – его айди
• 2013-12-01 – его дата создания

Когда мы создаем наш ключ, то это вообще все сохраняется в директории

Теперь смотрите, мы можем взять какой-нибудь файл и подписать его с помощью команды

Давайте теперь откроем файл и посмотрим на него.

Encrypt

Теперь давайте попробуем зашифровать какой-нибудь файл.

Теперь откроем его.

Видим, что файл зашифрован.

А теперь расшифруем его.

Ну, вот как-то так.

Just a test

Давайте теперь попробуем зашифровать какой-нибудь прям огромный файл.

Давайте, например, возьмем 100 гигабайт.

Теперь зашифруем его

А теперь расшифруем

Результат теста с ключом в 4096 бит следующий

Этот пример я показал вам для того, чтобы вы понимали, что асимметричное шифрование не очень хорошо подходит для того, чтобы шифровать очень большие файлы. Тест мой сделан на ноутбуке Lenovo x1c6. На вашем компьютере время будет другим.

Так же надо понимать, что это время для 4096 . На 2048 все будет в 6-7 раз быстрее. А на 1024 все будет в 40-50 раз быстрее.

Это я вам показал самые основы.

Теперь давайте поговорим подробнее про ключи. Так как это крайне важно.

Ваш ключ может использоваться для защиты ваших важных данных. Я вот рассказывал уже про менеджер паролей pass. Он как раз использует ключ gpg . Так же как я уже сказал вы можете привязать ключи к вашему SSH серверу и заходить на него с их помощью. И если злоумышленник получит ваши ключи, то будет совсем печально, поэтому надо со всей ответственностью подойти к безопасности и о правильном их хранении.

Хорошей практикой считается отдельное хранение основного приватного ключа.

Для этого мы сейчас создадим саб-ключи. А основной ключ сначала забэкапим, потом закачаем его в самое безопасное место и потом удалим из pgp .

А делается это потому, что наш главный ключ умеет создавать саб ключи. И саб ключа нам достаточно для всего.

Главным ключом мы можем создать саб-ключ на небольшой промежуток времени. И чисто теоретически, даже если у вас украдут ноутбук, то ваш ключ не будет скомпрометирован. С помощью основного ключа вы сможете отозвать тот ключ и создать новый.

Добавим subkeys

Делается это командой

После нее мы входим в консоль gpg и далее мы можем там вводить команды. Для того чтобы посмотреть список всех команд мы можем ввести ?

Чтобы добавить новые subkey мы должны ввести

Создать ключ и потом не забываем написать

Бэкапим секретный ключ

Создаем Revocation Certificate

Экспортируем публичный ключ

Очень важно хранить секретный ключ в супернадежном месте.

revocation certificate тоже важно хранить где-либо куда никто кроме вас не имеет доступ.

Удаляем Primary Key

Для начала мы должны экспортировать secret subkeys:

Теперь удалим всю секретную часть нашего ключа:

При этом надо понимать, что у нас останется публичная часть нашего ключа в

Но не будет ничего в

Теперь мы должны будем сделать импорт наших приватных саб-ключей, но без главного ключа:

And we’re left with our “laptop keys”:

Надо понимать, что знак # рядом с sec означает что primary часть секретного ключа отсутствует в нашей связке ключей.

Теперь мы можем записать primary часть секретного ключа, например на Yubikey или другой ключ. Если у нас его нет, то просто копируем на флэшку и прячем ее в самое секретное место в мире.

И теперь мы можем импортировать их на наш другой наш компьютер:

The end

Если эта тема будет интересна, то в следующий раз расскажу о том как авторизовываться на SSH с помощью gpg , как закачать ключ на Yubikey, как шифровать email переписку.

Всё и сразу¶

Короткая выжимка основных операций. Подробности в разделах ниже.

Шифруем файл GPL.txt открытым ключом (моим), результат записывается в GPL.txt.gpg :

Расшифровываем присланный файл и записываем результат в файл GPL.txt :

Создаём цифровую подпись (т.е. подписываем) файл GPL.txt , подпись создаётся в отдельном файле GPL.txt.sig (т.н. detached signature), в аргументе -u [email protected] указываем, какой ключ использовать:

Вместо —detach-sign можно писать -b :

Ещё можно сделать цифровую подпись вместе с самим документом, это делается такой командой:

Полученный на прошлом шаге файл GPL.txt.gpg вместе с подписью содержит и сам документ, его можно извлечь такой командой:

А чтобы просто проверить подпись документа, делаем так (это внешняя подпись, поэтому для корректной проверки рядом должен лежать файл GPL.txt ):

Если сам файл для проверки именуется по-другому, можно просто указать его имя в команде:

Ключи¶

Главный компонент GnuPG — ключ. Он состоит из двух частей: закрытой и открытой. Закрытая хранится только у владельца ключа в тщательно запароленном виде. Открытая распространяется свободно в интернетах.

закрытый ключ используется для:

• подписывания данных;
• дешифрования зашифрованных файлов.

Во всех операциях, где используется закрытый ключ, обязательно нужен вводить пароль к нему (который также называется парольной фразой).

Открытый ключ используется для:

• проверки подписи данных;
• шифрования данных.

Таким образом, если вы хотите кому-то отправить зашифрованный текст, который получатель сможет расшифровать, вы берёте открытый ключ этого пользователя, шифруете этим ключом данные, отправляете. Получатель берёт закрытую компоненту ключа и расшифровывает.

А если вы хотите подтвердить подлинность текста, вы берёте свой закрытый ключ, вычисляете при помощи него и первоначального текста специальный набор байтов, называемый подписью, и отправляете подпись вместе с документом. Получатель берёт ваш открытый ключ, текст и подпись, скармливает это всё специальному алгоритму, который говорит: «да, эта подпись соответствует этому открытому ключу для этого текста». Таким образом получатель может быть уверен, что он получил точно тот же документ, который вы ему отправили.

Пара закрытый-открытый ключ создаётся такой командой:

Детально её описывать не буду, сами разберётесь, в крайнем случае просто Enter жмите, параметры по умолчанию вполне сгодятся.

А теперь важный момент.

Дальше в тексте я буду явно разделять по смыслам слова ключ и криптоключ. Ключ — это такая собирательная сущность GnuPG, объединяющая несколько криптоключей, подписи, идентификаторы юзеров и т.п. А криптоключ — это бинарные данные, непосредственно использующиеся в криптоалгоритмах для операций типа подписывания или шифрования.

Идентификация ключей¶

При работе с gpg нужно указывать, какой именно ключ вы хотите использовать, поскольку в кейринге как правило хранится много ключей. Как минимум это ваш ключ (закрытая и открытая части), плюс открытые ключи других людей.

У каждого ключа есть набор параметров, по которым его можно идентифицировать. Прежде всего, это ID — идентификатор ключа, выглядит он обычно как строка из восьми hex-символов, например, 4600813F . Ещё в качестве идентификатора можно использовать ID юзера из этого ключа. Программа gpg достаточно умная и способна найти ключ, например, лишь по одному емейлу или полному имени, или даже части полного имени.

Поэтому, если у вас в кейринге есть открытый ключ, в юзерах которого есть емейл [email protected] и вы хотите отправить ему зашифрованный текст, можно команду зашифровки файла набрать так:

Здесь в параметре -r [email protected] указывается емейл получателя. Вместо емейла можно указать ID конкретного ключа, или полное имя, или только имя, или фамилию — gpg почти всегда что-то да найдёт, что введённому тексту соответствует.

Если вы хотите подписать файл, это можно сделать так:

Здесь имя передаётся в команде -u john .

Да, да, в одних командах для указания ключа используется команда -u , в других — -r , «Понять это нельзя, можно только запомнить».

Открытый ключ¶

Сразу начнём со списка:

Если у вас свежий кейринг с одним ключом, то после выполнения команды вы получите у себя в терминале нечто подобное. На примере этого листинга объясню базовые вещи о структуре gnupg-ключа.

Команда —list-keys печатает список всех открытых ключей. Каждый открытый ключ состоит из нескольких независимых блоков данных, каждый блок 1 в листинге печатается в отдельной строке (а между разными ключами в выводе —list-keys печатается пустая строка). В одном ключе скрывается сразу несколько криптоключей, которые используются в разных случаях (например, один криптоключ используется для подписывания, а для шифрования — другой). Помимо криптоключей, в блоках ключа хранятся и другие данные (о них будет написано ниже).

Начнём с первого блока:

В первой колонке указывается тип данных в этом блоке, строка pub означает, что в там находится открытая часть мастер-криптоключа, она используется для проверки подписи, сделанной закрытой частью. Это очень важный момент, запомните его: для шифрования данных мастер-криптоключ не используется, только для подписи/проверки подписи.

Во второй колонке указываются параметры криптоключа, в нашем случае 2048R/4600813F означает, что в основе блока лежит криптоключ длиной 2048 бит, буква R после длины ключа означает, что это RSA-ключ (вместо R могут быть и другие символы, например, D для DSA-ключа). Строка 4600813F — это ID криптоключа (в идеале каждый новый ключ должен иметь свой собственный ID, но на практике всё не так радужно — уже есть примеры коллизий).

В третьей колонке указывается дата создания криптоключа, у нас это 2013-03-11 .

В четвёртой колонке указывается дата окончания, в нашем примере она пустая, то есть криптоключ никогда не устаревает.

Деление на колонки весьма условное, но обычно из контекста понятно, где какие данные. Чтобы получить пригодный для автоматического парсинга вывод, добавьте аргумент —with-colons .

Теперь следующий блок:

Тип данных uid означает, что здесь лежит информация о юзере, по сути весь текст тут является ID этого юзера. Юзер служит для привязки бинарных данных ключа к конкретной персоне. В нашем блоке данных user-ID: John Smith (esquire) <[email protected]> .

Тип sub означает, что здесь находится открытая часть подчинённого криптоключа. Остальные параметры такие же, как в мастер-криптоключе: RSA-ключ 2048 бит, ID ключа CA71F43D, дата создания — 2013-03-11. Подчинённый криптоключ используется, для шифрования/дешифрования данных (открытая часть для шифрования, закрытая — для дешифрования).

Закрытый ключ¶

Список закрытых ключей смотрим командой —list-secret-keys

Формат вывода здесь такой же, как и для открытых ключей. Обратите внимание, что ID криптоключей здесь те же самые, то есть криптоключи закрытой и открытой частей образуют связную пару.

Здесь sec означает закрытый мастер-криптоключ, он используется для создания подписи данных.

ssb обозначает блок данных с закрытым подчинённым криптоключом. Этот ключ используется для расшифровывания данных, зашифрованных открытым парным криптоключом из предыдущей секции.

В закрытом ключе дублируются все записи о юзерах.

Вы уже могли обратить внимание, что в качестве ID всего ключа используется ID мастер-криптоключа. Также вспомните, суть мастер-криптоключа — он используется для подписывания данных, но не для шифрования. Эти две вещи связаны напрямую, криптоключ для подписывания не просто так был выбран главным в GnuPG-ключе: все важные блоки данных в открытом ключе подписаны мастер-криптоключом. Это означает, что распространяемый открытый ключ невозможно модифицировать, не сломав подписи блоков. Например, если злоумышленник подменит какой-нибудь емейл (т.е. uid-блок) в открытом ключе, то он не сможет этот подменный блок подписать так, чтобы он прошёл проверку открытой частью мастер-криптоключа.

Распространение открытого ключа¶

Базовые моменты¶

Принцип функционирования GnuPG описан много где, поэтому без подробностей: храните зашифрованный уникальной парольной фразой закрытый ключ в надёжном месте, раздавайте свой открытый ключ на все доступные сервера открытых ключей (и не забывайте после обновления ключа опять его загружать на сервер).

Некоторые сервера ключей являются на самом деле пулами, то есть при обращении к адресу сервера, обратно отдаётся ip-адрес случайного сервера из списка. Пример такого пула — hkp://pool.sks-keyservers.net. Клиент обращается к серверу либо за новым ключом (нужно знать его ID), либо за обновлением уже существующего.

Вот как можно запросить открытый ключ (в данном примере мой ключ):

А вот так можно отправить свой открытый ключ на сервер (это я обновляю свой ключ, поэтому указываю его ID):

Обновить локальные открытые ключи в кейринге можно командой —refresh-keys , она для каждого ID ключа попытается скачать более новую его версию и обновить записи в кейринге:

Практически все серверы ключей не позволяют удалять блоки данных из ключа. Объяснение этому простое — подписываются только отдельные блоки в ключе, поэтому если удалить блок вместе с его подписью, мы получим валидный (но изменённый злоумышленником) ключ. Поэтому, даже если вы удалите из открытого ключа, например, user-ID-блок, вы не сможете этот блок удалить с сервера ключей. Неким аналогом удаления блоков является так называемый отзыв, специальный вид цифровой подписи, помечающий блок как более невалидный. Программы обычно такие блоки либо игнорируют как несуществующие, либо выдают специальные предупреждения, если на невалидные блоки завязаны какие-либо действия.

Таким образом, очень внимательно подходите к вопросу выбора имени или добавления подчинённого криптоключа, после публикации открытого ключа «откатить» изменения полностью уже не получится.

Распространение изменений¶

Два стандартных способа распространения открытого ключа: через дамп с последующим выкладыванием куда-нибудь или через сервер ключей. Про экспорт на сервер я писал выше (команда —send-keys ). А файловый дамп делается так:

Если не указывать —armor , то ключ будет выдан в бинарном формате. Дальше этот файл (4600813F.pub) можно, например, на сайте выложить вместе с такой инструкцией по импорту:

Эта команда сама скачает и затем импортирует ключ в кейринг.

При любом импорте существует несколько сценариев применения изменений, «тонкая настройка» этого делается через команду —import-options , впрочем, действия по умолчанию вполне нормальны и особой необходимости влезать в этот процесс нет.

Редактирование ключа¶

Базовые моменты¶

Редактирование ключа происходит в полуинтерактивном режиме, который запускается командой —edit-key :

Также можно вместо ID ключа использовать имя юзера, вот эквивалентная команда:

Посмотреть список всех 2 доступных команд можно командой help . В процессе выполнения команд данные в ключ сразу не записываются, получается такая типа транзакционность. Записать изменения (и сразу же выйти) можно командой save . Выйти без сохранения можно либо через Ctrl+C , либо командой quit с двумя подтверждениями.

Чаще всего при редактировании ключа по-настоящему меняется только открытая часть: редактируется блок данных (либо добавляется новый) и для него создаётся новая подпись.

Редактирование юзеров¶

Наиболее часто используется команда adduid , она добавляет в ключ новый блок с user-ID: привязать к ключу новый емейл, например; сама команда крайне простая: вводим данные юзера, вводим парольную фразу ключа и всё.

Ввод парольной фразы нужен для создания подписи для добавленного юзера, подпись подтверждает, что юзер добавлен именно владельцем этого ключа.

Чтобы удалить user-ID, нужно в режиме редактирование снача авыделить его командой uid N , где N — номер user-ID из списка юзеров, на листинге выше номера указаны в круглых скобках перед непосредственно ID. После выделения командой deluid выделенных юзеров можно удалить. Да, выбрать можно сразу несколько юзеров, выбранные в списке отмечаются звёздочкой:

Первичный (по-английски — primary) обозначается точкой после номера юзера, в листинге выше это (1). Сменить первичного юзера можно так: выделить его (через uid 2 , например) и далее команду primary :

Первичный юзер используется как юзер по умолчанию при разруливании всяких сложностей (коллизий, например) или при отображении параметров найденного ключа (при вводе парольной фразы, например), если у вас в ключе несколько юзеров.

Командой deluid можно удалить выделенные блоки с user-ID, однако смысл в этой команде есть, только если вы ещё не успели поделиться обновлённым открытым ключом с другими.

Командой revuid можно отозвать выделенные user-ID, отозванные юзеры помечаются специальным образом и во многих случаях это почти то же самое, что удалённый. Необходимость в отзыве возникает, например, если вы потеряли один из емейлов и хотите пометить его в списке, чтобы его другие не использовали.

Редактирование подчинённых криптоключей¶

Блоки криптоключей можно удалять, добавлять и отзывать. Криптоключи бывают двух видов: для подписывания и для шифрования. Создаются они всегда парой: закрытый уходит в закрытый ключ, а открытый криптоключ — в открытый.

Посмотреть, какие у вас криптоключи можно, к сожалению, только из режима редактирования (команда —list-keys не показывает, какого типа криптоключ находится в блоке). Вот пример вывода команды list режима редактирования:

В списке видно два подчинённых криптоключа, ID первого CA71F43D, а второго — DAD9C2B3. В конце строки можно видеть, как этот криптоключ можно использовать: usage: S означает signing, то есть этим криптоключом можно подписывать сообщения, а usage: E означает encryption, то есть криптоключом можно шифровать данные. Запись usage: SC означает, что ключ можно использовать для подписывания (Signing), сертификации (Certification, потом расскажу, что это такое). Есть ещё также буква A , которая означает authentication, но на практике это почти не используется (чуть подробнее здесь можно прочитать).

Любой подчинённый криптоключ можно удалить или отозвать.

После создания новый криптоключ можно использовать для шифрования или подписывания вместо изначального. Так написано в официальной документации, однако как именно это делать, там упомянуто очень мутно. Хотя в действительности всё просто, пусть у нас вот такой набор криптоключей:

• мастер-криптоключ с ID 4600813F — этим криптоключом можно создавать подписи (буква S );
• RSA-криптоключ с ID CA71F43D — для шифрования (буква E ), этот криптоключ был создан ;
• DSA-криптоключ с ID 261AB303 — для подписи (буква S ), этот криптоключ был создан командой addkey ;
• RSA-криптоключ с ID 261AB303 — опять для шифрования, этот ключ также был отдельно создан командой addkey .

Допустим, какой-то человек получил этот открытый ключ и хочет зашифровать им файл GPL.txt , для этого он использует вот такую команду:

Каким именно криптоключом будет зашифрован файл? У нас в ключе их два: один с ID CA71F43D и второй с ID 261AB303. Какой из них использовался? Ответа на этот вопрос нет, хрен его знает, как GPG выбирает, каким именно подчинённым криптоключом шифровать данные, алгоритм выбора нигде в документации не описан (поправьте, если я не прав). В данной ситуации использовался криптоключ с ID 261AB303, видимо, при прочих равных GnuPG выбирает последний созданный ключ (плюс, возможно, с более дальней датой окончания).

Однако можно указать gpg, какой конкретно криптоключ использовать для шифрования (обратите внимание на восклицательный знак после ID подчинённого криптоключа):

Восклицательный знак после ID криптоключа заставляет gpg использовать именно этот криптоключ и запрещает обычную процедуру его поиска. Точно такой же метод можно использовать для подписывания данных. Посмотрите на разницу между вот этими двумя командами, отличающимися только лишь одним восклицательным знаком:

В обоих случаях в качестве юзера передан ID мастер-криптоключа, однако в первом случае gpg вместо него использует подчинённый криптоключ (с ID D306C7D0). А вот если указать восклицательный знак, то будет использован в точности указанный криптоключ, в данном случае — мастер-криптоключ.

С подписыванием ровно то же самое: непонятно как выбирается ключ для подписи, явно ключ можно указать, добавляя восклицательный знак после ID криптоключа.

Подписывание чужого ключа¶

Одной из главных декларируемых фич PGP является сеть доверия (web of trust), что это такое, можете почитать в википедии (только на английском). В основе сети доверия лежит подписывание ключей, суть его в следующем: если вы доверяете человеку, у вас есть его открытый ключ и вы абсолютно точно уверены, что это именно его открытый ключ, то вы можете подписать его открытый своим закрытым ключом. Такой процедурой вы подтверждаете, что этот ключ действительно принадлежит его владельцу. Чем больше таких авторитетных подписей, тем достовернее и надёжнее ключ (что бы это ни значило, но таков ритуал).

Для просмотра подписей блоков данных ключа есть команда —list-sigs , она работает как команда —list-keys , только для каждого блока показывает его сигнатуру:

Структура листинги аналогична команде —list-keys , только теперь мы видим дополнительные строки — они начинаются со слова sig — это подписи (иногда ещё говорят сигнатуры) для соответствующих блоков. Подписи могут быть у подчинённых криптоключей, у юзеров. Сразу после создания ключевой пары, у каждого блока в ключе есть только одна подпись, она создана мастер-криптоключом (напомню, что это сделано для того, чтобы можно было безопасно таскать кучку блоков вместе, а целостность — что никто не подменил блок — как раз обеспечивается подписью мастер-криптоключа).

Структуру строк-подписей рассмотрим на примере этой:

После слова-маркера sig идёт набор флагов подписи, затем ID криптоключа, которым сделана подпись, далее дата создания подписи, а в конце ID юзера (тут как раз и показывается первичный uid, о котором шла речь чуть выше). Если для данного ID криптоключа в кейринге нет открытого ключа, то вместо строки с информацией о юзере показывается нечто вроде [User ID not found] .

Теперь о флагах, для каждого типа флага отведена одна позиция в списке флагов.

Что вся эта муть означает, я писать даже и не хочу. Самые важные поля: [1], [6] и [7]. Если установлен флаг [4] (буква P ), то значит в подписи есть URL, по которому самые задроты кладут файлик с описанием их морального кодекса подписывания ключей 3 .

Флаг уровень проверки может содержать 0, 1, 2 или 3, по умолчанию стоит 0. Каждый уровень означает следующее:

0 — нет никакого особого уровня проверки, это значение по умолчанию, вы не думая подписали этот ключ.

1 — это означает, что вы считаете, что ключ принадлежит указанной персоне, но никак это не проверяли.

2 — это означает, что вы предприняли самые минимальные усилия, чтобы удостовериться, что ключ принадлежит указанной персоне.

3 — это означает, что вы прям совсем точно знаете, что ключ принадлежит кому надо.

Для своих собственных юзеров ключа, как вы можете видеть из листинга выше, стоит уровень проверки 3, что в принципе логично. Если вы просто создаёте подпись без указания конкретного уровня, то подразумевается уровень 0.

Вот как можно подписать ключ с уровнем проверки 1 (привожу полный вывод команды):

Здесь я подписываю свой собственный открытый ключ тестовым ключом, созданным специально для этой статьи. После ввода парольной фразы можно посмотреть, как выглядит набор сигнатур после подписи (напомню, команда —list-sigs ):

Как видите, к каждому блоку (кроме отозванных) добавлена подпись, созданная ключом с ID 4600813F и уровнем проверки 1.

Полезное дополнительное чтиво¶

Вообще, команда —list-keys печатает не все блоки для каждого ключа, например, она не выводит подписи, но для общего понимания структуры ключа это не особо важно. ↩

На самом деле не всех, часть доступных команд в этом списке отсутствует, видимо, они считаются слишком продвинутыми. Пример такой команды — cross-certify , про неё можно тут почитать. ↩

Посмотреть список этих урлов можно командой gpg —list-sigs —list-options show-policy-urls  ↩

Комментарии

Спасибо, отличная статья. Может подскажете, как одной командой получить отметку primary uid ключа/ключей? Т.к. количество этих самых uid может быть больше одного и, по моим наблюдениям, primary uid не всегда выводится первым. Явно такой uid отмечается только в режиме редактирования ключа. Особенно интересно в контексте опции —with-colons

Хороший вопрос! В параметрах —list-keys я не нашёл такого, при использовании —with-colons вроде бы primary uid помечается большими буквами в 12 поле:

1. Field: Key capabilities: e = encrypt s = sign c = certify a = authentication A key may have any combination of them in any order. In addition to these letters, the primary key has uppercase versions of the letters to denote the usable capabilities of the entire key, and a potential letter ‘D’ to indicate a disabled key.

the primary key has uppercase versions of the letters

Тут речь про ключ, как я понял. А меня интересует uid, у которого я насчитал всего 11 полей. А еще в документации для первого поля упоминается такое:

Работаем с цифровыми подписями GPG

Существует огромное количество статей и даже книг по работе с GnuPG, однако одну из самых полезных важных функций — работу с цифровыми подписями — в них обычно опускают. Устраним этот недостаток.

Введение

В данном HOWTO мы подробно рассмотрим как работать с GnuPG второй версии из терминала, а также графический интерфейс на примере утилиты Kleopatra, входящей в состав графической среды KDE, а также набор GnuPG for Windows.

Создание новой ключевой пары

Начнём мы конечно же с создания ключевой пары: связки из открытого и закрытого ключа, которые будут использоваться нами для для подписи и их проверки. Открытую часть вы должны распространять любыми возможными способами, а закрытую хранить в надёжном месте.

Консоль

Утилита gpg2 потребует указать полное имя, адрес электронной почты и затем пароль для защиты секретного ключа. Все остальные параметры будут заданы по умолчанию, включая его длину (по умолчанию 2048 бит).

В данном режиме уже можно настроить любые параметры: тип ключа (рекомендуется RSA/RSA), его длину (рекомендуется увеличить до 4096 бит), срок действия (по окончании срока действия ключ станет непригодным для шифрования и создания новых подписей, но может использоваться для расшифровки и проверки уже существующих цифровых подписей), полное имя, адрес электронной почты, описание и пароль.

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

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

Главное окно Kleopatra

Сначала запустим данную утилиту штатным для используемой операционной системы способом и увидим её главное окно, где отображаются все созданные или импортированные ключи. Полужирным шрифтом обозначаются те, для которых у нас есть закрытая часть, т.е. наши ключи.

Варианты создания ключевой пары

Для того, чтобы создать новую ключевую пару, в меню Файл (File) выберем пункт Новая ключевая пара (New key pair), а затем Создать личную пару ключей OpenPGP (Create new OpenPGP key pair).

Диалог создания ключевой пары

Далее в появившейся форме мастера создания ключей укажем наше имя и адрес электронной почты.

Дополнительные параметры ключевой пары

Нажатие кнопки Дополнительные параметры позволит задать различные необязательные настройки создания ключевой пары: тип, длину ключа, а также срок действия.

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

После указания всех необходимых данных и, опционально, параметров, жмём кнопку Далее (Next). Мастер ещё раз предложит убедиться, что всё указано верно и затем нажать кнопку Создать (Create).

Успешное завершение создания ключевой пары

Через несколько секунд начнётся процесс сбора энтропии для создания секретного ключа и будет предложено ввести пароль для его защиты, а по окончании будет доложено о результате, а также выведен на экран отпечаток созданной пары. Нажмём Завершить (Finish) для выхода.

Экспорт открытого ключа

Для того, чтобы нам могли шифровать файлы/сообщения, а также проверять наши подписи, мы должны экспортировать свой открытый ключ в файл, либо на ключевой сервер.

Консоль

Экспорт открытого ключа в текстовый файл:

Экспорт открытого ключа на сервер ключей:

Здесь 0xD45AB90A — отпечаток ключа нашей ключевой пары, открытый ключ которой мы экспортируем, а mykey.asc — имя файла, в который будет сохранён результат.

В главном окне Kleopatra выбираем нашу ключевую пару, нажимаем по ней правой кнопкой мыши и в контекстном меню выбираем пункт Экспортировать на сервер (Export on Server).

Если требуется экспортировать в файл, тогда в контекстном меню выбираем пункт Экспортировать (Export) и сохраняем файл.

Создание цифровой подписи файла

GnuPG позволяет использовать несколько типов подписей:

• встроенная в файл: содержимое файла изменяется так, чтобы в него была добавлена ЭЦП. Чаще всего применяется при отправке подписанных сообщений по электронной почте;
• отсоединённая в текстовом формате: создаётся файл с расширением *.asc вида mydocument.pdf.asc (где mydocument.pdf — имя оригинального файла);
• отсоединённая в двоичном формате: создаётся файл с расширением *.sig вида mydocument.pdf.sig в бинарном формате.

Для создания ЭЦП файла используется закрытый ключ из нашей ключевой пары, а для проверки — открытый.

Консоль

Создадим отсоединённую подпись в текстовом формате:

Здесь 0xD45AB90A — отпечаток ключа нашей ключевой пары, а mydocument.pdf — имя файла, который мы будем подписывать ЭЦП.

Создадим отсоединённую подпись в двоичном формате:

Все параметры идентичны, но на выходе будет получен файл mydocument.pdf.sig.

Создадим встроенную в файл подпись в текстовом формате:

Создадим встроенную в файл подпись в двоичном формате:

Внимание! При создании встроенных подписей содержимое файла-источника целиком включается внутрь, поэтому использовать данный формат не желательно из-за дублирования и значительного размера. Далее в статье мы будем рассматривать только отсоединённую ЭЦП, т.к. это самый популярный вариант подписи.

Выбор пункта на панели Kleopatra

В главном окне Kleopatra нажмём кнопку на панели инструментов Подписать/Зашифровать (Sign/Encrypt).

Подпись файлов в Kleopatra

В открывшемся окне сначала найдём на диске файл, который следует подписать, выберем его и увидим новое окно с настройками шифрования и подписи.

Выберем свой, который будет использоваться для подписи и, т.к. мы не хотим шифровать его, уберём флажки из всех чекбоксов блока Зашифровать (Encrypt).

Т.к. нам необходимо создать отсоединённую подпись, обязательно установим флажок в чекбокс Зашифровать / Подписать каждый файл отдельно (Encrypt / Sign each file separately).

Запрос ввода пароля закрытого ключа

После нажатия кнопки Подписать (Sign) будет предложено ввести пароль, указанный при создании ключевой пары.

Успешная подпись файла в Kleopatra

Если пароль был введён верно, то процесс завершится успешно и будет создана действительная цифровая подпись. Нажмём Завершить (Finish) для выхода.

Импорт открытого ключа

Для проверки чужой цифровой подписи GnuPG, у нас должны быть:

1. открытый ключ человека, который её создал;
2. оригинальный файл и файл отсоединённой цифровой подписи.

Сначала мы должны импортировать ключ респондента, подписавшего файл (если это не было сделано ранее). Это можно сделать любым способом:

• текстовый файл;
• серверы-хранилища ключей;
• буфер обмена (для GUI утилит).

Консоль

Импортируем открытый ключ с ключевого сервера (наиболее популярный вариант):

Здесь 0xD45AB90A — отпечаток открытого ключа, который мы импортируем.

Импортируем открытый ключ из файла:

Здесь mykey.asc — имя файла с открытым ключом.

Теперь мы должны установить доверие импортированному ключу, т.к. в противном случае не сможем проверить подпись. Войдём в интерактивный режим:

Установим доверие ключу:

Проверим отпечаток респондента (например посредством телефонного звонка или любым другим способом), затем выберем пункт Я полностью доверяю (I trust fully). Выходим из интерактивного режима:

Также мы можем подписать чужой ключ своей подписью после его проверки. Это можно сделать так:

Созданную подпись рекомендуется отправить назад на ключевой сервер:

Здесь 0xD45AB90A — отпечаток открытого ключа респондента.

Поиск ключа на сервере в Kleopatra

Для того, чтобы импортировать открытый ключ с сервера в Kleopatra, мы должны знать либо его отпечаток, либо адрес электронной почты, который был указан при его создании. Введём запрос в поле Искать (Search) и нажмём Поиск (Search). Как только будет найден необходимый, выберем его и нажмём Импорт (Import).

Если требуется загрузить открытый ключ из текстового файла достаточно просто нажать в главном окне Kleopatra кнопку Импорт (Import) и указать данный файл.

Настройка уровня доверия ключу в Kleopatra

Проверим отпечаток импортированного ключа и, если всё верно, установим ему уровень доверия посредством выбора ключа в главном окне и пункта Изменить уровень доверия (Change Certification Trust) в контекстном меню.

Подпись ключей в Kleopatra

Если необходимо, подпишем его (пункт Подписать (Certify)) контекстного меню). Проверим отпечаток ключа (контрольную сумму) и нажмём Далее (Next).

Выбор ключевой пары для подписи Kleopatra

Поставим точку в пункт Сертифицировать для всех (Certify for all) и Отправить заверенный сертификат на сервер (Export signed certificate to server), затем нажмём кнопку Удостоверить (Certify).

Проверка цифровой подписи

Внимание! Файл отсоединённой ЭЦП должен лежать в том же каталоге, что и оригинальный файл, иначе выполнить проверку его подлинности будет невозможно.

Консоль

Проверка отсоединённой подписи файла:

Главное окно Kleopatra, пункт проверки подписей

В главном окне Kleopatra, на панели инструментов, выберем пункт Расшифровать и проверить (Decrypt and verify), затем найдём на диске файл отсоединённой подписи и откроем его.

Результат проверки ЭЦП Kleopatra

Через несколько секунд программа произведёт проверку ЭЦП и выведет результат.