Посоветуйте RSA либу

Нужна RSA-либа, искал в инете нашёл несколько штук, какую выбрать не знаю. все какие-то навороченные

нужен простейший минимум, что-то в духе:

Код (Text):

1. bool RSACrypt(
2.    pSourceData,
3.    SourceDataSize,
4.    pSecretRSAKey, (указатель на буффер размером 256 байт (2048bit))
5.    RSAKeySize, (256 байт)
6.    pDestBuffer,
7.    DestBufferSize)
8.  
9. bool RSADecrypt(
10.    pSourceData,
11.    SourceDataSize,
12.    pOpenRSAKey,  (указатель на буффер размером 256 байт (2048bit))
13.    RSAKeySize,     (256 байт)
14.    pDestBuffer,
15.    DestBufferSize)

т.е. необходимый минимум: зашировал(указал данные и секретный ключ) и расшифровал(указал данные и открытый ключ)

все какие-то блатные с поддержкой XML и прочими свистелками и перделками

 

мне cryptopp понравилась, правда конечно там все чуть сложнее чем Вы указали) но думаю Вы ее и без меня нашли.
А если Вам все таки не нравится это, то проще всего взять GMP да закодить RSA, простенько и со вкусом)

На сколько я помню в RSA Вы шифруете ОТКРЫТЫМ ключем а расшифровываете ЗАКРЫТЫМ.) А если наоборот то это длинная подпись.)))

 

тоже склонялся к crypto++

цель реализовать именно подпись. чтобы клиент расшифровал данные и был уверен что данные зашифровал именно я

 

rpy3uH
Со временем мне тоже данная фишка пригодится.
Если реализуете, либо сделаете свою обертку над паблик-либой, сможете выложить код на форум?
Многие будут благодарны.

 

если сделаю, то выложу

 

могу выложить свою реализацию на базе gmp но только в районе 16 января(нет под руками исходников), если интересно.

 

Алгос зонбека. Как раз под 256бит ключи.

 

rpy3uH,Magnum
Когда-то тоже задался таким вопросом (кстати, в #1 помимо ключа еще и основание нужно передавать в функи), но не нашел НЕ навороченных аналогов - решил написать сам...
Но, со временем (как разобрался в математике), тоже появились навороты и в своем коде - связаны с оптимизацией вычислений и многопоточностью...
(пришлось вводить спец-е структуры контекстов).... Ну, например - если использовать интерфейс функций, приведенный в #1, то скорость вычисления нескольких RSA-операций подряд будет очень низкая (например, надо дешифровать 10 блоков подряд - 1мс*10 = 10мс - без оптимизации (1мс - 1 RSA-операция к-примеру), а с оптимизацией будет примерно 1.5-2 мс. на все 10 RSA-операций).

 

все зависит от конкретной задачи, если нужно шифровать большие объемы данных то конечно нужно выжимать скорость например применяя алгоритмы быстрого возведения в степень по фиксированному показателю и прочую оптимизацию если только маленькие объемы и на разных ключах то много не выиграть. Но код, как замечено, разрастется достаточно сильно.

 

навороченность состоит в том что имеющиеся либы. распределены на ~50 файлов, с использованием не меньшего количества мелких классов. а пока будешь всё этом говне разбираться пройдёт столько времени сколько тебе хватило бы самому запилить подобное. в прицнипе даже пойдут функции с использованием контекстов. но самое важное это суть, две функции: crypt() и decrypt() пусть будет в начале что-то вроде intitialize() а после release(), это не важно

 

нопремер 512 бит, исправьте одну цыферу и будет вам 256. все ждут от зонбика новых рса-релизенгов

 

а, ну и

Код (Text):

1. ; encrypt message n1 into n2 using public rsa_e and public rsa_n
2.                         push    offset n1       ; input
3.                         push    offset n2       ; output
4.                         push    offset rsa_e    ; e
5.                         push    offset rsa_n    ; n
6.                         call    rsa_main
7.  
8. ; decrypt message n2 into n3 using secret rsa_d and public rsa_n
9.                         push    offset n2       ; input
10.                         push    offset n3       ; output
11.                         push    offset rsa_d    ; d
12.                         push    offset rsa_n    ; n
13.                         call    rsa_main

 

Windows CryptoAPI и не надо никаких либ.

 

K10
Он не умеет шифровать на приватном ключе!

rpy3uH
Я вот на основе сурцов PolarSSL сделал свои реализации RSA функций (оптимизировал под Little-Endian и под формат ключей CryptoApi). Конвертаций в Big-Endian теперь по минимуму.
Реализацию AES тоже из PolarSSL взял.
А вот из crypto++ взял алгоритм TwoFish и переписал всё под чистый Си с множеством оптимизаций.

 

T800

RSA ключом шифруется симметричный ключ, которым уже шифруются данные.
Если у вас необходимость шифровать данные именно RSA, то явно неправильно спроектирована реализация.

 

чего неправильного ? зашифровать закрытым, расшифровал открытым, ну или наоборот, но смысл тот же.
ну очевидно что открытый ключ (e, n), приватный ключ это пара (d,n)

суть - чтобы клиент расшифровал мой файл открытым ключём и был уверен что этот файл зашифровал я.

 

Дело в том, что K10 прав, в том что использовать RSA для шифрования не рекомендуется и вот почему:
1. Низкая скорость, как бы Вы не оптимизировали алгоритм RSA то все равно он в 10 раз будет проигрывать симметричным алгоритмам, так как возведение
в степень и вычисление по модулю это прожорливые операции.
2. Есть опасность разнообразных атак, связанных с отсутствием имитостойкости у RSA (если вы возведете шифр текст в степень, то можете отдать его пользователю, пользователь его расшифрует и будет считать что он от Вас, но внутри у него будут друге данные, понятно что от этого просто защититься но это простенький пример)
3. У RSA есть ограничения на открытый текст, он должен быть из мультипликативной группы (т.е. 0000000000 биты шифровать нельзя) что тоже не совсем подходит для шифрования фалов.


Исходя из выше сказанного обычно делают как-нибудь так:
1. файл шифруется на сеансовом ключе Кs - каким-нибудь симметричной криптосистемой системой
2. этот сеансовый ключ шифруется RSA
3. пользователю передается файл зашифрованный на Ks и зашифрованный ключ.

Если необходимо что-бы только доверительный пользователь мог расшифровать сеансовый ключ, то поверх зашифрованного на собственном секретном ключе сеансового ключа накладывается RSA с использование открытого ключа пользователя, которому предназначено сообщение - такая схема носит название цифрового конверта.

 

не критично. файлы имеют размер не более 64 КБ

внутрь исходного текста запихать контрольную сумму, если после расшифровки контрольная сумма совпадает, то всё хорошо

файл можно предварительно перекодировать или ужать. другими словами применить операцию повышающую энтропию


Даже если делать цифровую подпись всё равно нужен RSA

 

Никто не говорить, что с этим нельзя бороться)
Просто очень много всяких мелочей, и борьба с ними может достаточно сильно увеличить код.
В любом случае выбор за вами.

 

в прицнипе вне зависимости от реализации RSA всё равно нужен. факт