— SATtva (04/01/2014 11:06)   

Файл зашифровался, но его объем не стал меньше, а сохранился практически один в один

Так и должно быть.

Хотя перед шифрованием положено файлы сжать.

Кем положено? Кому положено? Сжатие не способно повысить стойкость надёжных алгоритмов шифрования и не предназначено для этого. (Последние срачи на эту тему здесь^[link1] и здесь^[link2].)

В чем преимущества шифрования при использовании OpenSSL?

Как у любой криптобиблиотеки: гибкость, скорость операций.

При наличии GnuPG есть ли смысл заниматься шифрованием с помощью OpenSSL?

В каких целях? Какой use-case? Обычному пользователю, как правило, ручное использование OpenSSL ни к чему.

— Slon (04/01/2014 11:51)   

В каких целях? Какой use-case? Обычному пользователю, как правило, ручное использование OpenSSL ни к чему.

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


Прочитал здесь^[link3] о создании самоподписного сертификата. Возникли вопросы:

1. В какой папке следует искать создаваемые файлы, если начать выполнять команды из статьи (система Linux)?

2. Для того, что бы создать свой сертификат х509 для обмена зашифрованным e-mail сообщениями обязательно ли сначала делать собственный самоподписной сертификат, а после клиентский сертификат, который уже будет использоваться? Или можно сразу одной командой сделать нужный сертификат?

3. Обязательно ли создавать конфигурационный файл и где он должен лежать?


ps прошу прощения за вопросы "начального уровня", с openssl никогда дела не имел.

— SATtva (04/01/2014 12:44)   

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

Для данного случая — никаких, если только файл не на несколько гигабайт, и при этом очень дорого время. OpenSSL шифрует бессигнатурно, что имеет как плюсы, так и минусы: Вам придётся запомнить, каким алгоритмом, в каком режиме и с какими параметрами выполнялось зашифрование, чтобы успешно расшифровать файл. GnuPG, в свою очередь, не даёт пользователю с лёгкостью выстрелить себе в ногу, т.к. вся информация о параметрах сохраняется в формате OpenPGP.

— Гость (04/01/2014 15:08)   
Ressa выкладывал здесь скрипт для шифрования файлов средствами OpenSSL, мотивируя тем, что сабж де-факто поддерживает любую длину ключей. На выходе получался исполняемый автономный .sh скрипт.

— Гость (12/01/2014 04:39)   

В дополнение к уже вышесказанному: это вопрос удобства. Если хочется уменьшить объём шифртекста, то сначала заархивируйте, а только потом зашифруйте данные.


Помимо вышесказанного:

1. OpenSSL — как правило, часть системы. Например, на сырой свежеустановленной голой BSD нет GnuPG, а OpenSSL есть, поэтому если хочется особо полной портируемости между системами, можно воспользоваться OpenSSL.
2. Основной use case OpenSSL — работа с SSL-сертификатами (GnuPG этого всего попросту не умеет), которые нужны, например, для сайтов на HTTPS, для SSL в XMPP-протоколе и т.д. То, что при этом с помощью OpenSSL можно просто шифровать файлы или переписку — всего лишь, скорее, misuse, а не фича.
3. Иногда нужно бессигнатурное шифрование для отрицаемости. У GnuPG с этим плохо [1]^[link4], [2]^[link5]. У OpenSSL вроде получше^[link6], но гарантий никто не даст. Помимо OpenSSL и GnuPG можно вспомнить про mcrypt^[link7] и cryptsetup/LUKS, которыми тоже в принципе можно шифровать файлы, причём с помощью LUKS в plain mode^[link8] (а также, наверное, в truecrypt mode) с нужными параметрами и правильно сгенерённым паролем вроде как это будет надёжно бессигнатурно. Главное отличие от GnuPG здесь в том, что нет защиты от дурака: GnuPG — это всё в одном, где есть надёжная KDF, вектор инициализации и пр. В некоторых других тулзах этого может не быть (например, в mcrypt), поэтому можно ненароком очень сильно ослабить шифр. В общем, это для тех людей, которые понимают, зачем это нужно, для всех остальных случаев есть GnuPG.
4. Иногда нужно получить поток псевдослучайных чисел с хорошей производительностью. У OpenSSL такая возможность есть^[link9], чего не скажешь про многие другие тулзы. Для заполенения диска рандомом, правда, лучше использовать шифрование нулей cryptsetup/LUKS'ом, но, в принципе, у OpenSSL PRNG могут быть и другие применения, где LUKS не подойдёт.

Если у вас не какой-то особый случай (см. выше), то нет.


Работа с сертификатами, но и тут у него, в принципе, есть GNU-конкурент — GnuTLS. Правда, в силу тотального распространения OpenSSL и относительной молодости проекта GnuTLS доверия к первому больше, чем к последнему. Это не значит, что OpenSSL менее говно^[link6] паталогически дыряв по сути; это лишь значит, что в OpenSSL самые тривиальные дыры уже вычистили благодаря большому количеству его пользователей.


Зачем вам сертификаты для шифрования e-mail? Вы поднимаете собственный mail-сервер, юзерские коммуникации с которым должны быть защищены посредством SSL/TLS? Для end-to-end шифрования писем строго рекомендовано GnuPG.


По умолчанию все файлы в текущей директории. Это то, что выводится командой pwd. Определяя путь к файлам, их можно создавать в любой другой директории. Читайте, что именно написано в командах.


Если речь идёт о создании сертификата для mail-сервера, то не имеет значения. Важно только, чтобы клиентский сертификат после был позже подписан тем, чем вы хотите. Я не очень хорошо разбираюсь в сертификатах, но вроде бы самоподписной сертификат не требует создания какого-то особого дополнительного, которым он будет подписываться. В некоторых случаях так всё же делают, чтобы, импортировав нужный сертификат в браузеры клиентов (например, внутри компании), потом выстроить доверие ко всем другим сертификатам, которые будут подписаны первым. Это так называемое создание своего Certification Authority (CA). Обычно люди этим не занимаются, а получают подпись от того сертификата, который уже есть в браузере — это либо платные услуги от одного из сотен возможных поставщиков (CA), либо бесплатные от StartCom. В любом случае, это достаточно продвинутые вещи, и без понимания азов лучше туда не лезть.


Бессигнатурно, но только в смысле неполноты сигнатур для расшифрования/зашифрования по умолчанию, а не в смысле отрицания шифрования. Сигнатуры, указывающие на то, что это именно OpenSSL, имеются^[link6] (по крайней мере, если будете шифровать правильно, указывая нужные опции).


Было от него примерно три похожих по смыслу топика:

1. Pyrite – фронтенд GnuPG\OpenSSL^[link10]
2. Скрипт шифрования файлов открытым ключом OpenSSL^[link11]
3. NBStego.sh^[link12]

— Гость (13/04/2014 01:25)   

В области бэкдоров. Он настолько эпичен, что легко порвёт любой другой софт по масштабам мировых последствий [1]^[link13], [2]^[link14].

— Гость (13/04/2014 01:40)   

Это не доказано. Люди ошибаются, а computer science местами сплошное искусство и никакой науки. Сидят макаки за маками.

— Гость (13/04/2014 08:04)   

Ту часть деятельности не приятно называть CS. CS — это FOCS, STOC, CRYPTO, QIP, IEEE, SIAM J и т.п. Макак там не особо. Остальные тупо кодеры.