Шифрование алгоритмом RSA

← →
cr@nk © (2011-01-15 23:30) [0]

Задается исходная строка и надо зашифровать её по алгоритму 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, то получаем на выходе получаем Ц §1–c .
Есть догадка, что в модуле от FGInt присутствует какая-то "добавка", которая в корне меняет конечный результат. Но также в тех 2-х программах очень не нравится выходная строка - одинаковые тройки чисел.

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

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

← →
Германн © (2011-01-16 03:52) [1]

> P.S.: При использовании модулей FGInt в Delphi 2010, XE
> возникает ошибка

А ты уверен, что данные модули правильно работают с Юникодом?

← →
cr@nk © (2011-01-16 07:18) [2]

> А ты уверен, что данные модули правильно работают с Юникодом?

Нет, поэтому использую Delphi 7

← →
CrytoGen (2011-01-16 08:04) [3]

RSAEncrypt("111111", e, n, test); работает не с десятичными данными, это обычная строка, так что ожидать результата в виде 4051753 глупо.

← →
cr@nk © (2011-01-16 08:52) [4]

Ясно. Т.е. в целом FGInt выдаёт верные данные?
Проверить бы как-нибудь

← →
CrytoGen (2011-01-16 11:09) [5]

если вы не можете эти данные проверить, то дело плохо :)

← →
Anatoly Podgoretsky © (2011-01-16 12:00) [6]

> cr@nk (16.01.2011 08:52:04) [4]

Проверить просто, надо попытаться расшифровать зашифрованые данные, если
расшифруешь и они будут равны исходным, то работает правильно.

← →
cr@nk © (2011-01-16 18:10) [7]

> Anatoly Podgoretsky (16.01.11 12:00) [6]

Ну такую проверку я осуществлял средствами модуля FGInt и тексты совпадали :)
Просто хотелось быть уверенным, что это именно чистый алгоритм и некая сферическая программа, написанная другим человеком будет совместима с моей :)

← →
cr@nk © (2011-01-17 17:54) [8]

Подскажите пожалуйста решение дальнейшей проблемы - при шифровании может случиться так, что зашифрованная строка будет содержать #10#13 (мне кажется, что именно их) и в результате не получается правильно декодировать строку
Пример: http://dl.dropbox.com/u/4653598/TestCrypto.rar

← →
stas © (2011-01-20 17:13) [9]

вот еще тема http://delphimaster.net/view/15-1292509828/

← →
Ega23 © (2011-01-20 18:15) [10]

> Просто хотелось быть уверенным, что это именно чистый алгоритм
> и некая сферическая программа, написанная другим человеком
> будет совместима с моей :)

FGInt - хороший, годный модуль. Не волнуйся.

← →
cr@nk © (2011-01-22 23:02) [11]

> stas © (20.01.11 17:13) [9]

Там больше про CryptoAPI . Его я собираюсь попозже изучать

> FGInt - хороший, годный модуль. Не волнуйся.

Успокоили :)

Скажите, а есть рабочий пример с FGInt и использовании многострочных компонентов типа Memo, RichEdit

← →
Германн © (2011-01-23 02:23) [12]

> cr@nk © (17.01.11 17:54) [8]
>
> Подскажите пожалуйста решение дальнейшей проблемы - при
> шифровании может случиться так, что зашифрованная строка
> будет содержать #10#13 (мне кажется, что именно их) и в
> результате не получается правильно декодировать строку

> cr@nk © (22.01.11 23:02) [11]
>
>
> > stas © (20.01.11 17:13) [9]
>
> Там больше про CryptoAPI . Его я собираюсь попозже изучать
>
> > FGInt - хороший, годный модуль. Не волнуйся.
>
> Успокоили :)
>
> Скажите, а есть рабочий пример с FGInt и использовании многострочных
> компонентов типа Memo, RichEdit
>

А в чём собственно проблемы?
Чем тебе мешают символы LF/CR?
Ты приведи свой код. Тогда посмотрим и найдём ошибки.

← →
cr@nk © (2011-01-23 10:09) [13]

Пример: http://dl.dropbox.com/u/4653598/TestCrypto.rar
Если архив не скачивается, то дайте знать - отзеркалю ещё куда-нибудь

← →
Германн © (2011-01-24 02:55) [14]

> cr@nk © (23.01.11 10:09) [13]
>
> Пример: http://dl.dropbox.com/u/4653598/TestCrypto.rar
>

Это не то, что я имел в виду.
Проблемы (ошибки) в коде не указаны.

← →
cr@nk © (2011-01-24 05:24) [15]

При расшифровке текста
test:=reCryptoText.Lines.Strings[0]; ИЛИ test:=reCryptoText.Lines.Text; RSADecrypt(test, d, n, Nilgint, Nilgint, Nilgint, Nilgint, test);
не получается первоначальный текст

Если же в процедуре шифрования bnCryptoClick зашифрованный текст записать в глобальную переменную (например, global_test), то расшифровка проходит нормально
test:=reOriginalText.Lines.Text; RSAEncrypt(test, e, n, test); global_test:=test; reCryptoText.Lines.Text:=test;
=====================================
RSADecrypt(global_test, d, n, Nilgint, Nilgint, Nilgint, Nilgint, test); reOriginalText.Lines.Text:=test;
А если зашифрованный текст брать из визуального компонента (как в исходниках), товсё перестаёт работать

← →
cr@nk © (2011-01-25 23:06) [16]

Если надо ещё что-то сообщить, то с радостью :)
Ибо самому решить никак не получается

← →
Ega23 © (2011-01-26 00:25) [17]

test:=reCryptoText.Lines.Text; RSADecrypt(test, d, n, Nilgint, Nilgint, Nilgint, Nilgint, test);

А если
RSADecrypt(reCryptoText.Lines.Text, d, n, Nilgint, Nilgint, Nilgint, Nilgint, test);
?

← →
Германн © (2011-01-26 05:28) [18]

> не получается первоначальный текст
>

А что получается?

> Если же в процедуре шифрования bnCryptoClick зашифрованный
> текст записать в глобальную переменную (например, global_test),
> то расшифровка проходит нормально

Ну так записывай в глобальную переменную, если иначе не получается.

P.S.
Или ты в процедуре шифрования записываешь результат в TMemo? Ну тогда ССЗБ.

← →
cr@nk © (2011-01-26 06:23) [19]

RSADecrypt(reCryptoText.Lines.Text, d, n, Nilgint, Nilgint, Nilgint, Nilgint, test);
Это я пробовал сразу. Результат отрицательный

А что получается?
Пример:
Входная строка:
01234567890123456789012345678901234
Зашифрованный текст:
“ _?Gл/•wж}]OcP?.Щ№gХ?7G-pЛ6]v
После попытки расшифровать этот текст получаем:
ж6Ї

>
> Ну так записывай в глобальную переменную, если иначе не
> получается.
> P.S.
> Или ты в процедуре шифрования записываешь результат в TMemo? Ну тогда ССЗБ.

Так ситуация такая получается: на одном компе шифруем текст, сохраняем его в файл, переносим на другой ПК, загружаем его и пытаемся расшифровать. Но на данный момент это бессмысленно, т.к. в Tmemo и прочем зашифрованный текст получается уже искажен (видимо самим компонентом)

← →
Германн © (2011-01-26 06:35) [20]

> т.к. в Tmemo и прочем зашифрованный текст получается уже
> искажен (видимо самим компонентом)

Ну естественно! Забудь про TMemo! И про другие визуальные компоненты, показывающие текст.
Зачем вообще тебе понадобился сей компонент? Проверить правильность работы процедуры шифрования? Тогда ты ошибся. Он для такой проверки не годится! Зашифрованный текст нужно смотреть в HEX-редакторе (вьювере). А сохранять его нужно в любой приемлемый бинарный буфер.
P.S. Строка (String) тоже является таким буфером.

← →
cr@nk © (2011-01-26 06:47) [21]

Ещё попробовал сравнить посимвольно глобальную переменную и reCryptoText.Lines.Text вот в таком вот простом цикле
With ListBox1.Items Do begin Clear; Add("GLOBAL"+inttostr(length(global_test))+" - RICHEDIT"+inttostr(length(reCryptoText.Lines.Text))); For i:=0 To length(global_test)-1 Do begin ADD (global_test[i]+" - "+reCryptoText.Lines.Text[i]) end; end;
Шифроуем слово test
Получаем:
_E Ж|e?=

GLOBAL8 - RICHEDIT12 _ - _ E - E - Ж - | - e - Ж ? - |
В самой первой строке отображается сколько символов в глобальной переменной и сколько их в RchEdit

← →
cr@nk © (2011-01-26 06:51) [22]

>
> Ну естественно! Забудь про TMemo! И про другие визуальные компоненты, показывающие текст.

Спасибо за объяснения. Буду искать приемлемый выход из данной ситуации :)

← →
stas © (2011-01-26 14:34) [23]

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

← →
CrytoGen (2011-01-26 16:18) [24]

Одни советуют чО попало, второй не удосужился разобраться в теме хоть чуток.
У вас проблемы не с memo. У вас проблемы с длинной ключа - ключ должен быть длиннее шифруемого текста. попробуйте зашифровать текст 123. А потом, чОбы с символами перевода строки развеять сомнения - напишите 12Enter34.
Всё работает-всё крутиться. Думайте - включайте мозги.

← →
Ega23 © (2011-01-26 16:31) [25]

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

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

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

← →
CrytoGen (2011-01-26 16:41) [26]

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

← →
Ega23 © (2011-01-26 16:52) [27]

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

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

← →
CrytoGen (2011-01-26 16:59) [28]

Шарик ты балбес! Знаю я как вы используете...
http://ru.wikipedia.org/wiki/RSA
Схема RSA
Предположим, сторона хочет послать стороне сообщение .
Сообщением являются целые числа лежащие от 0 до n-1.

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

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

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

← →
CrytoGen (2011-01-26 17:15) [30]

Предположим было несколько ранее написано. Так часто пишут, вы книжки почитайте.
Я знаю что зашифровать можно. Но только RSA здесь уже не причОм. RSA шифрует блоками. Если разбить сообщение на блоки, то можно зашифровать и маленьким ключом. Однако аффтар пытается зашифровать блок длинной 280 бит, используя значение n длинной 20 бит.

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

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

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

← →
CrytoGen (2011-01-26 17:32) [32]

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

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

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

Извините, что вмешиваюсь в спор, но в данном случае (как мне кажется) проблема всё же в том, что RichEdit "удлиняет" зашифрованный текст.

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

← →
CrytoGen (2011-01-26 22:03) [36]

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

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

Об том и речь.

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

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

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

Писал ночью... накосячил немного :)
- Текст сначала шифруется, а потом подписывается
- И конечно же подпись проверяется моим бубличным ключиком

Достаточно одного из двух

Шифрование алгоритмом RSA Найти похожие ветки