Что: 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 uid [ ultimativ ] Sergey Matveev uid [ ultimativ ] Sergey Matveev 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 и он всё дешифровал и отправил. Дальше я только получил уведомление об успешном обновлении ключа. ------------------------------------------------------------------------ оставить комментарий: mailto:comment@blog.stargrave.org?subject=Re:%20%D0%A1%D0%B4%D0%B5%D0%BB%D0%B0%D0%BB%20%D1%81%D0%B5%D0%B1%D0%B5%20%D0%BD%D0%BE%D0%B2%D1%8B%D0%B9%20PGP%20%D0%BA%D0%BB%D1%8E%D1%87%20%2834b51c3068ae1f6d1beb2d65b678923f4821c6a4%29 ------------------------------------------------------------------------ Сгенерирован: SGBlog 0.34.0