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

Если не интересуют тонкости работы с подключами, а только с ключами, то в общем виде всё как-то так:

gpg -v --armor --default-key [myUID] --encrypt-to [RecipientUID] --hidden-recipient [HiddenRecipientUID] --encrypt --sign

Коллеги, прислушался несколько лет назад к Вашим советам освоить консоль. Логику понял, мнение свое изменил, на своем дилетантском уровне – освоил. Но блин, я не пойму логику использования консоли в GPG, ну т.е. всякие gpg -c/-e/-s/-d – да, порой так быстрее, особенно дешифровывать присланные файлы. Но вот шифровать (использую плагин seahorse), или вбивать вручную все эти 0xXXXXXXXX получателей – да я же офигею.. из за этого у меня пробел с подключами, хотелось бы наверстать. Вы все используете gpg в консоли? ну т.е. прям мне просто взять и принудительно перейти на консоль полностью и потом уже сноровка придет?
UPD: Движок ошибку выдает: "openSpace DBAL error: SQL query failed.", несколько раз подряд.

Господа, так какой алгоритм действий? Такой, примерно:
gpg --list-keys $ gpg --list-keys /home/.gnupg/pubring.gpg ------------------------------ pub 1024D/8BFC65C2 2012-12-11 uid Name (Comment) <user@gmail.com> sub 8192g/CBE7291A 2012-12-11 gpg -e /file.tar CBE7291A
И так действительно в разы быстрее?

Проверил – буду знать, очень удобно, но ты прав – если буквы сходятся – он мне два раза не того адресата подсунул, т.ч. надежнее все-таки по UID.

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

unknown, а прокомментируй пожалуйста вот это: 1 | awk {'print $2'} | awk -F \/ {'print $2'}`
Хотя если не сложно – то с grep'a, а то я не вьехал – зачем грепать, если уже имя ввел. А дальше и вовсе ничего не понял..
Я правильно понимаю, что один раз выстроил для себя и потом либо алиасы создаешь, либо табаешь, или нужно постоянно печатать подобные строки? Я же не кодер, это мне учить и учить в таком случае, а задача – экономить время и по пути навыки оттачивать.
UPD: А ну понятно, что за AWK^[link1], тогда я точно далек от этого, сколько ни пробовал любой мало-мальски простенький язык выучить – видимо не дано мне это..( Даже здесь ума не приложу, откуда берется эта $2. Это же переменная? Ты ее где-то объявлял что-ли? Нет. Откуда она и что интерпритатору печатать – я не понимаю.. Или это какая-то встроенная в язык переменная,которая выведет вторые поля grep?

Гость, ну это просто алиас, правильно? Я себе алиасы для OpenSSL делал. Кстати, а почему конфиги выкладывать – это не секьюрно? Я бы, к примеру, с радостью посмотрел на чьи-нибудь алиасы, и возможно даже себе бы взял на вооружение. Ну т.е. в чем угрозы в выкладывании конфигов?
Unknown, забавно, я же привык твои сообщения всерьез воспринимать – вот и начал вдумчиво смысл искать, зато узнал, что такое awk.

Спасибо тебе большое. Я же тебя узнал! Вот по большому тексту – сразу узнал. Спасибо, ты очень много полезного выкладываешь и пишешь.
Пожелания из скринов – учту. Да давно учел бы, вопрос времени)
Но теперь однозначно буду больший уклон в сторону CLI делать.
Слушай, на сколько это все-таки сильно – нести знания и так или иначе влиять на людей.
Искренне – всех благ и всего самого наилучшего.
О конфиге – так наоборот – может лучше выкладывать? Ну т.е. меня сломают и за тебя примут)) Ну и таких как я – не мало будет, которые конфиг твой заюзают.

Оффтоп-Стилометрия

1. Слишком частое употребление слов/выражений (вплоть до слов-паразитов): «уже», «ещё», «вот», «и» в роли частицы, «как правило», «наподобие», «во-первых» и «во-вторых», «с другой стороны», «мораль», «как бы», «кроме того», «стоит отметить», «т.к.», «т.е.», «вроде бы», «например», «фактически», «де факто», «на самом деле», «вообще», «кто-нибудь», «так что» вместо «поэтому», «вполне» и др. В тексте из нескольких абзацев с вероятностью, стремящейся к 100%, будут обнаружены все из перечисленных паразитов.
2. Частое начинание предложений с союза «и».
3. Обильное употребление скобок (логические связи становятся такими громоздкими, что их либо трудно выразить без скобок, либо не знаю, как их правильно оформить грамматически).
4. Многие предложения имеют одинотипную структуру (часто используются обороты «если..., то...» и др.).

Оффтоп-UNIX

Оффтоп-GnuPG

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

2 /comment84862^[link14]:

Вспомнил это обсуждение^[link15] и заодно посмеялся над своей профилируемостью ;) Ну и с отсылкой к профилю по нику^[link16], понятно, что эта проблема существует давно и только усугубляется со временем.

Если кратко, то это всё перфекционизм и нерациональное распределение затрат на изучение/внедрение и выигрыша от использования.

Разработчики систем расчитывают на некое большинство, которое будет пользоваться тем, что есть из коробки при минимуме дополнительных опций. Поэтому эти дополнительные опции плохо проработаны и могут откровенно глючить. Это даже в Tor так (без проблем с legacy-кодом, которые пока вообще ещё не накопились). Например, в Tor есть скрытая аутентификация^[link17]. Разрабы смеялись, что иногда они её ломают до полностью нерабочего состояния, так никто месяцами не жалуется ни в тикетах, ни в рассылках. Стоит ли это оперативно исправлять, если этим почти никто не пользуется? Также и с продвинутыми опциями GnuPG. Тонкий выбор подключей, манипуляция с экспортом закрытых ключей и пр. — это продвинутые опции на всякий случай, задел на будущее (которое может и не наступить в предполагаемом виде). Это всё железно работать не обязано. GnuPG гарантирует некую безопасность для тривиального случая с непродвинутыми опциями. Всякие продвинутости — на ваш страх и риск. Попытки нагородить отрицаемость, анонимность, наперёд заданную секретность, хитрые манипуляции с ключами и пр. — на ваше усмотрение.

Если обобщать проблему «избыточной продвинутости» некоторых пользователей, то она возникает там, где:

1. Параноидальный перфекционизм, совершенная параноидальность. Это лучше оставить без комментариев, а то далеко зайдём.
2. Как часть мировоззрения, шифрпанковской, опенсорсной субкультуры.
3. Пользователям интересен предмет как увлечение, из спортивного интереса (чаще для молодых и/или с проблемами нереализованности своего познавательного потенциала).
4. Пользователям интересен предмет, опять таки, как увлечение, но чтобы прокачать мозги, не впасть в маразм (актуально для тех, кто постарше).
5. Даже если знания и навыки напрямую нигде не применить, их можно прямо или косвенно утилизировать в какой-то смежной сфере деятельности (напрямую — в ИТ, умение разбираться в логических связях, алгоритмах, формальностях — много где ещё).
6. В исследовательских и/или промышленных целях. Нет смысла тратить годы на изучение шифрования, если нужно отправить пару шифросообщений за всю жизнь. Но можно решать какую-то задачу, выработать методику, инструкции, скрипты, где автоматизировать и поставить на поток отправку защищённых сообщений для какого-то узкого сценария. Если сообщений — тысячи и миллионы, то затраты на изучение и внедрение себя оправдывают.

Количество пунктов и их ранжирование по степени рациональности — условное.

Я^[link22] попробовал позвонить родителям, но не смог, поскольку с телефоном случилась какая-то странная вещь: ты набираешь номер — и сразу идут гудки, как будто занято. Пробуешь звонить с мобильного — такая же история.

з^[link26]десь ещё не упоминалась замечательная ссылка^[link27] от 2010-2011-го, в которой автор привёл 8 пунктов против использования TC (запрет на упоминание чего-то иного TC-совместимого на официальном форуме поддержки TC веселит; TC-team уже исправлили это в правилах?).

1. Делаем себе скрипт (допустим, ~/bin/script_name.sh; см. ниже).

2. Прописываем его стркой (вместо аналогичной предыдущей):

   backtick 1 10 10 sh -c '$HOME/bin/script_name.sh'

3. Перечитываем конфиг screen:

   $ cd ~/
   $ screen -X source .screenrc

4. Теперь в левом углу терминала будет показываться, кто залогинен, и сколько шеллов под конкретным юзером открыто. Вид отображения:

   user1:количество1 user2:количество2 user3:количество3

   И т.д.

#!/bin/sh
users \
|tr -s ' ' '\n' \
|uniq -c \
|sed 's/^[[:space:]]*//;s/\([[:digit:]]\)*[[:space:]]\([[:alpha:]]*[^[:space:]]\)/\2:\1 /g' \
|tr -s '\n' ' '

в командной строке ровно тот же вызов с sh -c работал, а там — нет, и поди пойми почему

Возможно, не все знают, что в screen можно отвести две строки в терминале под информацию, а не одну. Например, в одной можно отображать информацию о текущих запущенных (или последних завершившихся) процессах в шеллах, а в другой отображать иную информацию о системе. Берём за основу этот пример^[link37], добавляем в ~/.zshrc строчки

# If runing in screen, set the window title to the command about to be executed
preexec() {
    [ -n "$WINDOW" ] && print -Pn \
        "^[k$(echo $2|perl -pne 's!\s.*/! !g' \
        |sed 's/ls\( -[^ ]*\)\+\(.*\)$/ls\2/' \
        |cut -c1-10)^[\\"
}
 
# If in screen, blank the window title when displaying the prompt
premd() {
    [ -n "$WINDOW" ] && print -Pn "^[k ^[\\"
}

backtick 1 10 10 sh -c "users | perl -ane'\$_{\$_}++ for @F; print join q[ ], map qq[\$_:\$_{\$_}], sort keys %_'" caption always '%{=b dd}%=%?%-w%?[%n] %t%?%+w%?%=' hardstatus string '%{=b dd}%1`%=%l%=%S%=%D %M %d %c' hardstatus alwayslastline shelltitle "$ |zsh"

Магия с ls сделана, чтобы не писать всегда использующиеся опции цвета и классификатора (-F --color). Вместо %{=b dd} можно правильно расставить цвета под свою гамму перед каждым элементом. Кстати, %{= X}, где X — буква цвета, тоже работает, хотя из man screen это неочевидно. В последней строке будет отображаться число шеллов под юзерами, загрузка системы (load average из man uptime или из w), имя screen-сессии (если запускать как screen -S screen_name) и дата. В предпоследней строке — последние выполнявшиеся комманды с номерами шеллов, где они были (плюс умное обрезание аргументов).

P.S. ^[ в ~/.zshrc — специальный ESC-символ. Чтобы его ввести, в vim'е в режиме ввода жмём Ctrl+V ESC.

Начинаются глюки при работе с именами файлов, содержащими кириллические символы. То ли дело в том, что screen или шелл, возможно, не поддерживают UTF (или поддерживают его неправильно), то ли в том, что умолчальная кодировка не является UTF'ом.

Например, vi не понимает управляющих команд на кириллице, а в vim для этого приходится использовать langmap. Не знаю, можно ли что-то аналогичное сделать для vi-режима редактирования командной строки в zsh, но по умолчанию этот режим совершенно не понимает кириллицу, что приводит к неудобствам с множеством лишних переключений в латиницу и обратно при работе с кириллическими именами файлов.