How to become an author
Search
Write a publication
Pull to refresh

Comments 18

Так и хочется спросить: и чего же вы не нашли в официальной документации на openssl или в man?
По-моему все описанное вами там есть, как есть и в 100500 статьях в интернете.
Total votes 3: ↑1 and ↓2-1
На самом деле документация по OpenSSL, по современным меркам, ужасная. Особенно, если копнуть в сторону использования их библиотек программно, а не через командную строку. Спасает только наличие огромного количества примеров в сети.
Total votes 1: ↑1 and ↓0+1
Перепроверьте текст вашей заметки. Первой командой вы создаёте key и key.pem, а второй командой пытаетесь использовать privatkey.pem и получите ошибку о невозможности открыть файл.
Дальше вы пишете:
Публичный можно закинуть на сервер, чтобы подключаться к нему по ssh, используя свой приватный ключ.
, что сделать не удастся.
Простите, дальше перепроверять вас мне лень.
Total votes 6: ↑6 and ↓0+6
Это называется занудство.
1. Да, есть некоторый перескок key.pem -> privatekey.pem, но по скринам все четко.
2. Нюансы закидывания паблика на сервер не уточнялись. Может это свой же сервер или можно связаться с админом нужного сервера.
This comment wasn’t rated yet0
В таком режиме гораздо удобней gpg
Total votes 1: ↑1 and ↓0+1

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


https://github.com/torvalds.keys

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

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

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

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

Если посмотреть NIST SP 800-57 то окажется что стойкость AES-256 соответствует мифическому RSA-15360. У вас же наблюдается явный дисбаланс. Стойкость RSA-2048 вообще на уровне 3DES, чего просто мало в современном мире.
Total votes 1: ↑0 and ↓1-1
Стойкость AES-512 + RSA-2048 ну никак не может быть выше чем стойкость RSA-2048.
Total votes 1: ↑0 and ↓1-1
Собственно я об этом и написал:

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


Вы наверное не так поняли смысл моего комментария. Не имеет смысла использовать AES-512 + RSA-2048, потому что это тратит лишние ресурсы на работу с AES-512, не добавляя стойкости, ибо стойкость ограничена RSA-2048
This comment wasn’t rated yet0
Ох… Извините, но лучше все-таки не давать какие-либо советы по криптографии, если вы в ней сами только-только начинаете разбираться.

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 не может шифровать большие куски.
Total votes 4: ↑4 and ↓0+4
-rand /var/log/messages — рандомное значения из любой папки, лучше взять логи, т.к. с /dev/random или /dev/urandom может все повиснуть наглухо

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

Total votes 3: ↑3 and ↓0+3

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

This comment wasn’t rated yet0

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

This comment wasn’t rated yet0
Sign up to leave a comment.

Articles

Show the best of all time

Your account

Sections

Information

Services

Support
© 2006–2024, Habr