Что: 34b51c3068ae1f6d1beb2d65b678923f4821c6a4
Когда: 2022-07-24 11:50:13+03:00
Темы: crypto mail
Сделал себе новый PGP ключ
http://openpgpkey.stargrave.org/.well-known/openpgpkey/stargrave.org/hu/s8kd45yyt8ymu6uttefkjkngyagsui5x.asc
pub ed25519/0xCB8205632107AD8A 2022-07-24 [C]
Schl.-Fingerabdruck = 12AD 3268 9C66 0D42 6967 FD75 CB82 0563 2107 AD8A
uid [ ultimativ ] Sergey Matveev <stargrave@stargrave.org>
uid [ ultimativ ] Sergey Matveev <stargrave@gnupg.net>
uid [ ultimativ ] Sergey Matveev <admin@cypherpunks.ru>
uid [ niemals ] [jpeg image of size 5969]
sub ed25519/0xD2237E8409086CB7 2022-07-24 [S]
sub cv25519/0xAD1D959393A4B1E8 2022-07-24 [E]
Уже давно думаю о том, чтобы начать использовать что-то посовременнее
чем огромные медленные RSA и DSA. Но не хотелось терять красивый ключ с
кучей подписей. Но рано или поздно это всё равно пришлось бы сделать,
так что чего ждать то? Подписан он старым, так что доверие всё равно не
идёт с нуля. И старый я подписал новым.
Однозначно это должен быть на ECC, ибо вопросов с безопасностью к ним до
сих пор не предъявлено, а компактность и скорость крайне приятны.
Разрывался между *448 и *25519, остановившись на последнем. Я не верю
что будет найдена такая атака, что она сможет поставить под угрозу
25519, но не сможет, банально из-за длины, 448. Если будет что-то
угрожающее им, то наверняка сломаны будут одновременно оба. Если всё же
человечество сможет изобрести квантовые компьютеры достаточной мощности
и способностью выполнять алгоритмы для атаки на криптографию, то любой
ECC будет сломан вне зависимости от длины.
Может лучше перебздеть и не экономить на копейках, чай не RSA16k? Всё
усугубляется тем, что *25519 имеет и RFC черновик и реализован и вообще
по умолчанию уже используется в GnuPG. Тогда как для *448 ничего нет,
даже уверенности у Вернера Коха что его детали не поменяются со временем.
Поэтому сделав *448 я почти буду уверен что преобладающее большинство не
сможет его использовать, тогда как с *25519 это уже меньшая проблема.
Также пересмотрел свои предпочтения алгоритмов: сделал AES-256 более
приоритетным чем Twofish. Пускай последний, считается, и имеет немного
более высокий порог безопасности (а Serpent ещё больший), но нет никаких
сомнений в безопасности AES-а. Зато с ним можно получить на порядки
более высокие скорости работы из-за аппаратного ускорения в процессоре.
Убрал все алгоритмы с 192-бит ключом, как и SHA384: если нужна
безопасность, то будет 256-бит ключ, а если скорость, то и 128-бит
хватит за глаза. Плюс убрал все шифры с 64-бит блоком. Не то чтобы я не
доверял их безопасности (хотя надо проверять как GnuPG внутри их
использует и не касается ли его SWEET32), но смысла всё равно в них нет,
ибо даже по скорости выигрыша всё равно не будет.
Обнаружил что WKD для admin@cypherpunks.ru ключа у меня не был рабочим.
Похоже что во время какого-то рефакторинга я полностью потерял
.well-known/openpgpkey директорию.
WKS сервис без проблем отработал на gnupg.net. Причём впервые
использовал ~/.mailcap запись касающуюся WKS:
application/vnd.gnupg.wks; gpg-wks-client -v --read --send;
needsterminal; description=WKS message
Отправил запрос: gpg-wks-client --create --send \
12AD32689C660D426967FD75CB8205632107AD8A stargrave@gnupg.net
Получил ответ. И прямо в Mutt, нажав просмотр MIME вложений, жахнул
Enter на vnd.gnupg.wks и он всё дешифровал и отправил. Дальше я только
получил уведомление об успешном обновлении ключа.
Сгенерирован: SGBlog 0.34.0