Вот остановился перед выбором и соответственно возникли вопросы:
1) Почему на оффсайте предлагают к загрузке сразу три версии 1.4.х / 2.0.х / 2.1.х ?
В чем основное различие между этими версиями? Искал на оофсайте, так и не нашел чем они отличаются...
2) Какую версию лудше выбрать? Совместимы ли эти версии между собой? Можно ли к примеру на одном компьютере
сразу использовать 1.4.х + 2.0.х + 2.1.х на windows или Linux? Они пишут что нибуть в систему, есть какие траблы ?
Или всетаки выбирать только последнюю 2.1.х ?
3) Вопрос по созданию ключей, собственно ключи совместимы между версиями?
И в обратную сторону
И еще вопрос про опции
--enable-large-rsa
--disable-large-rsa
Они для какой версии предназначены? На какой версии они позволяют генерировать ключ 8192 бит?
> Почему на оффсайте предлагают к загрузке сразу три версии 1.4.х / 2.0.х / 2.1.х? В чем основное различие между этими версиями?
Ветка 1.4 — "классическая", полумонолитная. Подходит для серверов, загрузчиков и в иных подобных средах, где требуется компактность приложения и минимум внешних зависимостей. 2.0 — актуальная модульная стабильная версия программы, больше подходит для десктопов, требует наличия gpg-agent. 2.1 — нестабильная ветка.
> Какую версию лудше выбрать?
Если не имеете чёткого понимания, зачем может понадобиться что-то иное, то 2.0.
> Совместимы ли эти версии между собой?
В плане обмена сообщениями — да. На уровне конфигурации — не полностью.
> Можно ли к примеру на одном компьютере сразу использовать 1.4.х + 2.0.х + 2.1.х на windows или Linux?
Можно, если разведёте их по отдельным директориям опцией --homedir. Только нафиг не нужно, особенно совмещать 2.0 и 2.1.
> Вопрос по созданию ключей, собственно ключи совместимы между версиями?
Да, полностью.
> И еще вопрос про опции ... Они для какой версии предназначены? На какой версии они позволяют генерировать ключ 8192 бит?
Такие ключи ненужны, их не оправдывает ни одна модель угрозы, особенно если Вы при этом задаёте те вопросы, которые задаёте. Исторически, эти опции относились к прежним версиям из ветки 1.4. Некоторое время назад из-за изменений в механизме защиты памяти опции сломались, но недавно их починили и портировали в актуальные ветки. Для их поддержки в любом случае нужно собирать gpg самостоятельно с опцией --enable-large-secmem (по умолчанию отключена), только в этом случае gpg позволит указывать --enable-large-rsa при batch-генерации ключей.
Можно, если разведёте их по отдельным директориям опцией --homedir. Только нафиг не нужно, особенно совмещать 2.0 и 2.1.
Тоесть версии 2.0 и 2.1 конфликтуют между собой?
Для их поддержки в любом случае нужно собирать gpg самостоятельно с опцией --enable-large-secmem (по умолчанию отключена)
Тоесть то что придлагают к загрузке в виде готовых бинарников, эти бинарники не поддерживают создание таких ключей, так?
Тоесть если прет, то надо самому качать сурсняк и его вручную компилировать, так?
2.0 — актуальная модульная стабильная версия программы, больше подходит для десктопов, требует наличия gpg-agent
gpg-agent сразу идет вместе с дистрибутивом? Он уже есть в бинарниках и сурсняках?
В 2.1 добавили ключи ECC, которые не поддерживаются предыдущими версиями. Совместимость нарушена. Подписанные такими ключами сообщения невозможно проверить на 1.4 и 2.0. Кто-нибудь знает, планируется ли добавление поддержки хотя бы паблик ключей ECC в ветку 1.4?
В 2.1 добавили ключи ECC, которые не поддерживаются предыдущими версиями. Совместимость нарушена. Подписанные такими ключами сообщения невозможно проверить на 1.4 и 2.0. Кто-нибудь знает, планируется ли добавление поддержки хотя бы паблик ключей ECC в ветку 1.4?
Это что, значит что если зашифровать открытым ключом сообщение в версии 2.1 то оно не расшифруется в версиях 1.4 – 2.0 ?
А что это за ключи такие ЕСС??? Тоесть ключевая пара сгенерированная в 2.1 уже не импортируется в 1.4 – 2.0 ?
> В 2.1 добавили ключи ECC, которые не поддерживаются предыдущими версиями. <...> Кто-нибудь знает, планируется ли добавление поддержки хотя бы паблик ключей ECC в ветку 1.4?
Существует две ветки GnuPG: 1.4 и 2.x. 2.1 — наиболее свежая версия в ветке 2.x, но находящаяся в настоящее время в бета-стадии. После выхода из неё, версии 2.0.x уйдут в deprecated-стадию, так что портирования туда нового функционала можно не ждать. Касаемо 1.4, Вернер отмечал, что поддерживать обе ветки достаточно долго не в его силах, и, рано или поздно, поддержка 1.4 будет прекращена; портировать туда ECC он не намерен.
В то же время, для особо страждущих есть gnupg-ecc. Только имейте в виду, что это сторонний проект, и его надёжность неизвестна.
> Это что, значит что если зашифровать открытым ключом сообщение в версии 2.1 то оно не расшифруется в версиях 1.4 – 2.0 ? <...> Тоесть ключевая пара сгенерированная в 2.1 уже не импортируется в 1.4 – 2.0 ?
Если не использовать ключ ECC, то всё будет в порядке.
Вопросы по версиям
Вот остановился перед выбором и соответственно возникли вопросы:
1) Почему на оффсайте предлагают к загрузке сразу три версии 1.4.х / 2.0.х / 2.1.х ?
2) Какую версию лудше выбрать? Совместимы ли эти версии между собой? Можно ли к примеру на одном компьютере
Или всетаки выбирать только последнюю 2.1.х ?
3) Вопрос по созданию ключей, собственно ключи совместимы между версиями?
И в обратную сторону
И еще вопрос про опции
--enable-large-rsa
--disable-large-rsa
Они для какой версии предназначены? На какой версии они позволяют генерировать ключ 8192 бит?
PS: намудрил с разметкой, удалите нелеквид...
комментариев: 11558 документов: 1036 редакций: 4118
Ветка 1.4 — "классическая", полумонолитная. Подходит для серверов, загрузчиков и в иных подобных средах, где требуется компактность приложения и минимум внешних зависимостей. 2.0 — актуальная модульная стабильная версия программы, больше подходит для десктопов, требует наличия gpg-agent. 2.1 — нестабильная ветка.
Если не имеете чёткого понимания, зачем может понадобиться что-то иное, то 2.0.
В плане обмена сообщениями — да. На уровне конфигурации — не полностью.
Можно, если разведёте их по отдельным директориям опцией --homedir. Только нафиг не нужно, особенно совмещать 2.0 и 2.1.
Да, полностью.
Такие ключи ненужны, их не оправдывает ни одна модель угрозы, особенно если Вы при этом задаёте те вопросы, которые задаёте. Исторически, эти опции относились к прежним версиям из ветки 1.4. Некоторое время назад из-за изменений в механизме защиты памяти опции сломались, но недавно их починили и портировали в актуальные ветки. Для их поддержки в любом случае нужно собирать gpg самостоятельно с опцией --enable-large-secmem (по умолчанию отключена), только в этом случае gpg позволит указывать --enable-large-rsa при batch-генерации ключей.
Тоесть версии 2.0 и 2.1 конфликтуют между собой?
Тоесть то что придлагают к загрузке в виде готовых бинарников, эти бинарники не поддерживают создание таких ключей, так?
Тоесть если прет, то надо самому качать сурсняк и его вручную компилировать, так?
gpg-agent сразу идет вместе с дистрибутивом? Он уже есть в бинарниках и сурсняках?
комментариев: 11558 документов: 1036 редакций: 4118
Разве я об этом написал? В этом смысла нет, только и всего.
Да, по вышеназванной причине.
Да, это стандартный компонент.
Гость, почитайте про синтаксис, чтобы мне и другим модераторам за Вами посты не подчищать.
Это что, значит что если зашифровать открытым ключом сообщение в версии 2.1 то оно не расшифруется в версиях 1.4 – 2.0 ?
А что это за ключи такие ЕСС??? Тоесть ключевая пара сгенерированная в 2.1 уже не импортируется в 1.4 – 2.0 ?
комментариев: 11558 документов: 1036 редакций: 4118
Существует две ветки GnuPG: 1.4 и 2.x. 2.1 — наиболее свежая версия в ветке 2.x, но находящаяся в настоящее время в бета-стадии. После выхода из неё, версии 2.0.x уйдут в deprecated-стадию, так что портирования туда нового функционала можно не ждать. Касаемо 1.4, Вернер отмечал, что поддерживать обе ветки достаточно долго не в его силах, и, рано или поздно, поддержка 1.4 будет прекращена; портировать туда ECC он не намерен.
В то же время, для особо страждущих есть gnupg-ecc. Только имейте в виду, что это сторонний проект, и его надёжность неизвестна.
Если не использовать ключ ECC, то всё будет в порядке.
Ключи на эллиптических кривых. [1], [2]