Как зашифровать сообщения/текст с RSA & OpenSSL?

В ниже, обратите внимание, что можно указать любой алгоритм, который Вы хотите, быть этим те перечисленные или RSA (хотя я не знаю точное имя, используемое для RSA OpenSSL),

используйте "openssl enc - справка" для получения списка поддерживаемых шифров в системе и передачи что как аргумент. например, "-aes256"

Примечание по моей системе у меня нет RSA в моих опциях - по крайней мере, тем именем.

Как я шифрую сообщение S/MIME?

Скажем, то, что кто-то отправляет Вам ее общедоступный сертификат и просит, чтобы Вы зашифровали некоторое сообщение ей. Вы сохранили ее сертификат как она-cert.pem. Вы сохранили свой ответ как my-message.txt.

Получить значение по умолчанию — хотя довольно слабый — шифрование RC2-40, Вы просто говорите openssl, где сообщение и сертификат расположены.

openssl smime ее-cert.pem - шифруют - в my-message.txt

Если Вы вполне уверены, у Вашего удаленного корреспондента есть устойчивый инструментарий SSL, можно указать стойкий алгоритм шифрования как тройной DES:

openssl smime ее-cert.pem - шифруют-des3 - в my-message.txt

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

openssl smime her-cert.pem \
   -encrypt \
   -des3 \
   -in my-message.txt \
   -from 'Your Fullname <you@youraddress.com>' \
   -to 'Her Fullname <her@heraddress.com>' \
   -subject 'My encrypted reply' |\
 sendmail her@heraddress.com

Как я подписываю сообщение S/MIME?

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

 openssl smime \
   -sign \
   -signer /path/to/your-cert.pem \
   -in my-message.txt \
   -from 'Your Fullname <you@youraddress.com>' \
   -to 'Her Fullname <her@heraddress.com>' \
   -subject 'My signed reply' |\
 sendmail her@heraddress.com

(из http://www.madboa.com/geek/openssl/)

(er... все те обратные косые черты - они, как предполагается, являются оставленными новыми строками. не уверенный, что продолжается, поскольку это отображается прекрасный в моем окне редактирования здесь!

Во-первых, если Вы просто хотите хорошее шифрование, необходимо посмотреть на GnuPG. Но если Ваше экспериментирование и просто хочет изучить, как оно работает, необходимо понять, каков RSA. RSA не разработан для шифрования любой произвольной строки, это - алгоритм, который шифрует целое число. А именно, целое число от 0 до n-1, где n является значением модуля от открытого ключа. Когда Вы говорите о ключе RSA, это составляет 1 024 бита, который означает, что требуется 1 024 бита для хранения модуля в двоичном файле. Это - одна из причин, RSA используется в сочетании с шифром симметричного ключа как DES или AES. Можно генерировать случайный ключ на 256 битов для AES и зашифровать тот ключ с открытым ключом RSA на 1 024 бита. Затем любой, какой доступ к закрытому ключу может извлечь симметричный ключ и декодировать сообщение с AES. Полный стандарт для RSA называют № 1 PKCS

Кроме того, DES и AES являются блочными шифрами. Они только шифруют данные в блоке определенного размера. DES использует 64-разрядные блоки, и AES использует 128-разрядные блоки. Для шифрования больше, чем блок необходимо использовать Режим работы как CBC или CTR. Эти режимы указывают, как зашифровать поток битов с помощью шифра блочного режима.

Наконец, важно проверить данные, которые Вы получаете. В то время как взломщик не может считывать данные в пути, он может зеркально отражать биты без обнаружения, если никакая целостность или подлинность не применяются к потоку данных. Взломщик может легко предположить, что соединение SSL с портом 443 является, вероятно, запросом веб-страницы, запускающимся с GET / и он мог зеркально отразить бит, изменяющий его на PUT / не вмешиваясь в остальную часть шифрования. Простой подход к целостности должен добавить MD5 или сумму SHA-1 в конце, но который только обеспечивает целостность данных, не подлинность данных. Любой с полным знанием потока данных может генерировать корректную сумму, более безопасный подход должен использовать хэширование по ключу как HMAC, который требует, чтобы знание секретного ключа генерировало, таким образом, обеспечение подлинности данных в дополнение к целостности.