У меня в коде реализована работа с RSACryptoServiceProvider
Суть программы необходимо шифровать бинарный файл размер которого варьирует от 100 килобайт до 60 мегабайт.

основной кусок кода который проводит шифрование

OpenStream - поток из которого читаю открытые данные
byte[] Buffer = new byte[1032000];  - размер выбран как 86 * 12000 
потому что при длинне ключа 1024, заявленный размер пакета который может за один проход корректно зашифровать и расшифровать обратно RSACryptoServiceProvider
а 12000 просто выбрал , потому что много 8-)




при дешифрации разбиваю данные на куски по 128 байт
Хвоста в таком куске не бувает, обычно размер файла кратен 128
процедура дешифрации выглядит так:




код рабочий и в том и в другом направлении. 
Загвоздка в том что 50 метров он шифрует за минуту, а при расшифровке уходит около 30 секунд на 1 метр.
вначале слабым местом было то что читал по 128 и соответственно по 86 байт, но потом исправил и стал читать большими кусками по метру (выше написан уже исправленный код)
после исправления шифрование стало нормальным а вот дешифровка так и осталась медленной. Поставил временный замеры возле функции шифрования и дешифрования
Шифрует за мгновенья, а дешифрует очень долго раз так в 10-15 дольше
так что сделал вывод что гонит RSACryptoServiceProvider на расшифровку

Внимание вопрос:

ЧТО ДЕЛАТЬ ЧТОБЫ УВЕЛИЧИТЬ СКОРОСТЬ?
просто распаковка 50 мегабайт за 25 минут меня не устраивает..

для шифрования больших объёмов данных надо использовать симметрический алгоритм шифрования(DES, AES, Rijindal), а не ассиметрический (RSA).
ассиметрический алгоритм работает значительно медленней , так что большое время вполне оправдано, тем более лоя .net.
тем более то что ты разбиваешь на куски и шифруешь отдельно куски по 128 бит значительно понижает криптостойкость...

чем я понижаю криптостойкость блочного алгоритма?
У RSA шифрование идет блоками, а DES AES они поточные
поэтому я вынужден бить весь поток на блоки по 86 байт.
Криптостойкость его я никак не снижаю абсолютно, кто считают что я неправ пусть первый бросит в меня камень(ну или хотябы объяснит мне где я ошибаюсь).
Меня интересует вопрос не криптостойкости а увеличения скорости.
А в программе вместе с алгоритмом RSA также используются и DES и AES.
Просто пользователю на выбор предлагается алгоритм.

а при тестовом сравнении скоростей, блочный RSA в такой реализации ненамного уступает поточным....может максимум раза в 2....
я считаю что шифрование 50 метров за минуту или за 20-30 секунд...это не такая уж и большая разница...

С учетом того что RSA при расшифровке теоретически делает туже процедуру что и при шифровании, только немного измененную, то сильно большой разницы в скорости шифровка-дешифровка быть не должно, а она не только есть...ОНА ОГРОМНА....
вот это меня и смущает

Это сообщение отредактировал(а) LLlaMaH - 19.5.2008, 08:25

LLlaMaH, ну и посмотри где производительность проседает. Профайлер в руки и вперед   

Это сообщение отредактировал(а) ptr - 19.5.2008, 11:16

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

я же сказал где производительность падает, именно на методе RSA.Decrypt
я хотел узнать может я параметры какие забыл поставить, или еще что нибудь.....




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

не правильно

не правильно

я

книгу Шенона в руки и посмотри что такое шифрование в рса , а что такое расшифрование и быстро всё поймёшь.

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

что именно неправильно? RSA шифрует данные блоками в зависимости от размера ключа. при размере ключа 1024 бит максимальный выходной блок будет 128 байт.
DES и AES шифруют также блоками но в потоке, т.е. суть реализации такова что данные шифруются в потоке поблочно, в дефолтных параметрах ключа при длинне ключа 32 и вектора 16 блок получается 128



что здесь не правильно?

чем я снижаю криптостойкость? я также реализую поток шифрования данных. только блоками по 86 байт с выходом по 128.
Почему Вы считает что данный метод снизит криптостойкость?



аргументируй!



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

алгоритм шифрвания/дешифрования  выполняют приблизительно одинаковый набор действий
и данные операции по времени должны быть соразмерны, а не превышать в 30-50 раз.




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

И не нужно субъективно судить, ведь суть самой программы вам не известна, и серьезность данных которые она защищает тоже может очень варьироваться, я не спорю для документов некоторого уровня секретности можно использовать DES и AES а вот для серьезных данных, я бы лично предпочел RSA.

нет.


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

ваш RSA. 
Вы разделили 50 Мб по 128 байт получается ~ 390 тыс блоков. 
Все эти блоки вы шифруете одним и тем же ключём, без никаких изменений.
Если криптоаналитик (читай хакер)  получит такое количество секретных данных он сможет определить алгоритм шифрования, а также размер ключа.
И ему не составит труда методом подбора выудить ключ, а значит и открытый текст. 
если по простому то: 
Решить систему уравнений с N неизвесным размером 390 тыс уравнений легче.
Решить систему уравнений с N неизвесным размером 1 уравнение.

спасибо за развернутый ответ.
Но все равно я с вами не соглашусь.
Криптоаналитик получивший весь поток того же AES может также вычислить длинну ключа и якобы решить это уравнение, хотя это фактически ОЧЕНЬ трудно реализуемо

а по сути RSA, даже если вы имеет на рукаж 390 тысяч кусков зашифрованных одним и тем же ключем, это вам абсолютно ничего не даст, если вы не знаете какие данные зашифрованны, а с учетом того что шифруются бинарные данные, то проанализировать исходные данные невозможно, даже если предположить что там есть какие либо ключевые шаблонные куски, о которых криптоаналитик точно знает (например заголовочные теги редактора Word) то все равно в каком виде они запакоываны в бинарник фактически злоумышленнику не известно.

а при длине ключа 1024 бита простые числа участвующие в работе алгоритма составляют очень серьезную загадку
если ориентировочно в 128 байт помещается число 3,4028236692093846346337460743177e+38
то узнать два простых числа, вообще практически невозможно, даже если злоумышленник получит эты 390 тысяч кусков, для него они будут лишь мусором.

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


А на счет действий RSA  я немного не согласен
http://ru.wikipedia.org/wiki/RSA

шифрование 
с = m^e MOD n


расшифрование 

m = c^d MOD n


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

это принципиально разные алгоритмы , в AES надо используя метод перебора подбирать правильный ключ , и не важно ты будешь проверять правильность варианта на одном блоке или на сотне блоков, это не поможет найти быстрее ключ. Атаку на rsa , которая угрожает твоей программе в данном случае я уже расписал в предыдущем посте.


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

Пробовал разные ключи,  и разные объемы данных, результат один и тот же. Все больше склоняюсь к тому что RSA все таки не очень корректно реализован.

LLlaMaH, зря так думаешь , в микрософте не глупые дядьки сидят ;)

ФЯ ничего не имею против этих дядек.... я их даже уважаю....но человеческий фактор остается всегда.....каждый раз убеждаюсь что зеленых человечков не бывает и во всем виноваты мои кривые руки ..8-), но сейчас я уже реально свел аолгоритм обработки файла до минимума....он абсолютно одинкавый (фактический копи-паст) с записи (шифрования).... и скорость все равно разная.....
я уже выше писал...что ставил замеры по времни....и получилось что при шифровании у меня 0 целых хрен десятых миллисекунды  на шифрование.... а на расшифровку.. тоже самое только каждый 8-14 проход он зависает на 14-16 милисекунд...

и тут сомнений в том что тонкое место именно тут у меня не осталось....
может там какойнибудь буфер обнулять нужно...либо еще чего... все примеры МСДН молчат...