Скрипт шифрования файлов открытым ключом OpenSSL
Архивирует папку, шифрует её открытым ключом и генерирует другой скрипт, содержащий в себе одноразовый ключ, данные и команды для расшифровки. Кроме того, скрипт может сгенерировать для вас пару RSA ключей.
Генерируем пару ключей. После этого папка folder шифруется в скрипт decrypt-folder.sh а затем расшифровывается в архив folder.tar. Из минусов отмечу то, что данные в decrypt-folder.sh хранятся в формате BASE64 – соответственно их размер увеличивается:
./encrypt-file.sh -keys public.pem private.pem
./encrypt-file.sh folder public.pem > decrypt-folder.sh
chmod +x decrypt-folder.sh
./decrypt-folder.sh private.pem > folder.tar
Запускаем:
$ ./encrypt-file.sh
Usage: ./encrypt-file.sh [directory] [public-key] > [decryption-script]or: ./encrypt-file.sh -keys [public-key] [private-key]
Предлагаю оптимизировать и допилить его до уровня повышенной параноидальности)
P.S. Кому и для чего это нужно – наглядно поясняет один из старых комментов unknown:
unknown (08/02/2013 14:08) профиль/связь <#>
комментариев: 6772 документов: 419 редакций: 3821
отпечаток ключа: ...9153691B80585959
Длинные асимметричные ключи поддерживает OpenSSL. Если вас так мучает паранойя по поводу резкого прогресса во взломе асимметрики, то шифруйте сообщения им по договорённости с получателем. По крайней мере, там это поддерживается штатно.
комментариев: 9796 документов: 488 редакций: 5664
Предложите свой вариант, маэстро!;) ©
GnuPG в экспертном режиме вроде позволяет использовать ключи размером и 8192 и, кажется, даже ещё в 2 раза больше. Вам этого недостаточно?
Как вы решаете проблему передачи секретного ключа получателю, если ключевая пара полностью генерится отправителем? Если есть способ непосредственно передать из рук в руки, зачем привлекать ненужные сущности типа Public Key Crypto? Почему бы не шифровать симметричным ключом, который есть у обеих сторон, сразу? Даже если хочется попараноить, то для собеседников, с которыми вы можете встретиться лично, я бы посмотрел в сторону одноразового блокнота как дополнительной меры.
комментариев: 1079 документов: 58 редакций: 59
Ну разве что для шифрования файлов, т.к. в других случаях возникнут проблемы, особенно, если использовать мобильные приложения для работы с GnuPG. К примеру тот жe APG тупо не видит ничего, что выходит за рамки стандартной длины ключа. Почтовый клиент K-9 Mail – тоже самое.
А что там про экспертный режим? Можно ведь просто значение поменять и все:
Можно подписывать имеющимися ключами. Проблема передачи – это другая тема. Пароль сказать одним способом (устно, обезличенно письменно, да много их), а ключ передать – по защищенным каналам связи, да тупо пошифровать его в теле письма GPG и все. Уж связка Thunderbigd+Enigmail точно не захлебнется от gpg-ключа, размером в 16384.
комментариев: 1079 документов: 58 редакций: 59
Присоединяюсь;) Если есть время – перепиши этот кусок, буду признателен. Я не кодер и поэтому вообще не могу понять как мне эту функцию вызвать в bash, одно дело в С или Python, но как вызвать из скрипта – хз..
Я добавил только ввод размера ключа при генерации, и то по возможности допилю:
Ну и развеял свои сомнения по повду BASE64, не смотря на то, что он размер прибавляет порядка 30% – зато удобнее всего хранит любую инфу в текстовом виде.
комментариев: 1079 документов: 58 редакций: 59
В общем небольшие обновления скрипта:
-Добавлен ввод размера ключа, по умолчанию стоит 4096
-Комменты и echo переведены на русский
-Все танцы с /dev/urandom заменены на
Сам скрипт:
Допиливайте, кому интересно.
комментариев: 9796 документов: 488 редакций: 5664
Всегда удивляли люди, которые просто берут и делают, без малейшего ощущения, что так делать нельзя. Почти в любой другой области, кроме безопасности, человек, готовый показать делом, а не словом, конечно лучше, но тут как раз не тот случай :)
Добавить опцию --expert в командной строке, как бы банально это ни звучало.
Из командной строки это сработает. Если повесите команду на какую-то кнопку или хоткей, то тоже. Раз вы всё равно отказываетесь от совместимости, генеря собственные скрипты, то что вы теряете?
Прикрепляйте шифрованный с помощью gpg файл аттачем к письму, и расшифровывайте его не встроенными средствами мейлера, а руками в командной строке, например. Раз у вас всё равно самопал, то не вижу проблемы. Юзер всегда можно скачать прикреплённый файл и руками (или скриптом) его расшифровать.
Вы защищаетесь от гипотетического противника, который может ломать уже имеющиеся ключи, потому что они короткие. Вы не можете защитить длинный ключ, зашифровав его коротким.
Которых пока ещё нет, т.к. длинный ключ у вас, а всё остальное считается скомпрометированным. Исключение — предрасшаренный симметричный ключ-пароль, переданный заведомо безопасным способом (например, из рук в руки).
Пошифровать что и чем? Обратите внимание на мои замечания выше. Предлагаю вам подумать над тем, что вы считаете уже взломанным, а что ещё нет, и проанализировать с этой точки зрения свою схему передачи ключа. Я не буду вдаваться в резонность вашей паранои, но хотя бы в рамках своей логики вы должны быть конситентны, а то там можно дойти до того, что приватный ключ передавать открытым текстом, выкладывая его на сайт. Кстати, даже если придерживаться вашего метода, то разумно было бы ничего не передавать, а давать всем скрипт, пусть после этого каждый сам генерит для себя ключевую пару. А сверить отпечатки потом можно любым удобным способом — например, по телефону.
IMHO, лучше воспользоваться pwgen. По крайней мере, я слышал, что его автор тот же, что и писал gpg.
Простенький баянистый однострочник для симметричного и (должно бы быть) бессигнатурного.
Unknown, если вас не затруднит, напишите, зачем нужен keyctl. Он только для управления openssl-ключами или вообще любыми? Пишут про /proc/keys почему-то ещё. Поверхностный поиск не даёт ответа, в каких случаях обычно используют keyctl (я не про технику, а про суть).
комментариев: 9796 документов: 488 редакций: 5664
Любыми.
В Debian лежат примеры использования с LUKS, хотя изначально он разрабатывался не для этого. Это вроде как единственное по-настоящему безопасное решение, когда нужно передать симметричный ключ или пароль в скрипте, между скриптами или командами, чтобы он не засветился для посторонних процессов или случайно не попал на диск.
Кустарный метод для keychain и работы с ssh-ключами:
комментариев: 9796 документов: 488 редакций: 5664