Comments 16
Мы не хотим использовать какой-то один "супер-ключ" и давать его всем.
И вместо этого мы сделаем несколько "супер-ключей"!
Каждым из них можно расшифровать, да. Но за счет того, что их несколько - каждый хранится у отдельного человека в его темном чулане и не пересылается нигде, не оказывается в руках ни у кого. Это понижает шанс утечки.
Просто неприятный опыт с "суперключом" (единым) я наблюдал. Там правда был не ключ от шифрования, а тестовые логин/пароль к одной системе. Ими пользовались N человек, пересылали друг-другу, потом какие-то люди уходили из команды (а пароль оставался тем же), а потом он утек. И утек, как мы предполагаем - из переписки. А вот чью переписку (или мессенджер) взломали - мы так и не смогли узнать. Нет переписки, передачи, копирования ключа - нет сопряженных с этим рисков.
Если уж двигаться по этому пути, то немного подальше - чтобы в одиночку никто расшифровать не мог.
Знание "у кого утёк ключ" особой практической ценности не несёт - данные всё равно скомпрометированы.
Если пароль один на всех то кроме утечки из ./ssh, где он кстати лежит под паролем, добавляется еще возможность утечки из переписки, шарить же его как то нужно.
Можно конечно представить совсем отмороженных которые будут шарить свои приватные ключи но это техническими средствами не исправляется. Точно так же как и в вашей ситуации можно представить что все просто поделятся ключами друг с другом и получат "ключ всевластья".
У нас немного другие риски. Да, не хотелось бы, чтобы архивы утекли. Это было бы плохо, но не катастрофа. А вот катастрофой была бы другая опасность - если нам нужен бэкап, а мы не можем его получить (или скачали, но не можем расшифровать). Например, потому что нужен ключ человека, который уволился, умер, просто потерял/поменял себе ключ. Все-таки бэкапы делаются чтобы иногда ими пользоваться. Поэтому усиливать конфиденциальность имеет смысл только до той поры, пока это не начинает конфликтовать с доступностью бэкапов для нас самих.
А про знание, откуда утек ключ - мне оно кажется очень важным. Ключи ведь не должны утекать. Значит, где-то что-то у нас неправильно. Поменяем мы ключ и новый тем же образом утечет. Надо знать, где проблема, чтобы она не повторилась снова.
зачем тащить какую то утилиту для синхронного шифрования, если gpg -c secret.tar.gz?
Вы имеете в виду "симметричного", вероятно?
В случае с age будет связка: ChaCha20-Poly1305 для шифрования и PBKDF2 для наследования ключа из пароля.
В случае с gpg будет (по умолчанию) связка: AES-256 для шифрования и SHA-1 с солью для создания ключа из пароля.
И ChaCha20 более современный и считается более стойким, чем AES-256, и SHA-1 считается устаревшим для криптографических целей. Перебор паролей с SHA-1 будет гораздо быстрее, чем с PBKDF2 (специально замедленный алгоритм).
Но в целом, хоть алгоритмы в age более надежные, gpg "для дома для семьи" тоже вполне подойдет (мы же не рассматриваем вариант, что ЦРУ будет ваши файлы взламывать). Более опасная разница в том, что если начать настраивать алгоритмы ручкам в gpg, то там можно сильно напортачить (age более предсказуем в этом плане, он вот всегда с одной конфигурацией работает).
А так - если удобно - то почему бы и не тащить gpg если он привычнее? Если у вас УЖЕ есть работающая схема шифрования на gpg, она проверена и все хорошо - я бы ради преимущества в алгоритмах менять бы ее не стал (по крайней мере в обозримом будущем).
Основная прелесть здесь не в симметричном шифровании, а с использованием ключевых пар (как своих, так и уже имеющихся от OpenSSH). Да, gpg много где есть (но не везде ставится по умолчанию); но какой же он огромный и переусложнённый (один Web Of Trust, от PGP тянущийся, чего стоит).
Кстати, git тоже позволяет подписывать коммиты при помощи ключевых пар от OpenSSH, тенденция!
Мне кажется, тенденция в том, что во многих вопросах мир давно перешел порог разумного усложнения и по инерции прошел существенно дальше. И теперь я много где вижу откат к простоте (даже пусть и не бесплатно, с потерей каких-то плюшечек, которые не очень-то и жалко).
К примеру, сделали когда-то в *nix'ах shared библиотеки, не такой уж простой механизм, чтобы один код использовать в разных программах - хорошая идея вроде бы! Экономит место на диске, экономит оперативку. Для него пришлось использовать apt в debian/ubuntu для контроля зависимостей. При этом зависимости конфликтуют, потребовались виртуалки-контейнеры для изоляции. А тут появляется golang с простой идеей, что у них никаких shared библиотек не будет, как в gcc --static, все всегда будет собираться в один файл. Тупо как во времена MS DOS. Да, файл жирный будет, да и фиг с ним. И... оказалось, что всех устраивает! На самом деле исходно и gcc так мог легко, но не пользовались этим, и фактически это оказалось одним из преимуществ golang.
Во многих проектах виден жизненный цикл - появляется фанатский опен-сорсный проект, написанный за месяц на коленке, простой, эффективный, и он взлетает, становится популярным. Какое-то время он оправданно развивается - фиксятся баги, дописываются нужные многим функции. А потом дописывают туда одну фичу, другую, пятую, десятую, появляются корпоративные клиенты которые платят чтоб им сделали нужные им функции вроде масштабирования, резервирования. И удобный велосипед превращается в тяжеленный аэробус. А тебе-то нужно в булочную через два дома ездить. И появляются новые проекты, которые "вот то же как в том, только lite версия, только простые самые важные фукции", снова возврат к велосипеду.
Как то оно не выглядит пригодным для бэкапов, по крайней мере для инкрементных.
Для бэкапов, фанатам Filippo Valsora, лучше сразу смотреть restic, и читать его restic cryptography, в котором он пишет :"I'm going to use restic..."
Хех, у нас как раз такая комбинация и используется :-). restic'ом файловые каталоги (огромные, но мало новых файлов) бэкапируется, а age - бэкапы баз данных.
Для баз данных есть какой-то удобный способ инкрементальных бэкапов? (кроме бинлогов даже ничего и не приходит на ум). И вообще, когда проект брали - там была туева хуча баз данных непонятного предназначения и даже вот интересно было - есть ли способ узнать, за последний месяц что-то писалось в базу или нет, я не нашел инструментов для этого.
С рестиком, правда (хоть и немного оффтопик) был однажды странный глюк, из-за которого я начал чуть побаиваться его. Решили мы еще один каталог кидать в restic ежедневно, кидали. А потом просто перестали его использовать, удалили. Но по крону - кидали (несуществующий каталог). И в какой-то момент его репозиторий этого несуществующего каталога внезапно неимоверно раздулся так, что у меня мониторинг заистерил. Возможно, они его не тестили, когда сто раз делается снапшот несуществующего каталога :-)
А под Windows как работает?
Не пробовал, но это же программа на Go - полагаю, что так же, из командной строки, без GUI.
пример с паролем из статьи сработал только на шифрование, на расшифровку сыпал непобедимыми ошибками про ключ -o
В документации нашел более лаконичные и работающие под windows примеры:
#encryptage -p secrets.txt > secrets.txt.age Enter passphrase (leave empty to autogenerate a secure one): #decrypt age -d secrets.txt.age > secrets.txt
Большое спасибо за статью! Как-то эта утилита до сих пор мимо меня проходила; уже поставил на линуксах (sudo apt install age) и на макосях (brew install age). Проверил с ключевыми парами от OpenSSH (RSA и ed25519) — работает как надо.
Буду теперь использовать вместе (или вместо) GnuPG — он делает то же, и хорошо делает; но больно уж универсальным комбайном стремится стать. И если на системе его ещё нет, то теперь можно и не ставить, заменив на age.
Шифрование бэкапов с использованием age и о ценности простоты