Комментарии 19
НЛО прилетело и опубликовало эту надпись здесь
Интересное решение, прочитал с большим удовольствием
Профит от хранения ключа на криптографическом устройстве в полной силе существует тогда, когда он это само устройство не покидает. Обычно он вообще там внутри генерируется. А так, можно просто ключ и в rar файлике шифрованном на флешке хранить, примерно с тем же успехом.
Статья симпатичная :)
Статья симпатичная :)
Вот дела: чтобы защитить ключ, надо сперва его взломать о_О
Я правильно понял:
для создания подписи разными ключами, в отличии от остальных ключей, при использовании ключа WM придется делать лишние не стандартные телодвижения?
для создания подписи разными ключами, в отличии от остальных ключей, при использовании ключа WM придется делать лишние не стандартные телодвижения?
Да весьма симпатично. Оригинальное применение известной атаки Винера весьма доставило. Помнится в универе заставляли реализовывать. В самом деле позволяет с полиномиальной скоростью восстановить секретную экспоненту, только если не ошибаюсь при условии что d<n1/4.
Кстати, как там ваш проект реализации ДСТУ поживает?
Кстати, как там ваш проект реализации ДСТУ поживает?
>>только если не ошибаюсь при условии что d<n1/4.
Если точнее, то d < 1/3 * n ^ (1/4) Если бы можно было d любой длины находить — то смысла в RSA бы не было. Может когда и придумают…
>>Кстати, как там ваш проект реализации ДСТУ поживает?
web.cryptography.org.ua/index.html — там все написано. В общем то, после того как научились генерить ключи и подпись для обоих базисов — дело немножко подвисло. Теперь задача — сделать быструю версию подписи для ОНБ. Надеюсь появится время и займусь. Напишу вам.
Кстати, есть у вас идеи, как (и в каких случаях) можно использовать deviation для ослабления безопасности? У меня парочка есть, но не всегда можно использовать.
Если точнее, то d < 1/3 * n ^ (1/4) Если бы можно было d любой длины находить — то смысла в RSA бы не было. Может когда и придумают…
>>Кстати, как там ваш проект реализации ДСТУ поживает?
web.cryptography.org.ua/index.html — там все написано. В общем то, после того как научились генерить ключи и подпись для обоих базисов — дело немножко подвисло. Теперь задача — сделать быструю версию подписи для ОНБ. Надеюсь появится время и займусь. Напишу вам.
Кстати, есть у вас идеи, как (и в каких случаях) можно использовать deviation для ослабления безопасности? У меня парочка есть, но не всегда можно использовать.
[оффтоп href=«web.cryptography.org.ua/tasks.html» ]
> На данный момент умножение точки кривой на число занимает 7-10 секунд
Как вы этого добились? Даже если взять самый простой (интерфейсом) NTL, в лоб на нём нарисовать умножение справа самым простым способом, даже с перегруженными операторами, всё равно получается около 150 подписей в секунду в GF(P)
[/оффтоп]
> На данный момент умножение точки кривой на число занимает 7-10 секунд
Как вы этого добились? Даже если взять самый простой (интерфейсом) NTL, в лоб на нём нарисовать умножение справа самым простым способом, даже с перегруженными операторами, всё равно получается около 150 подписей в секунду в GF(P)
[/оффтоп]
>>Как вы этого добились?
Добились — хорошее слово. Будете смеяться, но первая реализация вычисляла произведение точки на число 15 минут.
Там умножение в ОНБ. В принципе, оно длительно выполняется. Скорее всего нужно перевести в полиномиальный базис, тогда будет быстрее. В общем, если вы разбираетесь в вопросе — можете посмотреть исходники.
Добились — хорошее слово. Будете смеяться, но первая реализация вычисляла произведение точки на число 15 минут.
Там умножение в ОНБ. В принципе, оно длительно выполняется. Скорее всего нужно перевести в полиномиальный базис, тогда будет быстрее. В общем, если вы разбираетесь в вопросе — можете посмотреть исходники.
А можно более детальное описание структуры kwm привести? Я помню, что у классика kwm-файл может быть разного размера, соответственно интересно было бы почитать как в случае с изменяющимся размером получить D и Modulus.
Закрытый RSA-ключ, который будет помечен как неэкспортируемый и поэтому его нельзя будет извлечь? Если да, то в случае с хранилищем win* все можно извлечь, правда нестандартным, но довольно простым способом.
Теперь модифицированный ключ можно сохранить в хранилище CSP (к примеру, eToken PRO) как закрытый RSA-ключ, а deviation сохранить как PKCS#11 объект
Закрытый RSA-ключ, который будет помечен как неэкспортируемый и поэтому его нельзя будет извлечь? Если да, то в случае с хранилищем win* все можно извлечь, правда нестандартным, но довольно простым способом.
>>А можно более детальное описание структуры kwm привести?
Вот здесь исходный код на C# для расшифровки ключа: wm-api.svn.sourceforge.net/svnroot/wm-api/trunk/WebMoney.Cryptography/DecryptedKey.cs В самом верху файла — константы. Они повторяют структуру файла kwm.
>>Я помню, что у классика kwm-файл может быть разного размера, соответственно интересно было бы почитать как в случае с изменяющимся размером получить D и Modulus
Это раньше было, теперь размер все время одинаковый. Раньше его раздували простейшим алгоритмом «для безопасности». Смысл, возможно, был, когда у всех было подключение 32 Кбод. Сейчас убрали.
>>Закрытый RSA-ключ, который будет помечен как неэкспортируемый и поэтому его нельзя будет извлечь? Если да, то в случае с хранилищем win* все можно извлечь, правда нестандартным, но довольно простым способом.
С win-хранилища можно (если на ключ не установлен пароль). А вот с eToken — такой возможности нет в принципе — только вместе с устройством.
Вот здесь исходный код на C# для расшифровки ключа: wm-api.svn.sourceforge.net/svnroot/wm-api/trunk/WebMoney.Cryptography/DecryptedKey.cs В самом верху файла — константы. Они повторяют структуру файла kwm.
>>Я помню, что у классика kwm-файл может быть разного размера, соответственно интересно было бы почитать как в случае с изменяющимся размером получить D и Modulus
Это раньше было, теперь размер все время одинаковый. Раньше его раздували простейшим алгоритмом «для безопасности». Смысл, возможно, был, когда у всех было подключение 32 Кбод. Сейчас убрали.
>>Закрытый RSA-ключ, который будет помечен как неэкспортируемый и поэтому его нельзя будет извлечь? Если да, то в случае с хранилищем win* все можно извлечь, правда нестандартным, но довольно простым способом.
С win-хранилища можно (если на ключ не установлен пароль). А вот с eToken — такой возможности нет в принципе — только вместе с устройством.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Криптографическая головоломка: импорт ключа WebMoney в Crypto Service Provider