Re[7]: шифрование RC4 - WIN API

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

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

Топикстартер упоминал 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. Предлагаю прекратить непродуктивную эксплуатацию клавиатуры.
Начну с себя.

	От:	Glenn
	Дата:	22.08.11 20:12
	Оценка:

От:	okman	https://searchinform.ru/
Дата:	22.08.11 21:06
Оценка:

	От:	Glenn
	Дата:	23.08.11 09:17
	Оценка:

От:	okman	https://searchinform.ru/
Дата:	23.08.11 10:58
Оценка:

От:	Pzz	https://github.com/alexpevzner
Дата:	23.08.11 23:49
Оценка:	+1