История изменений
Исправление user_id_68054, (текущая версия) :
А иметь в ключе несколько сабключей разных типов не несет в себе проблемы
это я понимаю.. да :) ..
но если рассмотреть ситуацию про «по-умолчанию»:
«что будет если вдруг ECDSA and ECDH стенет default, вместо RSA and RSA, в диалоговом окне gpg --gen-key?»
а в этом случае — предполагаю, что RSA-субключи даже не будут генерироваться! (до тех пор пока ты сам вручную их не сгенерируешь через gpg --edit-key ...). верно я предположил? :)
Подписи станут короткими-короткими.
это несомненный плюс!
именно из-за этого, кстати, я несколько лет назад избавился от своего 4096-RSA-ключа , поменяв его на новый (более слабый) 2048-RSA-ключ .. так как слишком длинные подписи — подзадолбали меня (не культурно это!) :)
но опять-же проблемка, следующая:
тот кто подпишет своё сообщение через ECDSA — молодца и почёт ему! однако кто сможет проверить его цифровую подпись? только лишь тот у кого gnupg-утилита имеет свежую внрсию (верно?) — а это значит что gnupg-разработчики врядли пойдут на такой шаг :) .
Некоторые другие PGP-клиенты умеют ECDSA.
начиная с какой версии — gnupg умеет проверять подпись, сделанную через ECDSA? (это я не упрекнуть пытаюсь, а просто сам не знаю.. потому и спрашиваю)
Исправление user_id_68054, :
А иметь в ключе несколько сабключей разных типов не несет в себе проблемы
это я понимаю.. да :) ..
но если рассмотреть ситуацию про «по-умолчанию»:
«что будет если вдруг ECDSA and ECDH стенет default, вместо RSA and RSA, в диалоговом окне gpg --gen-key?»
а в этом случае — предполагаю, что RSA-субключи даже не будут генерироваться! (до тех пор пока ты сам вручную их не сгенерируешь через gpg --edit-key ...). верно я предположил? :)
Подписи станут короткими-короткими.
это несомненный плюс!
именно из-за этого, кстати, я несколько лет назад избавился от своего 4096-RSA-ключа , поменяв его на новый (более слабый) 2048-RSA-ключ .. так как слишком длинные подписи — подзадолбали меня (не культурно это!) :)
но опять-же проблемка, следующая:
тот кто подпишет своё сообщение через ECDSA — молодца и почёт ему! однако кто сможет проверить его цифровую подпись? только лишь тот у кого gnupg-утилита имеет свежую внрсию — а это значит что gnupg-разработчики врядли пойдут на такой шаг :) .
Некоторые другие PGP-клиенты умеют ECDSA.
начиная с какой версии — gnupg умеет проверять подпись, сделанную через ECDSA? (это я не упрекнуть пытаюсь, а просто сам не знаю.. потому и спрашиваю)
Исходная версия user_id_68054, :
А иметь в ключе несколько сабключей разных типов не несет в себе проблемы
это я понимаю.. да :) ..
но если рассмотреть ситуацию про «по-умолчанию»:
«что будет если вдруг ECDSA and ECDH стенет default, вместо RSA and RSA, в диалоговом окне gpg --gen-key?»
а в этом случае — предполагаю, что RSA-субключи даже не будут генерироваться! (до тех пор пока ты сам вручную их не сгенерируешь через gpg --edit-key ...). верно я предположил? :)
Подписи станут короткими-короткими.
это несомненный плюс!
именно из-за этого, кстати, я несколько лет назад избавился от своего 4096-RSA-ключа , поменяв его на новый (более слабый) 2048-RSA-ключ .. так как слишком длинные подписи — подзадолбали меня (не культурно это!) :)
но опять-же проблемка, следующая:
тот кто подпишет своё сообщение через ECDSA — молодца и почёт ему! однако кто сможет проверить его цифровую подпись? только лишь тот у кого gnupg-утилита имеет свежую внрсию — а это значит что gnupg-разработчики врядли пойдут на такой шаг :) .