В http://msdn.microsoft.com/en-us/library/cc236692(v=PROT.10).aspx (это алгоритм NTLM) упоминается шифрование RC4K.
Знает ли кто — как это (именно это — RC4) шифрование реализовать через CryptoAPI?

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

G>В http://msdn.microsoft.com/en-us/library/cc236692(v=PROT.10).aspx (это алгоритм NTLM) упоминается шифрование RC4K.
G>Знает ли кто — как это (именно это — RC4) шифрование реализовать через CryptoAPI?

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

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

G>В http://msdn.microsoft.com/en-us/library/cc236692(v=PROT.10).aspx (это алгоритм NTLM) упоминается шифрование RC4K.
G>Знает ли кто — как это (именно это — RC4) шифрование реализовать через CryptoAPI?

“CryptoAPI можно исполь�s
���D0�ть, но замучаетесь возиться с провайдерами и криптоконтейнерами” – хорошо, допустим я решил помучиться Мне (по условиям задачи) надо сделать нечто такое:

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

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

Здравствуйте, 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++, там есть реализация
этого алгоритма с более простым интерфейсом.

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

G>В http://msdn.microsoft.com/en-us/library/cc236692(v=PROT.10).aspx (это алгоритм NTLM) упоминается шифрование RC4K.
G>Знает ли кто — как это (именно это — RC4) шифрование реализовать через CryptoAPI?

Вообще-то, вся реализация RC4 — это меньше сотни строк. Стоит ли ради этого с CryptoAPI заморачиваться?

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

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

G>>В http://msdn.microsoft.com/en-us/library/cc236692(v=PROT.10).aspx (это алгоритм NTLM) упоминается шифрование RC4K.
G>>Знает ли кто — как это (именно это — RC4) шифрование реализовать через CryptoAPI?

Pzz>Вообще-то, вся реализация RC4 — это меньше сотни строк. Стоит ли ради этого с CryptoAPI заморачиваться?

А с использованием CryptoApi всё шифрование — 5 строк.

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

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

ЕМНИП, что-то Вы путаете, админские права не требуются. Всё, что нужно, работает под ограниченным юзером. Да и пара ключей нужна одна, и то если требуется обмен сессионным ключом. А в качестве сессионного используют симметричный ключ, иначе смысла нет.

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

ИМХО, интерфейс CryptoApi вполне прост.

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

JR>ЕМНИП, что-то Вы путаете, админские права не требуются. Всё, что нужно, работает под ограниченным юзером. Да и пара ключей нужна одна, и то если требуется обмен сессионным ключом. А в качестве сессионного используют симметричный ключ, иначе смысла нет.

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

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

JR>ИМХО, интерфейс CryptoApi вполне прост.

В целом — да. Но иногда палка перегибается. Например, можно было сделать вычисление хэшей MD/SHA без
задействования криптопровайдеров.

А теперь конкретный ответ на конкретный вопрос топикстартера, коего от местных знатоков мы не дождались:

BOOLEAN DoRC4Crypt(const unsigned char *key, DWORD key_length, const unsigned *plaintext, DWORD plaintext_length, unsigned *encrypted_text)
{
    HCRYPTPROV hProv;
    HCRYPTKEY hKey;
    struct {
        BLOBHEADER hdr;
        DWORD cbKeySize;
        BYTE  rgbKeyData[128 / 8]; // 128bit - maximum key length
    } keyBlob;
    BOOLEAN bRet = FALSE;
    DWORD dwLen;

    if (key_length < 40/8 || key_length > 128/8) return FALSE;
    if (!CryptAcquireContext(&hProv, NULL, NULL, PROV_RSA_FULL, CRYPT_VERIFYCONTEXT)) return FALSE;
    
    keyBlob.hdr.bType = PLAINTEXTKEYBLOB;
    keyBlob.hdr.bVersion = CUR_BLOB_VERSION;
    keyBlob.hdr.reserved = 0;
    keyBlob.hdr.aiKeyAlg = CALG_RC4;
    keyBlob.cbKeySize = key_length;
    CopyMemory(keyBlob.rgbKeyData, key, key_length);

    if (CryptImportKey(hProv, (BYTE *)&keyBlob, sizeof(keyBlob), 0, 0, &hKey))
    {
        CopyMemory(encrypted_text, plaintext, plaintext_length);
        dwLen = plaintext_length;
        bRet = CryptEncrypt(hKey, 0, TRUE, 0, (BYTE *)encrypted_text, &dwLen, plaintext_length);
        CryptDestroyKey(hKey);
    }
    SecureZeroMemory(keyBlob.rgbKeyData, sizeof(keyBlob.rgbKeyData));
    CryptReleaseContext(hProv, 0);
    return bRet;
}

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

Gorilla написал:

G>А теперь конкретный ответ на конкретный вопрос топикстартера, коего от местных знатоков мы не дождались:
G>

G>...
G>

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

Ключ передается в функцию в открытом виде. Блестящая криптография !
Ты сначала разберись как следует в безопасности, а потом пиши в эти нелюбимые русские форумы.

Здравствуйте, Gorilla.

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

Если не использовать возможности работы с криптоконтейнерами, то смысла использовать
CryptoAPI в том виде, в котором тут предлагали, нет.

Уважаемый okman, попытайтесь выработать в себе умение отвечать на заданный вопрос, а не растекаться мыслью по дереву. Топикстартер просил шифрование rc4 на CryptoAPI под заданную "рыбу" прототипа функции. В этом топике никто не просил абстрактных лекций на тему как надо использовать CryptoAPI или как хранить и применять ключи. Вопрос был как сделать конкретное действие, и я полагаю что другие сопутствующие вопросы топикстартер способен сам решить или задать их на форуме.
Я не люблю русские форумы именно из-за таких людей как вы. Вы дали ровно ноль полезной информации, при этом успели порассуждать о знании/незнании безопасности и надавать кучу непрошенных советов, вынуждая этим отвечать на ваши сообщения и вступать с вами в полемику, которая мне нафиг не сдалась. Вы просто отнимаете у людей время. Если нечего сказать — лучше стоит промолчать.
За сим откланиваюсь.

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

O>Здравствуйте, Jolly Roger, Вы писали:

JR>>ЕМНИП, что-то Вы путаете, админские права не требуются. Всё, что нужно, работает под ограниченным юзером. Да и пара ключей нужна одна, и то если требуется обмен сессионным ключом. А в качестве сессионного используют симметричный ключ, иначе смысла нет.

O>Админские права требуются для определенного уровня доступа к криптоконтейнеру, хранящему ключ.

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

O>Если данные шифруются на одной машине, а дешифруются на другой, ключ подлежит транспортировке.
O>Само собой, что в CryptoAPI его нельзя "просто" взять и напрямую записать его в файл — придется
O>выполнить несколько операций, которые начинающему разбираться с CryptoAPI не покажутся очевидными.

Ну, начинающий — пока не пробовал. За пару (ну тройку) часов вполне можно разобраться. "Лучше пол-дня потерять, потом за пять минут долететь"(с)

O>Вот тут и начинается код, отнюдь не пять строчек.

Хм, CryptExportKey, это и делает Ну не в файл — в блоб, какая разница С импортом кдюча и закрытием хёндлов и будет 5-6 строк, с открытием-чтением файла — 10

O>В целом — да. Но иногда палка перегибается. Например, можно было сделать вычисление хэшей MD/SHA без
O>задействования криптопровайдеров.

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

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

G>Уважаемый okman, попытайтесь выработать в себе умение отвечать на заданный вопрос, а не растекаться мыслью по дереву. Топикстартер просил шифрование rc4 на CryptoAPI под заданную "рыбу" прототипа функции. В этом топике никто не просил абстрактных лекций на тему как надо использовать CryptoAPI или как хранить и применять ключи. Вопрос был как сделать конкретное действие, и я полагаю что другие сопутствующие вопросы топикстартер способен сам решить или задать их на форуме.
G>Я не люблю русские форумы именно из-за таких людей как вы. Вы дали ровно ноль полезной информации, при этом успели порассуждать о знании/незнании безопасности и надавать кучу непрошенных советов, вынуждая этим отвечать на ваши сообщения и вступать с вами в полемику, которая мне нафиг не сдалась. Вы просто отнимаете у людей время. Если нечего сказать — лучше стоит промолчать.

здесь

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

G>Уважаемый okman, попытайтесь выработать в себе умение отвечать на заданный вопрос, а не растекаться мыслью по дереву. Топикстартер просил шифрование rc4 на CryptoAPI под заданную "рыбу" прототипа функции. В этом топике никто не просил абстрактных лекций на тему как надо использовать CryptoAPI или как хранить и применять ключи. Вопрос был как сделать конкретное действие, и я полагаю что другие сопутствующие вопросы топикстартер способен сам решить или задать их на форуме.

То есть, на вопрос "как забить гвоздь микроскопом", я должен был ответить что-то типа "возьми гвоздь в
левую руку, микроскоп в правую, и заколачивай его с размаху" ?

Топикстартер упоминал RC4 в контексте NTLM. Что это такое и для чего — думаю, объяснять не нужно.
Если Вы считаете, что гонять ключи в открытую в собственной реализации NTLM вполне нормально, то
это Ваше право. Кстати, я никого дураком не обзывал и не считал, а первый укор в профессиональной
квалификации был с Вашей стороны.

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

Во-первых, я сразу предупредил, что в CryptoAPI тривиальные на первый взгляд вещи могут
достигаться неочевидными способами, которые потом будут иметь внезапные последствие.
Например, программа может вылететь внезапно на свежеустановленной ОС, потому что в ней не
был создан дефолтный контейнер, а текущая учетка такой операции делать не разрешает.
Зачем мне откупаться простыми ответами, если я почти уверен, что ТС пойдет тем же
путем, что и я когда-то, а потом наступит на те же грабли и набъет те же шишки ?

Во-вторых, я указал на Crypto++, как вариант (см. ARC4).
Если дополнительные возможности CryptoAPI не нужны.

Зато Вы одним сообщением дали типичный пример vulnerability-кода и обосрали русские форумы.

G>За сим откланиваюсь.

Да как угодно, мне эта полемика тоже поперек горла.

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

O>>Админские права требуются для определенного уровня доступа к криптоконтейнеру, хранящему ключ.

JR>Какие, например? Может, конечно, я чего забыл, но вроде как для обычной работы никаких особых прав не требуется Разумеется, к чужому контейнеру так просто доступ не получишь, но это скорее плюс

Была ситуация — в одной программе использовался Microsoft Base Cryptographic Provider для вычисления MD-5,
причем то ли по незнанию, то ли по ошибке, CryptAcquireContext создавал дефолтный контейнер.
Все работало несколько месяцев исправно, затем программу запустили на только что установленной
Windows XP, и CryptAcquireContext вернул ошибку, так как дефолтный контейнер до этого еще никем не
создавался, а прав (программа запускалась под учеткой "Гость") для его создания не было.

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

O>>Вот тут и начинается код, отнюдь не пять строчек.

JR>Хм, CryptExportKey, это и делает Ну не в файл — в блоб, какая разница С импортом кдюча и закрытием хёндлов и будет 5-6 строк, с открытием-чтением файла — 10

А ты попробуй (см. второй параметр в CryptExportKey, если думать о безопасном транспорте) — узнаешь

JR>Ну тут как посмотреть, с одной стороны — вроде да, несколько лишних действий. С другой — действий-то чуть, зато унифицированный доступ к разным алгоритмам и разным их реализациям, единый интерфейс для разработчиков криптопровайдеров, что позволяет одним кодом работать с разными поставщиками. В этом тоже есть свои плюсы, ИМХО.

Единственный плюс стандарных криптопровайдеров, если рассматривать это в плоскости MD-5/SHA-1, это то,
что они работают очень быстро. Сам замерял. Было несколько сторонних библиотек, включая Crypto++ и
собственные реализации — CryptHashData на первом месте.

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

O>А ты попробуй (см. второй параметр в CryptExportKey, если думать о безопасном транспорте) — узнаешь

Да я как-бы пробовал...когда-то

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

JR>А с использованием CryptoApi всё шифрование — 5 строк.

Угу. Только чтобы написать их, надо неделью MSDN читать. А реализацию RC4 можно найти за 5 минут

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

O>Во-первых, я сразу предупредил, что в CryptoAPI тривиальные на первый взгляд вещи могут
O>достигаться неочевидными способами, которые потом будут иметь внезапные последствие.
Мой пример 100% рабочий без всяких внезапных последствий, все последствия и ограничения описаны в MSDN. Зуб даю.

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

O>Зачем мне откупаться простыми ответами, если я почти уверен, что ТС пойдет тем же
O>путем, что и я когда-то, а потом наступит на те же грабли и набъет те же шишки ?
Судя по вашим ответам рискну заявить что вы знаете CryptoAPI постольку-поскольку, но пытаетесь всех учить. Попробуйте меньше говорить и больше делать, тогда вас воспримут серьезней.

O>Зато Вы одним сообщением дали типичный пример vulnerability-кода
А это уже вызов моей профессиональной гордости! Извините за выражение, но вы готовы ответить за базар? Разжуйте пожалуйста где тут vulnerability. Этот код делает то что требовлось — шифрует данные алгоритмом RC4, при этом создаваемые копии ключей корректно затираются (CryptDestroyKey, SecureZeroMemory), как и положено в нормальной криптобиблиотеке. Переполнений буфера и утечек данных здесь не может быть, код для этого слишком прост. Единственное место где может быть уязвимость, это сам CryptoAPI.
Полагаю что вы считаете передачу ключа в функцию шифрования за уязвимость, но тогда мне придется усомниться не только в вашей квалификации, но и в умственных способностях.

O> и обосрали русские форумы.
Печально, но русские форумы не идеальны, пока на них есть такие как вы.

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

G>Судя по вашим ответам рискну заявить что вы знаете CryptoAPI постольку-поскольку, но пытаетесь всех учить.
G>Попробуйте меньше говорить и больше делать, тогда вас воспримут серьезней.

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

G>В моем примере никакой контейнер не используется и не создается. Ваши слова опять мимо.
И зря (см. ниже).

O>>Зато Вы одним сообщением дали типичный пример vulnerability-кода
G>А это уже вызов моей профессиональной гордости! Извините за выражение, но вы готовы ответить за базар? Разжуйте пожалуйста где тут vulnerability. Этот код делает то что требовлось — шифрует данные алгоритмом RC4, при этом создаваемые копии ключей корректно затираются (CryptDestroyKey, SecureZeroMemory), как и положено в нормальной криптобиблиотеке. Переполнений буфера и утечек данных здесь не может быть, код для этого слишком прост. Единственное место где может быть уязвимость, это сам CryptoAPI.
G>Полагаю что вы считаете передачу ключа в функцию шифрования за уязвимость, но тогда мне придется усомниться не только в вашей квалификации, но и в умственных способностях.

Сомневайтесь. Отвечаю за базар.

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

Кроме того, зловредное ПО может поставить хук на функцию и узнать ключ.
Это два.

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

O>> и обосрали русские форумы.
G>Печально, но русские форумы не идеальны, пока на них есть такие как вы.

Вы посмотрите историю моих сообщений, если я Вам так уж неприятен — может быть поймете,
что такие как я тут делают.

P.S. Предлагаю прекратить непродуктивную эксплуатацию клавиатуры.
Начну с себя.

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

JR>Ну тут как посмотреть, с одной стороны — вроде да, несколько лишних действий. С другой — действий-то чуть, зато унифицированный доступ к разным алгоритмам и разным их реализациям, единый интерфейс для разработчиков криптопровайдеров, что позволяет одним кодом работать с разными поставщиками. В этом тоже есть свои плюсы, ИМХО.
Из довольно интенсивного опыта использования криптографии могу сказать что CryptoAPI всё таки изрядно неудобен.

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

O>Уязвимость именно в том, что при такой реализации Вам придется хранить ключ где-то снаружи.
O>В файлах, реестре, "вшить" в программу, и т.п. Это значит, что его можно будет относительно
O>несложно узнать или, если он зашифрован, подвергнуть криптоанализу.
O>Это раз.
А еще ключ можно нигде не хранить и вводить с клавиатуры, получать со смарткарты через стороннюю библиотеку, и.т.п. Все зависит от того как именно использовать. Так что ваши слова о уязвимости в МОЕМ коде — как всегда мимо. Если не согласны — срочно пишите в багтрак об уязвимостях в OpenSSL, Crypto++ и большинстве других криптобиблиотек. Там хоть посмеются.

O>Кроме того, зловредное ПО может поставить хук на функцию и узнать ключ.
O>Это два.
А еще злоумышленник может засунуть паяльник в задницу пользователю и узнать ключ, а если не ключ, то данные. О ужас, все криптобиблиотеки уязвимы!! Раз у вас отсутствует систематическое мышление, то намекну: каждый класс атак требует своей, специфичной защиты. От переполнений буфера, утечек копий ключа в памяти, ошибок в реализации и.т.п. вещей дожна защищать криптобиблиотека. Хранение ключа в реестре, программе или передача в открытую по сети — проблема конкретного протокола или приложения. От зловредного ПО должен защищать антивирус, а от паяльника — милиция.

O>P.S. Предлагаю прекратить непродуктивную эксплуатацию клавиатуры.
O>Начну с себя.
Молодец, исправляетесь...

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

G>А еще ключ можно нигде не хранить и вводить с клавиатуры, получать со смарткарты через стороннюю библиотеку, и.т.п. Все зависит от того как именно использовать. Так что ваши слова о уязвимости в МОЕМ коде — как всегда мимо. Если не согласны — срочно пишите в багтрак об уязвимостях в OpenSSL, Crypto++ и большинстве других криптобиблиотек. Там хоть посмеются.

Напомню — речь шла о реализации NTLM (см. самое первое сообщение). Здесь важны любые детали.
ТВОЙ код содержит реальную уязвимость в этом контексте, потому что ключ передается в
открытом виде и не задействованы возможности CryptoAPI, предоставляющие более надежное хранилище.
Загляни ради интереса в Windows SSPI и посмотри как протокол NTLM управляется этим API.
Между прочим, ни OpenSSL, ни Crypto++ не заявляли о полноценной поддержке NTLM.

G>А еще злоумышленник может засунуть паяльник в задницу...

А еще разработку концепции защиты можно доверить какому-нибудь дилетанту.

O>>P.S. Предлагаю прекратить непродуктивную эксплуатацию клавиатуры.
O>>Начну с себя.
G>Молодец, исправляетесь...

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

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

O>Была ситуация — в одной программе использовался Microsoft Base Cryptographic Provider для вычисления MD-5,
O>причем то ли по незнанию, то ли по ошибке, CryptAcquireContext создавал дефолтный контейнер.

не совсем понятно, зачем нужен контейнер для md5?

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

вот в том то и дело, что автор изначально спросил про rc4 — симметричный алгоритм. А вы в двух словах рассказали про сложность работы шифрования с открытым-закрытым ключом.
Даже прототип функции привел. Оно конечно хорошо, что вы попытались вразумить человеку, как нужно сделать все остальное помимо данной функции, чтобы реализация была безопасной, но... от этого легче не становится, во-первых если найдется другая библиотека (кроме cryptoAPI), использовать ее будет совсем не легче для нормальной реализации, а во-вторых, вы просто запутаете таким образом человека, потому что спрашивал он действительно про другое.