Хотел спросить, как организовать шифрование + электронную подпись. Т.е. нужно: -Передать зашифрованный небольшой кусок данных (текста) -Проверить подлинность документа Шифрование проводится с помощью RC6. Контрольную сумму думаю считать CRC16. Мое решение (правильное ли???): 1) Берутся данные и определяется их контрольная сумма 2) Данные шифруются 3) Данные совмещаются с контрольной суммой и отправляются.
Да, цифровая подпись - это, по сути, зашифрованная хэш-сумма. Но практический смысл такая подпись будет иметь только в том случае, если вместо RC6 будет использоваться какой-нибуть асcиметричный алгоритм, а вместо CRC16 - хэш-функция с достаточно большой разрядностью (SHA-256, к примеру).
RC6 - симметричный алгоритм шифрования, пригоден в схеме с закрытым ключем Т.е. если юзер А передает по открытому каналу юзеру Б сообщение, зашифрованное неким ключем, известным только обоим юзерам (или ключ сгенерирован юзером А и передан юзеру Б по защищенному каналу) Тогда "Проверить подлинность документа..." будет заключаться в дешифрации сообщения и проверке КС. Обычно под проверкой подлинности понимается нечто иное, а именно - то, что сообщение сгенерировано именно юзером А, а не кем иным. При такой постановке вопроса необходимо использовать асимметричные алгоритмы (DSA, RSA), оперирующие парами ключей открытый/закрытый.
Cr4sh, gorodon Спасибо, понял что RC6 симметричный только после изучения алгоритма(( Такой вопрос: также нужно шифровать переданные данные, для этого надо будет дополнительно шифровать все симметричным алгоритмом? А если шифровать так: и контрольную сумму и данные вместе только асимметричным алгоритмом? Тогда длинна контрольной функции будет менее критична?
Электронно-цифровая подпись на асимметричных алгоритмах нужна там, где две стороны не доверяют друг другу. То есть потенциальную выгоду может получить отправитель, передав что-то "не то", а затем заявив, что это мошенничество получателя или наоборот. Яркий пример : "клиент-банк". Если же угроза только в том, что какая-то третья сторона пытается модифицировать посылку, то тут достаточно симметричных алгоритмов проверки подлинности - MAC : http://ru.wikipedia.org/wiki/Message_authentication_code , HMAC : http://ru.wikipedia.org/wiki/HMAC - на любом криптостойком симметричном шифре или хеш-функции. Они гораздо проще в реализации, чем "асимметрия". По поводу длины если очень-очень хочется использовать CRC, а не нормальный криптостойкий хеш - обсуждали буквально только что : http://wasm.ru/forum/viewtopic.php?id=40650 (пост №9)
OLS Спасибо. Дело в том, что надо, чтобы принимающая сторона была уверена, что данные пришли именно от верного источника, а не от злоумышленника. При этом обратная связь не важна (данные передаются только в одну сторону). Также желательно, чтобы данные не передавались в исходном виде (хотя это менее важная задача). Поэтому интересуют именно асимметричные алгоритмы шифрования. Хеш я выберу более стойкий. Исходя из этого два варианта (Шифрование RSA): 1) Классический, но решающий только задачу верификации: Код (Text): Начало блока+[Зашифрованный контейнер:Хеш]+(Случайная последовательность+Данные)+Конец блока В этом случае придется еще шифровать все симметричным ключом. 2) Второй вариант, решающий задачу шифрования данных. Код (Text): Начало блока+[Зашифрованный контейнер:Хеш+(Случайная последовательность+Данные)]+Конец блока При этом Хеш делается из случайной последовательности И данных. Второй вариант заслуживает реализации? ------- И еще один вопрос, RSA реализован в CryptoApi? Если да то почему люди пишут свои библиотеки?
Тогда тебе как раз подойдут симметричные схемы. Либо используй MAC/HMAC, либо если хочется высокую скорость обработки, то смотри в сторону "single-pass authenticated encryption" (лучше всего на мой взгляд OCB - http://www.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm - и по скорости замечательные показатели и стандартизован несколько раз).
