Здравствуйте!

Демо-проект ASYMMETRIC - Асимметричное шифрование. (C#)
Демо-проект ENCFILE - Шифрование/дешифрование файла алгоритмом 3DES с хешем MD5, подписанным ЭЦП. (VC6)
Демо-проект SYMMETRIC - Симметричное шифрование. (C#)
Демо-проект RSAKG - Генерация ключевых пар RSA. (VC6)

Введение

Криптография, как прикладная дисциплина, существует уже очень давно. Один из простейших шифров, шифр алфавитной замены, использовался еще во времена Цезаря. Но настоящий расцвет криптографии произошел только в последние несколько столетий, когда к задачам шифрования был применен математический аппарат. Эта статья дает обзор криптографических алгоритмов, предоставляемых MS CryptoAPI 2.0 и .NET Framework, и содержит примеры их использования на языках C++ (CryptoAPI) и C# (.NET). Также вкратце описывается набор замечательных ошибок, обнаруженных автором в реализации класса RSACryptoServiceProvider библиотеки .NET Framework.

Симметричные и асимметричные шифры

Основное назначение любого шифра – обеспечение возможности передачи сообщения по незащищенным каналам (не обязательно сетевым) с защитой этого сообщения от прочтения посторонними лицами. Посмотрим, что же такое шифры и с чем их едят.

Сначала дадим краткое определение криптографических функций шифрования и дешифрования.

Пусть есть две функции E(M1,K1) и D(M2,K2), зависящие от сообщений M1 и M2 и ключей K1 и K2, такие, что D(E(M,K1),K2)=M для некоторой пары ключей K1 и K2 и любого M, тогда E(.) и D(.) – функции шифрования и дешифрования, соответственно. Результат C=E(M,K1) называется криптограммой (или шифрограммой).

К функциям E(.) и D(.) предъявляются следующие требования:

1. Они должны быть легко вычислимы для любых M, если известны K1 и K2.
2. Вычисление D(M,?) – тяжелая задача при неизвестном ключе K2 (т.е., не зная ключа дешифрования, мы не можем вычислить исходное сообщение по криптограмме).
3. Вычисление ключей K1 и K2 – тяжелая задача при наличии некоторого набора пар {M,E(M,K1)} (имея набор криптограмм и исходных сообщений, мы не можем вычислить ключи).
4. Вычисление K2 (в случае K2 отличного от K1) при известном K1 – также должно быть трудной задачей (это требование относится к асимметричным шифрам. Для цифровой подписи K2 и K1 меняются ролями).

Надежность шифра определяется именно по его соответствию вышеперечисленным требованиям, при этом считается, что алгоритмы вычисления E(.) и D(.) известны всем (есть еще вариант так называемой Security by obscurity, т.е. защиты из-за неизвестности алгоритма, но он при оценке стойкости шифров не рассматривается).

Если K1=K2, то шифр называется симметричным, в противном случае – асимметричным. Примеры известных симметричных шифров – DES, IDEA, Blowfish, ГОСТ, асимметричных – RSA, ECC.

Шифры также бывают блочными и потоковыми. Блочный шифр работает с сообщениями фиксированного размера (например, 64 бита), а поточный – шифрует весь поток данных посимвольно (например, побайтно). Известные блочные шифры – DES, IDEA, Blowfish, потоковые – RC4. Блочность шифра не означает невозможность шифрования им сообщений, превышающих по длине размер блока.

Существуют следующие распространенные варианты использования блочных шифров для шифрования длинных сообщений:

• ECB (Electronic CodeBook) – режим электронной кодовой книги. В этом режиме каждый блок шифруется независимо от других. Этот режим удобен для шифрования частей файла, записей в базе данных и т.п., однако при этом одинаковые фрагменты исходного сообщения порождают одинаковые фрагменты криптограммы, так что, зная часть исходного сообщения, злоумышленник может легко восстановить совпадающие фрагменты.
• CBC (Cipher Block Chaining) – режим сцепления блоков шифра. Это самый распространенный режим. В этом режиме шифруется не сам блок исходного сообщения, а его XOR с результатом шифрования предыдущего блока (это верно для всех блоков, кроме первого). Т.е. C(i)=E(M(i) xor C(i-1)), для всех i>0, C(0)=E(M(0) xor I), где I – это начальный вектор инициализации (он может передаваться вместе с шифрограммой в открытом виде).
• CFB (Cipher FeedBack) – режим обратной связи по шифру. Этот режим фактически превращает блочный шифр в потоковый. Для шифрования используется регистр R с размером, равным размеру блока. В начале он заполняется инициализационным вектором I. На каждом шаге регистр шифруется, и над n битами исходного сообщения (шифрование может идти как побитно, так и блоками по n=2, 4, … бита) выполняется XOR со старшими (левыми) битами E(R). Результат этого XOR и является частью шифрограммы. Затем R сдвигается на n бит влево, а результат XOR записывается в младшие (правые) разряды R.
• OFB (Output FeedBack) – режим выходной обратной связи. Этот режим очень похож на CFB, но вместо битов шифрограммы в регистр R вдвигаются старшие биты результата E(R), тем самым состояние сдвигового регистра вообще не зависит ни от исходного сообщения, ни от криптограммы.

Потоковые шифры в этой статье не рассматриваются. Я также не буду приводить деталей реализации конкретных блочных шифров, т.к. это выходит за рамки данной статьи, и существуют хорошие книги по криптографии, где эти алгоритмы рассматриваются в деталях (например, [1]).

Однако стоит немного остановиться на асимметричных шифрах, а точнее на популярной их разновидности – шифрах с открытым ключом. Шифр с открытым ключом имеет два ключа – открытый (public), который можно свободно распространять, и закрытый (private), который держится в секрете. Зашифровать сообщение может кто угодно, но расшифровать его сможет только владелец закрытого ключа. Системы шифрования с открытым ключом, как правило, основываются на сложности разрешения какой-либо математической задачи. Например, популярный алгоритм RSA основан на сложности разложения на множители произведения двух больших простых чисел. Рассмотрим этот алгоритм поподробнее, т.к. понимание основ его работы нам пригодится в дальнейшем.

Алгоритм RSA

Для генерации ключевой пары выбираются два больших (по современным требованиям надежности не менее 512 бит) простых числа (некоторые популярные алгоритмы их генерации рассмотрены в [1]) p и q. Затем вычисляется их произведение n=p*q и выбирается случайное число e, так что e взаимно просто с (p-1)*(q-1). Также вычисляется число d, такое, что d*e=1 mod (p-1)*(q-1) (эта операция делается с помощью расширенного алгоритма Евклида, см. [1]). Это означает, что

d*e=1+k*(p-1)*(q-1), где k – некое целое число. Открытым ключом является пара e и n, закрытым – d и n. Алгоритм позволяет шифровать сообщения m меньшие, либо равные n (как целые неотрицательные числа). Большие сообщения следует разбивать на части.

Шифрование осуществляется следующим способом:

c=m^e mod n (возведение m в степень e по модулю n),

а дешифрование производится так:

m=c^d mod n.

Гарантию того, что получится верный результат, дает малая теорема Ферма. Для любого a меньше, либо равного n:

a^phi(n)=1 mod n, где phi(n) – число целых положительных чисел меньших n и взаимно простых с ним. Для n=p*q, phi(n)=(p-1)*(q-1) и

(m^e)^d mod n = m^(1+k*phi(n)) mod n=m.

Хеши

Основное предназначение криптографических хешей – контроль подлинности данных путем вычисления от них некоторой функции H(.), дающей результат фиксированной (и обычно небольшой длины). Функция H(.) должна удовлетворять следующим требованиям:

Для любых сообщений m, h=H(m) легко вычисляема.

Задача нахождения такого u (отличного от m), чтобы H(u)=h, должна являться трудной при неизвестном m.

Задача нахождения такого u, что H(u)=H(m) является трудной при известном m.

Большинство популярных хеш-функций генерируют хеш длиной 128 бит и более. Примерами наиболее распространенных хеш-функций являются MD5 и SHA. Значения хеш-функций часто используются в системах электронной цифровой подписи для генерации дайджеста сообщения, который затем и подписывается тем или иным алгоритмом. Также хеш-функции применяются в системах аутентификации для проверки паролей – открытый пароль пользователя не должен храниться в системе, вместо него хранится его хеш, который затем и сравнивается с хешем от пароля, вводимого пользователем при входе в систему.

Цифровая подпись

Электронная цифровая подпись (ЭЦП), как и обычная, позволяет установить некую отметку, указывающую на принадлежность электронного сообщения конкретному автору. Алгоритмы цифровой подписи тесно связаны с асимметричными шифрами. Например, алгоритм цифровой подписи RSA – это практически шифр RSA, но шифруется не само сообщение, а его дайджест, и шифрование производится не на открытом ключе, а на закрытом. В этом случае любой получатель, имеющий открытый ключ автора, может расшифровать дайджест и проверить его правильность.

Обмен ключами

Хорошо, у нас есть работающий шифр (или система ЭЦП), который мы хотим использовать для защищенной передачи данных. Однако остается одна проблема – обмен ключами. Симметричному алгоритму нужен один и тот же ключ как на шифрующей, так и на дешифрующей стороне. Требуется надежный способ генерации одинаковых сеансовых ключей на обеих сторонах или передачи ключа шифрующей стороной дешифрующей стороне (в качестве такого способа может выступать надежный курьер с дискеткой). Существуют специальные алгоритмы генерации совпадающих сеансовых ключей, но мы их рассматривать не будем, т.к. в CryptoAPI и .NET они не используются. Рассмотрим, как можно передать сгенерированный на шифрующей стороне сеансовый ключ другой стороне. Самый простой вариант – использовать шифр с открытым ключом. Имея открытый ключ получателя, мы шифруем на нем сеансовый ключ и передаем результат получателю вместе с зашифрованными данными. Теперь получатель может расшифровать сеансовый ключ и сами данные. Казалось бы, все хорошо, однако тут кроется еще одна проблема, связанная с распределением открытых ключей. В самом деле, где гарантия того, что полученный открытый ключ действительно принадлежит конкретному получателю? Если злоумышленник перехватил оригинальный открытый ключ и подсунул вместо него свой, то зашифрованный сеансовый ключ получит именно он, а не требуемый получатель. В дальнейшем злоумышленник может выдать себя за получателя и перехватить передаваемое сообщение. Для предотвращения такой возможности вводят различные сети доверия (trusted network) и авторитетные источники (trusted authority), которые берут на себя ответственность за подлинность открытого ключа (ключ подписывается собственной подписью центра, которой все безоговорочно доверяют).

Работа с CryptoAPI

Криптопровайдеры, инициализация и деинициализация

Любой сеанс работы с CryptoAPI начинается с инициализации (получения контекста). Инициализация выполняется при помощи функции CryptAcquireContext. В качестве параметров эта функция принимает имя контейнера ключей, имя криптопровайдера, тип провайдера и флаги, определяющие тип и действия с контейнером ключей и режим работы криптопровайдера:

BOOL WINAPI CryptAcquireContext(HCRYPTPROV* phProv,LPCTSTR pszContainer,
  LPCTSTR pszProvider,DWORD dwProvType,DWORD dwFlags);

Криптопровайдер – это сущность (обычно библиотека), реализующая определенный набор криптографических алгоритмов и обеспечивающая работу с ними. Существует около семи стандартных провайдеров, предустановленных в системе. Нам для примеров понадобятся два из них – Microsoft Base Cryptographic Provider (MS_DEF_PROV) и Microsoft Enhanced Cryptographic Provider (MS_ENHANCED_PROV).

ПРИМЕЧАНИЕ Заметим, что Enhanced-провайдер присутствует только на тех машинах, где установлена поддержка 128-битного шифрования (она автоматически устанавливается вместе с Internet Explorer 6.0).

Каждый криптопровайдер относится к определенному типу. Это позволяет, перебрав все установленные на машине провайдеры, выбрать те, которые поддерживают нужные алгоритмы. Два упомянутых провайдера имеют тип PROV_RSA_FULL.

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

ПРИМЕЧАНИЕ Стандартные криптопровайдеры хранят ключи на диске, в зашифрованном виде. Однако существует потенциальная возможность, что злоумышленник, укравший компьютер или жесткий диск, сможет расшифровать сохраненные ключи.

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

Для первоначального создания контейнера нужно вызвать CryptAcquireContext с флагом CRYPT_NEWKEYSET. Для удаления контейнера требуется указать флаг CRYPT_DELETEKEYSET.

Если приложению не требуется доступ к контейнеру ключей (например, приложение вычисляет хеш MD5), то стоит вызывать CryptAcquireContext с флагом CRYPT_VERIFYCONTEXT, передавая NULL вместо имени контейнера.

Следующий пример демонстрирует инициализацию CryptoAPI для последующего вычисления хеша MD5:

HCRYPTPROV hProv;
if(!CryptAcquireContext(&hProv, NULL, MS_DEF_PROV, PROV_RSA_FULL,
                        CRYPT_VERIFYCONTEXT))
{
    MessageBoxA("Failed to acquire cryptographic context",
                "Error", MB_OK|MB_ICONERROR);
    return;
}
//здесь что-то делаем
//.
CryptReleaseContext(hProv,0);

Деинициализация CryptoAPI выполняется с помощью функции CryptReleaseContext, единственным значащим параметром которой является полученный ранее хэндл криптографического контекста.

Генерация ключей и обмен ключами

Для генерации ключей в CryptoAPI предусмотрены две функции – CryptGenKey и CryptDeriveKey. Первая из них генерирует ключи случайным образом, а вторая – на основе пользовательских данных. При этом гарантируется, что для одних и тех же входных данных CryptDeriveKey всегда выдает один и тот же результат. Это способ генерации ключей может быть полезен для создания симметричного ключа шифрования на базе пароля. Мы же более подробно остановимся на функции CryptGenKey, которая используется чаще всего. Эта функция имеет прототип:

BOOL WINAPI CryptGenKey(HCRYPTPROV hProv, ALG_ID Algid, DWORD dwFlags,
                        HCRYPTKEY* phKey);

Первый и четвертый параметры говорят сами за себя. Вторым параметром передается идентификатор алгоритма шифрования, для которого генерируется ключ (например, CALG_3DES). При генерации ключевых пар RSA для шифрования и подписи используются специальные значения AT_KEYEXCHANGE и AT_SIGNATURE. Третий параметр задает различные опции ключа, которые зависят от алгоритма и провайдера. Например, старшие 16 битов этого параметра могут задавать размер ключа для алгоритма RSA. Подробное описание всех флагов можно найти в MSDN. Здесь я упомяну только один флаг - CRYPT_EXPORTABLE, который позволяет экспортировать закрытые ключи RSA из контейнера (по умолчанию это запрещено). Для других ключей этот параметр смысла не имеет – открытые ключи являются свободно экспортируемыми, а сессионные ключи вообще не хранятся внутри контейнера, т.ч. их обязательно нужно экспортировать.

Параметры, которые нельзя задать при генерации ключа (например, инициализационные векторы), можно установить уже после его создания с помощью функции CryptSetKeyParam. Ее рассмотрение, однако, выходит за рамки этой статьи.

Обмен ключами в CryptoAPI реализуется с помощью функций CryptExportKey и CryptImportKey, имеющих следующие прототипы:

BOOL WINAPI CryptExportKey(HCRYPTKEY hKey,HCRYPTKEY hExpKey,DWORD dwBlobType,
 DWORD dwFlags,BYTE* pbData,DWORD* pdwDataLen);

BOOL WINAPI CryptImportKey(HCRYPTPROV hProv,BYTE* pbData,DWORD dwDataLen,
 HCRYPTKEY hImpKey, DWORD dwFlags,HCRYPTKEY* phKey);

В качестве ключей экспорта/импорта могут использоваться либо ключевая пара RSA (с типом AT_KEYEXCHANGE), либо симметричный сеансовый ключ. Параметр dwBlobType зависит от того, какой ключ экспортируется (импортируется), и задает тип структуры, в которую помещается экспортируемый ключ. Для открытого ключа это PUBLICKEYBLOB, и ключ экспорта/импорта при этом лишен смысла и должен быть нулем. Для закрытого ключа это PRIVATEKEYBLOB, и в качестве ключа экспорта может использоваться сеансовый ключ. Для сеансового ключа это обычно SIMPLEBLOB (бывает еще OPAQUEKEYBLOB и SYMMETRICWRAPKEYBLOB, но мы их рассматривать не будем), а экспортируется он, как правило, на открытом ключе получателя.

Описание флагов можно найти в MSDN. Я выделю среди них флаг CRYPT_OAEP, который заставляет криптопровайдера использовать формат PKCS #1 версии 2 при сохранении сессионного ключа с шифрованием RSA. Ключ, сохраненный в этом формате, затем может быть расшифрован другими системами шифрования (например, я так передавал ключ в библиотеку Crypto++). Если же этот флаг не указан, то ключ сохраняется в каком-то ведомом только CryptoAPI формате, и использовать его где-либо еще вряд ли удастся.

И, наконец, параметры pbData и pdwDataLen задают адрес и размер буфера под структуру экспортируемого ключа. Если размер структуры не известен при написании программы, то можно определить требуемый размер буфера, установив в pbData ноль. В этом случае нужный размер возвращается в pdwDataLen.

После окончания работы с ключом, его нужно уничтожить вызовом CryptDestroyKey.

ПРИМЕЧАНИЕ При этом закрытый ключ сохраняется в контейнере (если, конечно, не использовался режим CRYPT_VERIFYCONTEXT), а сессионные ключи уничтожаются совсем.

В качестве примера рассмотрим создание и экспорт пары ключей для шифрования RSA и симметричного ключа 3DES:

//создание и экспорт пары ключей  RSA

if(CryptGenKey(hProv,AT_KEYEXCHANGE,1024<<16,&hKey)) //генерируем 1024-битный ключ
{
    RSAPubKey1024 key; //эта структура описана в файле tools.h в примере rsakg
    DWORD dwLen=sizeof(RSAPubKey1024);
    //экспортируем ключ
    if(CryptExportKey(hKey,NULL,PUBLICKEYBLOB,0,(BYTE *)&key,&dwLen)) 
    {
        //. тут что-то делаем
    }
    CryptDestroyKey(hKey); //уничтожаем ключ
}

//генерация и экспорт ключа 3DES

if(::CryptGenKey(hProv,CALG_3DES,CRYPT_EXPORTABLE,&hKey)) //генерируем ключ для 3DES
{
    RSA1024KeyExchBLOB kb; //описание см. в tools.h
    dwLen=sizeof(RSA1024KeyExchBLOB);
    //экспортируем ключ 3DES на публичном ключе RSA 

    if(::CryptExportKey(hKey,hPubKey,SIMPLEBLOB,0,(BYTE *)&kb,&dwLen)) 

    {
        //.
    }
}

Рабочие примеры генерации и импорта/экспорта ключей приведены в демонстрационных проектах rsakg и encfile.

Симметричные шифры DES и 3DES

Это одни из немногих симметричных шифров, предоставляемых стандартными криптопровайдерами CryptoAPI. Поскольку DES и 3DES – это практически один и тот же алгоритм (3DES – это DES, применяемый 3 раза подряд), то мы ограничимся примером использования алгоритма 3DES.

ПРИМЕЧАНИЕ Однако заметим, что для использования алгоритма 3DES требуется Enhanced провайдер, а для DES вполне достаточно Base. Впрочем, DES уже не является стойким по современным меркам алгоритмом, поэтому использовать его стоит лишь там, где надежность шифрования не очень критична.

Алгоритм 3DES использует разные ключи DES для каждой из своих итераций. Поэтому размер его ключа равен тройному размеру ключа DES, т.е. 192 (64*3) бита. Реально размер ключа 3DES – 168 (56*3) бит, т.к. в DES один байт ключа является контрольным для основных семи. Шифрование и дешифрование выполняются с помощью функций:

BOOL WINAPI CryptEncrypt(HCRYPTKEY hKey,HCRYPTHASH hHash,BOOL Final,DWORD dwFlags,

      BYTE* pbData,DWORD* pdwDataLen,DWORD dwBufLen);

BOOL WINAPI CryptDecrypt(HCRYPTKEY hKey,HCRYPTHASH hHash,BOOL Final,DWORD dwFlags,
 BYTE* pbData,DWORD* pdwDataLen);

Параметр hHash позволяет параллельно с шифрованием/дешифрованием проводить хеширование данных для последующей электронной подписи или ее проверки. Флаг Final определяет, является ли шифруемый блок данных последним. Он необходим, поскольку данные можно шифровать по кускам, но для последнего блока всегда выполняется определенная деинициализация алгоритма (освобождаются внутренние структуры), и многие алгоритмы производят добавление (и проверку корректности при дешифровании) заполнителя (padding) после основных данных. Параметры pbData и pdwDataLen задают адрес буфера и размер шифруемых данных. Для не последнего блока данных (Final=FALSE) размер данных должен быть всегда кратен размеру шифруемого алгоритмом блока (для 3DES и DES этот размер равен 64 битам). Для последнего блока допускается нарушение этого условия.

ПРИМЕЧАНИЕ Заметим, что зашифрованные данные помещаются в тот же самый буфер поверх исходных.

Последний параметр функции CryptEncrypt – dwBufLen может показаться странным. Зачем нам размер буфера, если мы и так знаем размер входных данных? Однако на самом деле он необходим. Как я уже упомянул, многие алгоритмы добавляют заполнитель в последний блок после основных данных. В этом случае размер зашифрованных данных может оказаться больше, чем размер исходных данных. И результат может попросту не вместиться в буфер! Поэтому стоит заранее указать размер буфера, превышающий максимальный размер помещаемых в него открытых данных. Для DES и 3DES максимально возможный довесок составляет 64 бита, т.е. 8 байт (это я установил опытным путем).

В качестве примера шифрования приведу выдержку из демонстрационного проекта encfile:

BYTE buf[BUFFER_SIZE+8]; //8 - запас на padding
while(fSize)
{
    if(!::ReadFile(hInFile,buf,BUFFER_SIZE,&dwLen,NULL)) //читаем блок данных
        break;
    dwSzLow=dwLen;
    //шифруем    и хешируем его <
    /font>
    if(!::CryptEncrypt(hKey,hHash,fSize<=BUFFER_SIZE,0,buf,&dwSzLow,sizeof(buf))) 
    break;
    if(!::WriteFile(hOutFile,buf,dwSzLow,&dwSzLow,NULL))
        break;
    fSize-=dwLen;
}

CryptHashData(hHash,(BYTE *)&data,dwLen,0);

CryptGetHashParam(hHash,HP_HASHVAL,(BYTE *)&buf,&dwLen,0);

HCRYPTHASH hHash;
::CryptCreateHash(hProv,CALG_MD5,0,0,&hHash);
::CryptHashData(hHash,(BYTE *)&data,dwLen,0);
BYTE newHash[16];
dwLen=16;
::CryptGetHashParam(hHash,HP_HASHVAL,newHash,&dwLen,0);
if(!memcmp(newHash,oldHash,16))
{
    //хеш верен
}
else
{
    //хеш не верен
}
::CryptDestroyHash(hHash);

 //Вычисление подписи
::CryptSignHash(hHash,AT_SIGNATURE,NULL,0,buf,&dwLen);
// Проверка подписи
if(::CryptVerifySignature(hHash,buf,1024/8,hPubKey,NULL,0))
{
  // Верная подпись
}
else
{
  // Неверная подпись или хеш
}
Размер подписи равняется размеру ключа RSA или DSS, соответственно.

private SymmetricAlgorithm alg;

alg=(SymmetricAlgorithm)RijndaelManaged.Create(); //пример создания класса RijndaelManaged




//класс, позволяющий генерировать ключи на базе паролей
PasswordDeriveBytes pdb=new PasswordDeriveBytes(Password.Text,null); 
pdb.HashName="SHA512"; //будем использовать SHA512
int keylen=(int)KeySize.SelectedItem; //получаем размер ключа из ComboBox’а
alg.KeySize=keylen; //устанавливаем размер ключа
alg.Key=pdb.GetBytes(keylen>>3); //получаем ключ из пароля
alg.Mode=CipherMode.CBC; //используем режим CBC
alg.IV=new Byte[alg.BlockSize>>3]; //и пустой инициализационный вектор
ICryptoTransform tr=alg.CreateEncryptor(); //создаем encryptor

FileStream instream=new FileStream(inFile.Text,FileMode.Open,
 FileAccess.Read,FileShare.Read);
FileStream outstream=new FileStream(outFile.Text,FileMode.Create,
 FileAccess.Write,FileShare.None);
int buflen=((2<<16)/alg.BlockSize)*alg.BlockSize;
byte []inbuf=new byte[buflen];
byte []outbuf=new byte[buflen];
int len;
while((len=instream.Read(inbuf,0,buflen))==buflen)
{
    int enclen=tr.TransformBlock(inbuf,0,buflen,outbuf,0); //собственно шифруем
    outstream.Write(outbuf,0,enclen);
}
instream.Close();
outbuf=tr.TransformFinalBlock(inbuf,0,len); //шифруем финальный блок
outstream.Write(outbuf,0,outbuf.Length);
outstream.Close();
alg.Clear(); //осуществляем зачистку

//генерация ключей: новый ключ генерируется автоматически при создании экземпляра класса
RSACryptoServiceProvider rsa=new RSACryptoServiceProvider(1024); //1024-битный ключ

//Экспорт ключа
RSAParameters rp=rsa.ExportParameters(true); //экспорт закрытого ключа. 
//Для открытого нужно передавать false

//Импорт ключа
rsa.ImportParameters(rp); //будьте внимательны. Этот вызов портит значение rp

//шифрование блока

byte []enc=rsa.Encrypt(buf,true); //шифрование RSA/OAEP

//дешифрование блока
rsa.Decrypt(enc,true); //дешифрация RSA/OAEP

//создание цифровой подписи RSA
AsymmetricSignatureFormatter sf;
sf=(AsymmetricSignatureFormatter)new RSAPKCS1SignatureFormatter(rsa); //создаем форматер
sf.SetHashAlgorithm("MD5"); //выбираем алгоритм хеширования
sig=sf.CreateSignature(Hash); //создаем подпись (хеш должен быть уже посчитан ранее)

//проверка цифровой подписи RSA
AsymmetricSignatureDeformatter df;
//создаем деформатер
df=(AsymmetricSignatureDeformatter)new RSAPKCS1SignatureDeformatter(rsa); 

df.SetHashAlgorithm("MD5");
if(df.VerifySignature(Hash,sig)) //проверяем подпись
{
    //подпись верна
}
else
{
    //подпись неверна
}

RSACryptoServiceProvider rsa1=new RSACryptoServiceProvider(1024); //получатель ключа
RSAParameters rp=rsa1.ExportParameters(false);
Console.WriteLine("Passing public key to sender...");
//передаем открытый ключ отправителю
//.

RSACryptoServiceProvider rsa2=new RSACryptoServiceProvider(1024); //отправитель ключа
Console.WriteLine("Importing receiver's public key...");
//импортируем открытый ключ получателя
rsa2.ImportParameters(rp);
AsymmetricKeyExchangeFormatter kf=

 (AsymmetricKeyExchangeFormatter)new RSAOAEPKeyExchangeFormatter(rsa2);
byte []key=new Byte[16]; //128-битный ключ
byte []enckey=kf.CreateKeyExchange(key);
Console.WriteLine("Sending encrypted session key to receiver...");
//передаем зашифрованный сессионный ключ получателю
//.

AsymmetricKeyExchangeDeformatter kd =

 (AsymmetricKeyExchangeDeformatter)new RSAOAEPKeyExchangeDeformatter(rsa1);

//Расшифровываем ключ

byte []deckey=kd.DecryptKeyExchange(enckey);
for(uint i=0;i<16;i++)
if(deckey[i]!=key[i])
{
    Console.WriteLine("Key exchange failed");
    return;
}
Console.WriteLine("Key exchange succeeded");

HashAlgorithm ha=(HashAlgorithm)new MD5CryptoServiceProvider();
byte []hash=md5.ComputeHash(data,0,data.Length); //считаем хеш

ha=(HashAlgorithm)new SHA1CryptoServiceProvider();
//читаем файл поблочно 



while((len=ins.Read(inbuf,0,MaxRSABlockSize))==MaxRSABlockSize) 
{
    ha.TransformBlock(inbuf,0,MaxRSABlockSize,outbuf,0); //считаем хеш от блока данных
}
byte []hash=ha.TransformFinalBlock(inbuf,0,len); //досчитываем хеш от последнего куска