Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Основная";
Текущий архив: 2013.03.22;
Скачать: [xml.tar.bz2];

Вниз

Шифрование алгоритмом 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ж}]O cP?.Щ№ 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 бит.


 
Ega23 ©   (2011-01-26 17:08) [29]


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


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


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

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


 
Ega23 ©   (2011-01-26 17:28) [31]


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

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

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


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

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


 
Ega23 ©   (2011-01-26 19:16) [33]


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

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


 
Inovet ©   (2011-01-26 20:23) [34]

> [19] cr@nk ©   (26.01.11 06:23)
> Зашифрованный текст:

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


 
cr@nk ©   (2011-01-26 21:43) [35]

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

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


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

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


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


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

Об том и речь.


 
cr@nk ©   (2011-01-28 22:47) [38]

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

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

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


 
cr@nk ©   (2011-01-29 05:22) [39]

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


 
Anatoly Podgoretsky ©   (2011-01-29 13:17) [40]

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


 
Ega23 ©   (2011-01-31 01:11) [41]


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

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


 
cr@nk ©   (2011-03-12 19:10) [42]

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

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

http://rghost.ru/4739526



Страницы: 1 2 вся ветка

Форум: "Основная";
Текущий архив: 2013.03.22;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.57 MB
Время: 0.082 c
3-1280406421
Alekcey
2010-07-29 16:27
2013.03.22
raised exception ... in module IDODBC32.DLL


15-1332164769
Empleado
2012-03-19 17:46
2013.03.22
Работа с формулами


15-1332713589
-111-
2012-03-26 02:13
2013.03.22
office starter 2010


2-1329472416
AlxAY
2012-02-17 13:53
2013.03.22
Как в отдельном потоке вызвать функцию из основного без зависаний


15-1334223202
brother
2012-04-12 13:33
2013.03.22
в win7 теперь это возможно?





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский