URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 36027
[ Назад ]

Исходное сообщение
"OpenNews: Выход GnuPG 2.0.0. Проблемы безопасности в OpenSSL реализации RSA."

Отправлено opennews , 20-Ноя-06 21:26 
Jean-Pierre Seifert, немецкий специалист в области криптографии, представил (http://eprint.iacr.org/2006/351) новый метод эффективного подбора значений закрытых RSA ключей, используя слабые стороны реализации RSA в OpenSSL.


Также можно отметить выход (http://lists.gnupg.org/pipermail/gnupg-announce/2006q4/00023...) новой версии GnuPG 2.0.0 (http://www.gnupg.org/), отличающийся от GnuPG 1.x.x полностью переработанной архитектурой приложения (код разбит на модули).


Из новшеств GnuPG 2 можно отметить:
-  gpg-agent запускается как фоновое приложение и является центральным звеном по управлению закрытыми ключами и кэшем паролей доступа к содержимому ключей.
-  gpgsm - реализация стандартов X.509 и CMS и протокола S/MIME.
-  scdaemon - демон запускаемый из gpg-agent  для доступа к различным типам смарт-карт.
-  gpg-connect-agent - утилита предоставляющая возможность использования в скриптах сервисов gpg-agent  и scdaemon.
-  gpgconf - утилита для управления конфигурационными файлами из скриптов через представленное API.
-  Поддержка протокола Secure Shell Agent, gpg-agent может выступать в роли замены ssh-agent.


URL: http://it.slashdot.org/article.pl?sid=06/11/18/2030247
Новость: http://www.opennet.me/opennews/art.shtml?num=8909


Содержание

Сообщения в этом обсуждении
"Выход GnuPG 2.0.0. Проблемы безопасности в OpenSSL реализации RSA."
Отправлено mirya , 20-Ноя-06 21:26 
>Jean-Pierre Seifert, немецкий специалист в области криптографии, представил
>новый метод эффективного подбора значений закрытых RSA ключей, используя
>слабые стороны реализации RSA в OpenSSL.

Как я понял, OpenSSL тут не при чем, атака на уровне предсказывания одним процессом поведеня другого на основе остаточных данных процессора после переключения задач ОС - с OpenSSL связанно только тем, что на нем отрабатывают такие уязвимости, а он пытается защищаться, соотв. уязвимость показывает, что это бесполезно. См. http://security.freebsd.org/advisories/FreeBSD-SA-05:09.htt.asc, почему both hyperthreading & Intel (они божились, что уязвимость non-critical) sux