>>657425
На ставке 4к$, у которого есть все кроме мозгов

>>657425
так его!

>>657410 (OP)
пиши фейкомыло - проконсультирую за 2к рублей
дома жрать нечего, лол

>>657425>>657430
К сожалению, вы не угадали.

>>657430
не завидуй, нищеброд

>>657425
Успешные люди не сидят на дваче же

>>657461
Но стиль изложения характерный же. Невнятная постановка задачи типа "угадай что мне нужно", зато по-деловому поставлен план работ:
>нужен >-< подробный алгоритм
>последовательно разбирать все шаги в подробностях, чтобы не пришлось писать огромный пост со всем алгоритмом, по которому потом возникнет такой же огромный пост с вопросами

>>657483
Да я вроде понятно объяснил-то, что в общих чертах понимаю процесс и что интересует, но в тонкостях реализации — каша получается. Описывать привык всё детально, чтобы лишних вопросов не возникало; старался ничего не упустить.
А как тогда надо было бы написать?

>>657502
Да никак, чувак. Самому надо разбираться. Тут у тебя нетривиальная задача, и ты фактически просишь все за тебя сделать, ну разве что код ты под диктовку сам запишешь.

>>657509
Ну вообще-то нет. А что в задаче нетривиального? Как бы понимающие люди (которые пока не я) без проблем смогут рассказать про корректную последовательность операций шифрования, а уж конкретика реализации (например, с какими ключами я буду это делать) — уже другой вопрос. Ясен перец, программу за меня я просить никого не буду написать, но без понимания всей сути этого не сделать.
У меня просто даже идей нет, как всё это совместить, потому как практики 0. То есть инициализировать криптопровайдер я умею, ключи генерировать — тоже, а дальше — тёмный лес.

>>657410 (OP)
пиши фейкомыло - проконсультирую за 10к рублей
дома винт наебнулся, лол

>>657437>>657569
Многовато чёт, да и не надо мне за деньги
И фейкомыла нет

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

>>658221
>CryptoAPI
оно не секурно для тех целей, что ты ставишь

это была демо-версия консультации, далее - фейкомыло и 2к

>>658291
Чому несекурно?
Это какой-то новый тренд на дваче — писать таким образом про деньги? Просто давно не бывал, а здесь зашёл, и вдруг такое.

>>658364
если пека под твоим контролем, то секурно.

>>658291
я его консультирую за 10, а тебе 2к, так отъебешся? ок?

> шифруются закрытым ключом A
Это и есть подпись.
> CryptoAPI
Не знаю.

>>658919
>если пека под твоим контролем, то секурно.

если пека 100% под твоим контролем то и смарткарта не нужна. если же ты не уверен насчёт подконтрольности пека то схема не взлетает

делим так: мне 8к, тебе 2к

>>658364>>659258
Целевой пека не под моим, для того и нужна смарт-карта.

Такой вопрос: генерирую я асимметричные ключи с помощью CryptGenKey, передавая туда AT_KEYEXCHANGE или AT_SIGNATURE. Да, я понимаю, что AT_KEYEXCHANGE может также и для подписи использоваться, но если абстрагироваться от этого, то какая между ними разница? (0)
Далее, если я хочу на будущее сохранить оба ключа, то мне надо, во-первых, сгенерировать оба (ибо процесс генерации одного независим от другого) и по отдельности экспортировать? (1)

>>658978
>> шифруются закрытым ключом A
>Это и есть подпись.
сначала берется хеш от данных, а хеш уже шифруется закрытым ключом, это будет подпись
делается это для того, чтобы ускорить операцию - ассимметричное шифрование затратная операция

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

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

>А можно ли будет вообще извлечь закрытый ключ или как-то заставить данные расшифроваться посредством смарт-карты, не отходя от CryptoAPI? Я нарыл CryptAcquireCertificatePrivateKey, но из её описания непонятно — вдруг она на другой машине уже не сможет отдать приватный ключ, потому что "can only be used by the owner of a private key and not by any other user".
повторюсь, ты, похоже не понимаешь самого смысла аппаратного решения - оно на то и надо, чтобы сохранить приватность закрытого ключа на условно небезопасных машинах
а обеспечивается это тем, что собственно, операции по дешифрованию или формированию цифровой подписи будут происходить на самом устройстве где и хранится закрытый ключ, а cryptoapi (либо какое-то другое стороннее криптографическое решение) будет всего лишь передавать туда нужные данные и получать их расшифрованными или подписаными
таким образом что получается: что условный злоумышленник, получив управление машиной, сможет таки выполнять какое-то время криптографические операции используя закрытый ключ, но не сможет получить сам закрытый ключ
все ОЧЕ просто

>>657502
>что в общих чертах понимаю процесс
нет, судя по твоему посту ты НИХУЯ не понимаешь еще в теме, не обманывай себя

>>657509
>Тут у тебя нетривиальная задача
ага, заключающаяся в вызове двух стандартных функций из cryptoapi -
отправить на расшифровку на смарт карту где лежит закрытый ключ
проверить цифровую подпись открытым ключом, лежащим на компе

Начну наоборот
>>661110
Да, чувак, ты прав!
И смысл аппаратного решения я таки понимаю — чтобы закрытый ключ не извлекли из защищённых контейнеров с целевого компа (ибо они не такие уж и защищённые), процедуры работы с закрытым ключом делаются в самом устройстве. В ближайшее время накидаю простейший шифратор-дешифратор; надеюсь, взлетит (но у меня ни хрена не взлетит, конечно же, кого я обманываю)
>>661101
>тебя, как прикладного программиста, всего лишь использующего api, не должны волновать такие вопросы
Как я понял из описания процесса, сессионный ключ сам себя не сгенерирует, и не педераст передаст себя в зашифрованном виде тоже.
>>661087
>"сертификат" же это обычно просто такой контейнер (по сути, файл), где могут лежать либо открытый, либо закрытый ключ, либо оба вместе
Видимо, я очень плохо прочитал раздел про сертификаты, потому что думал, что там только открытый ключ хранится (ну и плюс данные по самому сертификату). Типа потому что закрытый хранить несекурно же.

Кстати, спасибо за ответы. Кое-что стало более понятно, чем после чтения MSDN'а на эту тему.

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

>>661126
Скорее, даже не в браузере, а в хранилище системы — ведь эти сертификаты не ему одному могут быть нужны. Браузер-то оттуда берёт, насколько мне известно (взять хотя бы IE и Chrome-based браузеры).
Но мне сертификаты нужны постольку-поскольку; для реализации моего двойного шифрования они необязательны же?
Кстати, до этого думал, а не забить ли мне данные просто в сертификат и использовать их уже, но потом чёт отдумался от этой мысли. Вдруг можно и без работы с сертификатами обойтись.

P.S. В прошлый раз забыл подписаться, да. Но оно и так понятно вроде.
А на дваче, по ходу, криптуют только единицы.

>>661133
cryptoapi - это ж в первую очередь стандартизирующий промежуточный слой от майкрософт
дык и я не очень понимаю, через какой криптопровайдер ты собираешься работать? какой то сторонний (возможно наших русских разрабов с русскими алгоритмами) либо один из предлагаемых майкрософт? какой из криптопровайдеров поддерживат твое аппаратное решение

>>661152
Ну я смотрел всякие CryptoPro, например. Конкретного на примете нет, но отвечая на твой вопрос в общем — работать собираюсь через MS-провайдеры, но распространённые, которые и наши аппаратные ключи поддерживают (т.е. RSA, ГОСТ не нужен).

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

>>661182
Ладно, я много языком руками треплю, сейчас накидаю примерно, как я вижу простое шифрование-дешифрование. Потому что у меня есть очень большие сомнения в некоторых моментах, а правильно ли я понял кое-что, но если напишу, то сомнения могут и развеяться (а могут и укрепиться, лол).

По картам пока нет конкретики, но я же правильно понимаю, что если она поддерживает RSA, то при работе с ней через MS CryptoAPI проблем возникнуть не должно, как будто я с обычным хранилищем ключей работаю?

В источнике я:
получаю контекст провайдера, генерирую асимметричный А и сеансовый Б ключи;
записываю ключ А в хранилище;
считаю хэш данных, шифрую их ключом Б, а хэш — открытым А;
записываю зашифрованный хэш, ключ Б и зашифрованные данные и отправляю их. На этом со стороной источника покончено;
уничтожаю всю созданную ебалу, ну т.е. корректно завершаю работу с криптопровайдером.

В приёмнике я:
получаю контекст провайдера;
каким-то магическим образом получаю дескриптор закрытого ключа А (не сам ключ, естественно), дешифрую им хэш, ключом Б дешифрую данные и сверяю хэши;
если всё успешно, продолжаю работу, если нет — форматирую негодному пользователю диск C:, и завершаю работу с криптопровайдером.

Всё верно, или я где-то написал херню?

>>661216
Объебался с разметкой, ну да ладно.

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

>>661084
Далеко не только за этим. В системах где одна пара используется для подписи и шифрования, хеширование позволяет избежать раскрытия зашифрованной информации через подпись.
Алсо, хеширование всё равно необязательно для подписи.

>>661133
Браузер таки использует своё хранилище сертификатов, а вот хромоподелия лезут в системное.

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

>>661240
В принципе, ЦП не нужна. Но это я очень подробно расписал, на плюсах же пишу. Опять же, одной функцией тут не обойтись. Я как раз описал 1-й вариант, когда криптопровайдер генерирует, а потом я сам кладу в смарт-карту.
Только у меня не клиент-серверная архитектура, на стороне «источника» я генерирую файл, а он передаётся вместе со смарт-картой «приёмнику», который уже будет пользоваться данными, зашифрованными тем ключом. Изменять он их не должен, и свои генерировать и подписывать — тоже.

Не тони!

Решил сделать простейший шифратор-дешифратор. Создал хранилище для постоянной ключевой пары, сгенерировал сеансовый ключ, и… теперь не знаю, как зашифровать данные публичным ключом из хранилища!
В CryptEncrypt и CryptEncryptMessage я не нашёл параметра, который отвечает за то, чтобы шифрование осуществлялось публичным ключом (наверняка ведь приватным осуществляет, сука), CryptProtectData вообще только в рамках одного компьютера. Как зашифровать сообщение с помощью приватного ключа?

>>662860
> с помощью приватного ключа?
Публичного, конечно, я имел в виду.

Вот что нашёл https://msdn.microsoft.com/en-us/library/windows/desktop/aa386972
Вроде пишут, что в «источнике» шифруется с помощью открытого ключа, а в «приёмнике» расшифровывается с помощью закрытого. Пилю пока что прогу, попутно пытаясь понять встречающиеся ошибки.

Наконец-то добрался до сюда. Итак, что у меня вышло:
— в источнике сгенерировал асимметричный ключ, экспортировал его;
— сгенерировал сессионный ключ;
— экспортнул его, зашифровав (если верить документаци) публичным ключом из пары;
— зашифровал полученным сессионным ключом исходное сообщение, записав туда зашифрованный сессионный ключ;
— в приёмнике импортировал сохранённый ключ;
— извлёк из сообщения зашифрованный сессионный ключ, расшифровав его (опять же, согласно документации) приватным ключом;
— расшифровал сообщение полученным сессионным ключом.
Всё работает даже на разных компьютерах, но оно и неудивительно — ключевую пару я туда импортирую, что в реальной ситуации случаться не должно — приватный ключ должен будет храниться на смарт-карте, например.
Поэтому вопрос — будет ли в случае со смарт-картой всё работать также, отправит ли CryptoAPI весь процесс расшифровки приватным ключом во внутренности карты?
Потому что если этот подход неверен, придётся искать другой путь.

Ну же, анон, я уверен, что ты знаешь! Если не работал со смарт-картами, то хотя бы в теории можешь ответить.

>>661113
А как отправить-то? Вот в чём вопрос. Мой алгоритм из >>666732 подойдёт, или его придётся генно-модифицировать?

>>670851
>Ну же, анон, я уверен, что ты знаешь! Если не работал со смарт-картами, то хотя бы в теории можешь ответить.
тебе же объявили цену, дебилушка

>>674193 → >>657576
>да и не надо мне за деньги
Может, это какой-то новый прекол такой. Но мне пофиг.