id: Гость   вход   регистрация
текущее время 01:14 29/03/2024
Автор темы: Гость, тема открыта 04/01/2014 10:01 Печать
Категории: криптография, алгоритмы
создать
просмотр
ссылки

Использование OpenSSL


OpenSSL умеет симметрично шифрованть файлы. Я попытался зашифровать файл шифром 3des



Файл зашифровался, но его объем не стал меньше, а сохранился практически один в один (это файл word, который архиватором 7z сжался примерно в 3 раза, с 50 до 15 кБ). Хотя перед шифрованием положено файлы сжать.


1. В чем преимущества шифрования при использовании OpenSSL?
2. При наличии GnuPG есть ли смысл заниматься шифрованием с помощью OpenSSL?
3. Если ответ на п.2 отрицательный, то в каких областях OpenSSL вне конкуренции?



 
Комментарии
— SATtva (04/01/2014 11:06)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Файл зашифровался, но его объем не стал меньше, а сохранился практически один в один

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

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

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

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

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

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

В каких целях? Какой use-case? Обычному пользователю, как правило, ручное использование OpenSSL ни к чему.
— Slon (04/01/2014 11:51)   <#>
В каких целях? Какой use-case? Обычному пользователю, как правило, ручное использование OpenSSL ни к чему.


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


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

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

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

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


ps прошу прощения за вопросы "начального уровня", с openssl никогда дела не имел.
— SATtva (04/01/2014 12:44)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Обычное шифрование отдельного файла, для его защиты от просмотра и хранения например на удаленном хранилище. Так обычно использую 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], [2]. У OpenSSL вроде получше, но гарантий никто не даст. Помимо OpenSSL и GnuPG можно вспомнить про mcrypt и cryptsetup/LUKS, которыми тоже в принципе можно шифровать файлы, причём с помощью LUKS в plain mode (а также, наверное, в truecrypt mode) с нужными параметрами и правильно сгенерённым паролем вроде как это будет надёжно бессигнатурно. Главное отличие от GnuPG здесь в том, что нет защиты от дурака: GnuPG — это всё в одном, где есть надёжная KDF, вектор инициализации и пр. В некоторых других тулзах этого может не быть (например, в mcrypt), поэтому можно ненароком очень сильно ослабить шифр. В общем, это для тех людей, которые понимают, зачем это нужно, для всех остальных случаев есть GnuPG.
  4. Иногда нужно получить поток псевдослучайных чисел с хорошей производительностью. У OpenSSL такая возможность есть, чего не скажешь про многие другие тулзы. Для заполенения диска рандомом, правда, лучше использовать шифрование нулей cryptsetup/LUKS'ом, но, в принципе, у OpenSSL PRNG могут быть и другие применения, где LUKS не подойдёт.


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


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


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


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


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


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


Было от него примерно три похожих по смыслу топика:
  1. Pyrite – фронтенд GnuPG\OpenSSL
  2. Скрипт шифрования файлов открытым ключом OpenSSL
  3. NBStego.sh
— Гость (13/04/2014 01:25)   <#>

В области бэкдоров. Он настолько эпичен, что легко порвёт любой другой софт по масштабам мировых последствий [1], [2].
— Гость (13/04/2014 01:40)   <#>

Это не доказано. Люди ошибаются, а computer science местами сплошное искусство и никакой науки. Сидят макаки за маками.
— Гость (13/04/2014 08:04)   <#>

Ту часть деятельности не приятно называть CS. CS — это FOCS, STOC, CRYPTO, QIP, IEEE, SIAM J и т.п. Макак там не особо. Остальные тупо кодеры.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3