Ещё раз об OpenSSL

[Sleuthhound]

Так и хочется спросить: и чего же вы не нашли в официальной документации на openssl или в man?
По-моему все описанное вами там есть, как есть и в 100500 статьях в интернете.

[alex_ter]

На самом деле документация по OpenSSL, по современным меркам, ужасная. Особенно, если копнуть в сторону использования их библиотек программно, а не через командную строку. Спасает только наличие огромного количества примеров в сети.

[MMik]

Перепроверьте текст вашей заметки. Первой командой вы создаёте key и key.pem, а второй командой пытаетесь использовать privatkey.pem и получите ошибку о невозможности открыть файл.
Дальше вы пишете:

Публичный можно закинуть на сервер, чтобы подключаться к нему по ssh, используя свой приватный ключ.

, что сделать не удастся.
Простите, дальше перепроверять вас мне лень.

[Gutt]

Получится, просто не со стоковым OpenSSH. Одна из реализаций: http://roumenpetrov.info/secsh/index.html
Но удовольствие на любителя.

[GarfieldX]

Это называется занудство.
1. Да, есть некоторый перескок key.pem -> privatekey.pem, но по скринам все четко.
2. Нюансы закидывания паблика на сервер не уточнялись. Может это свой же сервер или можно связаться с админом нужного сервера.

[sena]

В таком режиме гораздо удобней gpg

[kay]

Не у всех есть gpg. А вот rsa/dsa/ecdsa/ed25519 как правило у многих. И публичный ключ легко достать через тот же github.com:

https://github.com/torvalds.keys

[sena]

Я думал наоборот, ведь именно pgp предназначен для этого изначально.

pgp.mit.edu/pks/lookup?search=0x00411886&op=index

[rt3879439]

Власти скрывают.

[iig]

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

[robux]

Кстати, у меня в Пандоре так личные сообщения и шифруются:
если сообщение короче или равно 256 байт, то только RSA-2048,
а если длиннее, то случайный AES-512 + RSA-2048.

[lorc]

Хм, какой же вы паддинг используете, если вы можете зашифровать 256 байт с помощью RSA-2048?

а если длиннее, то случайный AES-512 + RSA-2048.

Если посмотреть NIST SP 800-57 то окажется что стойкость AES-256 соответствует мифическому RSA-15360. У вас же наблюдается явный дисбаланс. Стойкость RSA-2048 вообще на уровне 3DES, чего просто мало в современном мире.

[mayorovp]

Стойкость AES-512 + RSA-2048 ну никак не может быть выше чем стойкость RSA-2048.

[lorc]

Собственно я об этом и написал:

У вас же наблюдается явный дисбаланс

Вы наверное не так поняли смысл моего комментария. Не имеет смысла использовать AES-512 + RSA-2048, потому что это тратит лишние ресурсы на работу с AES-512, не добавляя стойкости, ибо стойкость ограничена RSA-2048

[lorc]

Ох… Извините, но лучше все-таки не давать какие-либо советы по криптографии, если вы в ней сами только-только начинаете разбираться.

rand /var/log/messages — рандомное значения из любой папки, лучше взять логи, т.к. с /dev/random или /dev/urandom может все повиснуть наглухо, у меня так и было.

/var/log/messages далеко не случаен, поэтому есть немаленькие шансы восстановить ваш ключ. А /dev/random у вас не «зависал», а блокировался, потому что у ядра было недостаточно энтропии для генерации истинно случайных чисел. В этом случае можно использовать /dev/urandom или добавить источников энтропии.

openssl rand -base64 32 > key.bin

Все-таки base64 или bin? Это приведет к путанице (точнее уже привело) и ослаблению надежности криптосистемы.

aes-256-cfb — алгоритм и режим шифрования. О режимах здесь не буду говорить. Этот лучший.

Чем СFB лучше CTR, например? Я уж молчу об аутенфицирующем шифровании типа GCM.

Далее зашифруем файл этим ключом:

openssl enc -aes-256-cfb -salt -in OWASP_Top_10-2017_\(en\).pdf -out OWASP_Top_10-2017_\(en\).pdf.enc -pass file:./key.bin

Вы шифруете файл не ключом. Вы говорите openssl «возьми содержимое файла key.bin в качестве пароля, породи из него ключ и IV». Правильнее было бы вызвать enc с параметрами -K и -iv для передачи настоящей пары key/iv.

Теперь: Почему так сложно? Почему нельзя взять и сделать все с помощью ассиметричного шифрования?

Потому что суть RSA — это возведение огромного числа в огромную степень. Это долго и дорого.

Слишком много данных для размера ключа. Ибо в ассиметричном шифровании размер ключа должен быть больше или равен открытому тексту.

Вас же не удивляет что AES может шифровать только блоками по 128 бит? Это даже меньше чем у RSA с их 1024/2048/4096 битами. Вы вполне можете побить свой файл на блоки 4096 бит и зашифровать его весь с помощью RSA. Только это будет ОЧЕНЬ долго. Вот поэтому и используют RSA+симметричный шифр, а вовсе не потому что RSA не может шифровать большие куски.

[demfloro]

-rand /var/log/messages — рандомное значения из любой папки, лучше взять логи, т.к. с /dev/random или /dev/urandom может все повиснуть наглухо

Во-первых: нет причин указывать -rand параметр если точно не знаете зачем указываете.
Во-вторых: любой лог файл это плохой источник энтропии.
В-третьих: /dev/urandom блокируется только во время инициализации генератора случайных числе (crng init done в dmesg) (CVE-2018-1108), после этого он никогда не блокируется. Ядра, не запатченные от этого CVE, не блокируют urandom.

[saipr]

Желающие могут попробовать OpenSSL с ГОСТ-ой криптографтей. И шифровать не на aes-cfb, а на ГОСТ28147-CFB.

[asoloviov]

Много скриншотов и мало проработки нюансов. Да и вообще, отсутствие пояснений выбора того или иного параметра для OpenSSL, не только скрывает источник ошибок применения исструмента, но и не позволяет критичному читателю копнуть поглубже. Хоть бы ссылки на внешние источники привели, которые бы пояснили почему же это aes-256-cfb — Это лучший
Ну и так, на последок: судя по -pass file:./key.bin вот это вы не видели…
Я бы поставил 3 с минусом за такую "домашнюю работу".