Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Шифрование алгоритмом RSA [D7, WinXP]

Страницы: 1 2 3 >
cr@nk © (2011-01-15 23:30:00)
Задается исходная строка и надо зашифровать её по алгоритму RSA
Для работы с большими числами скачал библиотеку FGInt ( http://www.submanifold.be/triade/GInt/gint.html RSA.zip) . В архиве прилагается пример шифрования строки.
Подгоняю данные в их исходнике под пример из http://ru.wikipedia.org/wiki/RSA#.D0.9F.D1.80.D0.B8.D0.BC.D0.B5.D1.80(просто фиксировано задаю переменные E, D, N)
program Project1; {$APPTYPE CONSOLE} uses SysUtils, FGInt, FGIntPrimeGeneration, FGIntRSA; Var n, e, d : TFGInt; test : String; Begin Base10StringToFGInt('3', e); Base10StringToFGInt('9173503', n); Base10StringToFGInt('6111579', d); RSAEncrypt('111111', e, n, test); writeln(test); readln; End.
Получаю UА_n‹@k‘вместо 4051753

Также нашёл в сети пару программ ( http://dl.dropbox.com/u/4653598/RSA_sample.rar), демонстрирующих работу с RSA. В них видимо идентичный код, т.к. на выходе получаются идентичные данные
При значениях E= 7, N=697, D=183 и входной строке 111111получаю 535 535 535 535 535 535
Если эти же значения использовать с модулями от FGInt, то получаем на выходе получаем \x2\x15Ц §1–c.
Есть догадка, что в модуле от FGInt присутствует какая-то "добавка", которая в корне меняет конечный результат. Но также в тех 2-х программах очень не нравится выходная строка - одинаковые тройки чисел.

Что-то так много всего написал, что не знаю, как правильно сформулировать вопрос :)
Наверное хотелось бы увидеть нормальный модуль или пример, где реализован чистый алгоритм RSA, позволяющий шифровать отдельно текст, а не сами файлы на жёстком диске.
Второй день бьюсь над решением этой задачи

P.S.: При использовании модулей FGInt в Delphi 2010, XE возникает ошибка, если вызывать одну из функций (замечал это на функции Base256StringToFGInt). Эту информацию привожу для справки... вдруг она тоже окажется полезной

cr@nk (2011-03-12 19:10:00) [1]
Ух, попробую описать свою проблему.
1. Генерируется 2 ключевых файла: открытый и закрытый ключи (Файл - сгененрировать новую пару)
2. Генерируется ещё одна пара ключей (первая пара ключей - отправитель, вторая - получателя)
3. В настройках указываем путь к Вашему секртеному ключику и к его публичному
4. Далее программа шифрует сообщение текст публичным ключем ПОЛУЧАТЕЛЯ и подписывает ВАШИМ секретным
5. Для "нормального" отображения зашифрованного сообщения переводим его в HEX (чтобы избежать проблемы с неотображаемыми символами и т.п.)
6. Половина дела сделана - текст зашифрован. Надо бы произвести обратную операцию. Снова заходим в настройки и меняем пути до ключей
7. Пытаемся расшифровать. Для этого считываем HEX-строку, переводим её в String и полученную строку передаём в процедуру RSADecrypt, но на выходе почему-то получается ерунда

Надеюсь, что найдётся человек, который сможет подсказать по всему этому ужасу :)

http://rghost.ru/4739526

Ega23 (2011-01-31 01:11:00) [2]

> Если вышеизложенный алгоритм верен,

Не верен. RSA - генерируются 2 ключа. Не важно, что есть секретный, что - публичный. Сообщение, зашифрованное ключом 1 может быть расшифровано ключом 2. Сообщение, зашифрованное ключом 2, может быть расшифровано ключом 1.
Всё.

Anatoly Podgoretsky (2011-01-29 13:17:00) [3]
Достаточно одного из двух

cr@nk (2011-01-29 05:22:00) [4]
Писал ночью... накосячил немного :)
- Текст сначала шифруется, а потом подписывается
- И конечно же подпись проверяется моим бубличным ключиком

cr@nk (2011-01-28 22:47:00) [5]
На данный момент не могу понять логику работы программы (точнее даже алгоритма RSA)
Программой генерирую два файла ключа. Секретный ключ оставляю себе, публичный отправляю получателю.
Верно ли, что мой собеседник ОБЯЗАН проделать тоже самое? Или же он должен на основе публичного ключа сгенерировать свой секретный? (мне кажется, что это не верно, но надо бы уточнить)
Т.е. для обмена шифрованными сообщениями:
1. я подписываю исходный незашифрованный текст своим секретным ключом
2. беру ЕГО публичный ключ, шифрую этим ключиком своё сообщение (не уверен в последовательности подписать-зашифровать).
Получатель:
1. Расшифровывает текст СВОИ секретным ключиком
2. Проверяет подпись моим секретным ключом.

Итого: для двустороннего обмена сообщениями всего должно использоваться 4 ключевых файла?

Если вышеизложенный алгоритм верен, то у меня будет вопрос непосредственно по подписыванию текста функциями от FGInt

Ega23 (2011-01-27 00:44:00) [6]

> RSAEncrypt и Decrypt самостоятельно разбивают текст на
> куски с длинной меньше длинны n.

Об том и речь.

CrytoGen (2011-01-26 22:03:00) [7]
Да извиняюсь. Был неправ. Проблема RichEdit. RSAEncrypt и Decrypt самостоятельно разбивают текст на куски с длинной меньше длинны n.

cr@nk (2011-01-26 21:43:00) [8]
Извините, что вмешиваюсь в спор, но в данном случае (как мне кажется) проблема всё же в том, что RichEdit "удлиняет" зашифрованный текст.

Я, конечно, это всё еще перепроверю и позже отпишусь о результатах

Inovet (2011-01-26 20:23:00) [9]
> [19] cr@nk © (26.01.11 06:23)
> Зашифрованный текст:

После него ДМКлиент эту ветку глючно отображает. Версия 3.0.0.7.

Ega23 (2011-01-26 19:16:00) [10]

> Ругаться не хочеться, потому отвечать не буду.

Ну-ну.
З.Ы. Интересно, и как же я раньше использовал RSADecrypt из FGInt?

CrytoGen (2011-01-26 17:32:00) [11]
Ругаться не хочеться, потому отвечать не буду.

Ega23 (2011-01-26 17:28:00) [12]

> Я знаю что зашифровать можно.

"Как тебя понимать, Саид?" (с)

> CrytoGen (26.01.11 16:18) [24]
>
> У вас проблемы не с memo. У вас проблемы с длинной ключа
> - ключ должен быть длиннее шифруемого текста.

CrytoGen (2011-01-26 17:15:00) [13]
Предположим было несколько ранее написано. Так часто пишут, вы книжки почитайте.
Я знаю что зашифровать можно. Но только RSA здесь уже не причОм. RSA шифрует блоками. Если разбить сообщение на блоки, то можно зашифровать и маленьким ключом. Однако аффтар пытается зашифровать блок длинной 280 бит, используя значение n длинной 20 бит.

Ega23 (2011-01-26 17:08:00) [14]

> Предположим, сторона хочет послать стороне сообщение .
> Сообщением являются целые числа лежащие от 0 до n-1.

Ключевое слово - предположим
Ты действительно считаешь, что нельзя зашифровать 10 Кб данных 256-битным RSA-ключом? И обратно расшифровать?

CrytoGen (2011-01-26 16:59:00) [15]
Шарик ты балбес! Знаю я как вы используете...
http://ru.wikipedia.org/wiki/RSA
Схема RSA
Предположим, сторона хочет послать стороне сообщение .
Сообщением являются целые числа лежащие от 0 до n-1.

Аффтар же пытается зашифровать строку из 35*8 бит, используя значение n= 9173503, т.е. 20 бит.

Ega23 (2011-01-26 16:52:00) [16]

> Вы видели как шифрует RSA? для чего используются e,d и
> самое главное n? Посмотрите и надеюсь вопрос исчезнет.

Видел. Использовал. И что дальше?

CrytoGen (2011-01-26 16:41:00) [17]
При чОм тут симметричные шифры? Вы видели как шифрует RSA? для чего используются e,d и самое главное n? Посмотрите и надеюсь вопрос исчезнет.

Ega23 (2011-01-26 16:31:00) [18]

> ключ должен быть длиннее шифруемого текста

Это с какого перепоя?

Для современных симметричных алгоритмов (AES, CAST5, IDEA, Blowfish, Twofish) основной характеристикой криптостойкости является длина ключа. Шифрование с ключами длиной 128 бит и выше считается сильным, так как для расшифровки информации без ключа требуются годы работы мощных суперкомпьютеров. Для асимметричных алгоритмов, основанных на проблемах теории чисел (проблема факторизации — RSA, проблема дискретного логарифма — Elgamal) в силу их особенностей минимальная надёжная длина ключа в настоящее время — 1024 бит. Для асимметричных алгоритмов, основанных на использовании теории эллиптических кривых (ECDSA, ГОСТ Р 34.10-2001, ДСТУ 4145-2002), минимальной надёжной длиной ключа считается 163 бит, но рекомендуются длины от 191 бит и выше.

CrytoGen (2011-01-26 16:18:00) [19]
Одни советуют чО попало, второй не удосужился разобраться в теме хоть чуток.
У вас проблемы не с memo. У вас проблемы с длинной ключа - ключ должен быть длиннее шифруемого текста. попробуйте зашифровать текст 123. А потом, чОбы с символами перевода строки развеять сомнения - напишите 12Enter34.
Всё работает-всё крутиться. Думайте - включайте мозги.

stas (2011-01-26 14:34:00) [20]
cr@nk © (26.01.11 06:23) [19]
Ты сразу преобразуй результат еще в hex, а при расшифровке преобразовывай обратно. Тогда не будет проблем с не отображаемыми символами.

Страницы: 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »