Здравствуйте, Glenn, Вы писали:

G>Здравствуйте, Glenn, Вы писали:
G>>Мне (по условиям задачи) надо сделать нечто такое:

G>DoRC4Crypt(const unsigned char *key,
G>Size_t key_length,
G> const unsigned *plaintext,
G> size_t plaintext_length,
G> const unsigned *encrypted_text);

G>Причём я сам не до конца понимаю смысл этих параметров (у меня есть ‘рыба’ функции, тело которой я должен написать; а спросить некого). Понятно, что такое plaintext, plaintext_length и encrypted_text. Но что такое — в применении к CryptoAPI – key? Это – готовый ключ который можно заимпортировать через CryptImportKey и результат импорта подавать на функцию CryptEncrypt? Или это – нечто из чего надо сделать ключ посредством CryptDeriveKey и результат подавать на функцию CryptEncrypt?

В том-то и дело, что функции CryptoAPI — это не Blowfish, тут недостаточно взять и
просто закриптовать строку определенным ключом и вернуть клиенту.
Сначала нужно будет получить HANDLE криптопровайдера (в Вашем случае, скорее всего,
Microsoft Enhanced Cryptographic Provider), затем получить доступ к криптоконтейнеру или
создать новый, потом две пары ключей — одна экспортируемая для обмена, другая приватная
для шифрования, затем нужно будет еще разобраться, какая максимально допустимая длина
ключа на установленной версии Windows, и т.д. Причем большую часть описанного можно
"провернуть" только если есть администраторские или системные права.
Только после этого можно работать с ключами и что-то шифровать (всех тонкостей не упомню,
работал последний раз на уровне CryptoAPI года полтора назад).
Поэтому сигнатуру функции, которую Вы привели, можно трактовать по-разному.

Говорю же — нет смысла ввязываться в бои с CryptoAPI, если только это не обусловлено
необходимостью надежного хранения криптоключей. Возьмите Crypto++, там есть реализация
этого алгоритма с более простым интерфейсом.