Crypto API и многопоточность

← →
Eraser © (2006-03-27 22:42) [0]

Ещё один вопрос по крипто-API.
Потокобезопасно ли CryptoAPI, т.е. можно ли, без угрозы возниконовения ошибок, одновременно шифровать/дешифровать данные в нескольких потоках, одним и тем же ключем без защиты критическими секциями или объектами ядра?

В инете и MSDN внятного ответа на этот вопрос не нашёл.

Спасибо.

← →
Polevi © (2006-03-28 09:22) [1]

я бы не стал

← →
Reindeer Moss Eater © (2006-03-28 09:26) [2]

Было бы странным, если бы реализации провайдеров были потоконебезопастными.

одним и тем же ключем без защиты ...
У программиста, использующего cryptoapi, доступа непосредственно к приватному ключу никогда не будет. Поэтому использование объектов синхронизации никак не может повлиять на процесс.

А вообще что мешает делать CrytptAcquireConetx в каждом своем потоке?

← →
Eraser © (2006-03-28 15:31) [3]

понятно, буду проверять на практике )

> А вообще что мешает делать CrytptAcquireConetx в каждом
> своем потоке?

алгоритм работы программы... каждый раз аутентифицироваться и авторизовываться не годится. Можно конечно каждый раз импорировать сохранённый session key... но уж очень не желательно его сохранять.

← →
Reindeer Moss Eater © (2006-03-28 15:39) [4]

Не понял.
Во вторичных потоках пользовательский интерфейс живет что ли?
Что значит "каждый раз аутентифицироваться и авторизовываться" ?

← →
Eraser © (2006-03-28 15:53) [5]

> Reindeer Moss Eater © (28.03.06 15:39) [4]

не.. пользовательского интерфеса там вообще нету ))
схема такая, клиент аутентифицируется/авторизуется, на сервере создаётся некий "контекст" (объект) соединения с информацией о клиенте. После успешной аутенификации соединение отключается, поток аутентификации завершает свою работу, но "контекст" остаётся, в этом "контексте" хранится дескриптор ключа шифрования, который был сгенерирован при аутентификации, к примеру, по алгоритму Diffie-Hellman"a.

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

Надеюсь не сильно сумбурно выразился ))

А почему бы не работать "этажом выше", используя клиентский сертификат и мессаджи? Не генерируя сессионный ключ руками.

> Reindeer Moss Eater © (28.03.06 16:11) [6]

да итак я через чур высоко забрался...тут в основном 2 фактора мешают:
1. всё портит необходимость совместимости с win9x (обязательное условие) с приемлемой криптозащитой... а 40 битный CALG_RC4 это смешно.. вдруг и правда кому то взбредёт в голову сломать.. и сломают же ведь, поэтому надо предусмотреть "свой" алгоритм (без CryptoAPI) специально для 9x, например 512 RSA + 128 AES ... или Blowfish.
2. Необходима высокая производительность. Думаю мессаджи её не обеспечат.

Crypto API и многопоточность Найти похожие ветки