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