Здравствуйте, Аноним, Вы писали:

А>Как вы храните бекапы со своими gpg ключами?

Может использовать старый добрый KeePass: файл KeePass в облаке + длинный мастер-пароль?
У KeePass вроде есть плагины для хранения/использования ключей.

P.S. Сам ключи gpg не храню.

Здравствуйте, Буравчик, Вы писали:

Б> Может использовать старый добрый KeePass: файл KeePass в облаке + длинный мастер-пароль?

Кроме того, KeePass может использовать ключевые файлы.

Есть только одна проблема. При компрометации или протухании мастер-пароля копии файла в облаках и других местах просто так не уничтожить. Это недостаток не KeePass, а схемы в целом.

Здравствуйте,

Есть идея как хранить приватные ключи в открытом доступе.

1. Прячем наши приватные ключи в архив.
2. Генерим ключи (K). Для генирации ключей (K) мы заюзали такой пароль:
— взяли любой большой бинарный файл (А) с большой энтропией
— открыли в hex редакторе в любой извесной только нам кодировке, системе исчисления и скопировали символы с офсета 0xN по 0xM.
— добавли к фразе несколько своих символов.
3. Шифруем архив (B) с публичным ключем (К).
4. Добавляем ключ (K) в новый зашифрованый архив (С).
5. Генерим дерикторию с кучей мусора: файлов, бинарников; добавляем в него архив с (B), (С) или файл (А).
6. Постим архив на Github, облака и подобные сервисы под левым акком.
7. Повторяем 5. 6. несколько раз.

Профит: архив с приватными ключами и мусором(B) будет мало кому интересен и спрятан от большинства по разным обакам. Инфы которую нам надо помнить что бы рашифровать B немного, пароль к приватным ключам тоже так просто не сбрутфорсить.

-- Приватные ключи в всю роботу мы конечно проделываем с ОС загруженной с флешки(что бы потом не тратить время на стирание файлов с диска).
Сохраняем ключи на флешку, делаем пункы 1.-7., юзая tor и исспользуя другие меры анонимности, после копируем файлы на диск из уже другой ОС, флешку уничтожаем, оперативку перезаписываем много раз.

Как вы храните бекапы со своими gpg ключами?

Здравствуйте, wildwind, Вы писали:

W>Здравствуйте, Буравчик, Вы писали:

Б>> Может использовать старый добрый KeePass: файл KeePass в облаке + длинный мастер-пароль?

W>Кроме того, KeePass может использовать ключевые файлы.

W>Есть только одна проблема. При компрометации или протухании мастер-пароля копии файла в облаках и других местах просто так не уничтожить. Это недостаток не KeePass, а схемы в целом.

Если пароль в файле поменять, то он сменится и в облаке. Но да, резервные копии будут со старым паролем

Здравствуйте, Буравчик, Вы писали:

Б>Если пароль в файле поменять, то он сменится и в облаке. Но да, резервные копии будут со старым паролем

Зачем юзать гуишный keepass, от малоизвестного дева, что не секурно.
люди которые юзают его с первых версий, обновляя программу, полагаясь на дефолтные настройки, могут испытать прилив батхерта, когда попробуют сменить ОС(винду). т.к. в первых версиях keepass исспользовал по умолчанию опцию исспользования данных учетной записи пользователя в ОС(только в виндовой версии) для шифрованию кошелька с паролями, и воостановить такой бекап в новой ОС оказывается очень проблематично, после попыток иммитации подобной учетной записи в новой ос, восстановления регистров, темп папок и прочего, в конце-концов приходиться восстанавливать загрузчик для загрузки старой ос, и если повезет, делать выгрузку паролей, однако потеря на сутки всех своих паролей чувство незабываемое, мотивируя в будущем думать дважды прежде чем юзать подозрительный софт.
`сейчас для паролей юзаю pass — простой врапер над зашифрованными gpg файлами, оч удобно, особенно в компании с git.

вообще хранить конфиденциальную инфу в чужем облаке, как-то странно; особенно когда в софте стоит галочка атообновления.

Здравствуйте, Аноним, Вы писали:

А> Б>Если пароль в файле поменять, то он сменится и в облаке. Но да, резервные копии будут со старым паролем

А> Зачем юзать гуишный keepass, от малоизвестного дева, что не секурно.

Интересный тезис. А чем известен автор pass (кроме того, что у него есть сайт)? И как это добавляет секурности?

А> вообще хранить конфиденциальную инфу в чужем облаке, как-то странно; особенно когда в софте стоит галочка атообновления.

А где лучше хранить? С учетом того, что нужен доступ с нескольких устройств, и любое из них может быть неожиданно сломано/потеряно/украдено/взломано?

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Буравчик, Вы писали:

А>Зачем юзать гуишный keepass, от малоизвестного дева, что не секурно.

ГУИ — в моем случае плюс
Для никсов конечно лучще без gui. Для keepass есть cli, сам не пробовал

А>люди которые юзают его с первых версий, обновляя программу, полагаясь на дефолтные настройки, могут испытать прилив батхерта, когда попробуют сменить ОС(винду). т.к. в первых версиях keepass исспользовал по умолчанию опцию исспользования данных учетной записи пользователя в ОС(только в виндовой версии) для шифрованию кошелька с паролями, и воостановить такой бекап в новой ОС оказывается очень проблематично, после попыток иммитации подобной учетной записи в новой ос, восстановления регистров, темп папок и прочего, в конце-концов приходиться восстанавливать загрузчик для загрузки старой ос, и если повезет, делать выгрузку паролей, однако потеря на сутки всех своих паролей чувство незабываемое, мотивируя в будущем думать дважды прежде чем юзать подозрительный софт.
А>`сейчас для паролей юзаю pass — простой врапер над зашифрованными gpg файлами, оч удобно, особенно в компании с git.

Не знаю, возможно было в старых версиях. Сейчас у меня файл открывается на трех разных компьютерах с разной ОС, вроде ок.

А>вообще хранить конфиденциальную инфу в чужем облаке, как-то странно; особенно когда в софте стоит галочка атообновления.

KeePass под open source GPL2 вроде, поэтому надеюсь совсем больших дыр не засунут. Да и формат файлов открыт.

P.S. Не спорю, что есть более безопасные решения, чем KeePass. Просто предложил вариант, чтобы не "городить огород" (который иногда реально может быть нужен)

Здравствуйте, wildwind, Вы писали:

W>Интересный тезис. А чем известен автор pass (кроме того, что у него есть сайт)? И как это добавляет секурности?
там скриптов c десяток строк, несколько часов читаем, анализируем, всю жизнь пользуемся tree

W>А где лучше хранить? С учетом того, что нужен доступ с нескольких устройств, и любое из них может быть неожиданно сломано/потеряно/украдено/взломано?

т.к. pass отлично работает с git, нам просто надо поднять git репозиторий, закрытый, если уже совсем лень или нет необходимости поднимать свой сервер, можно использовать bitbucket или подобные сервисы и даже настроить репликацию с другими серверами, напр. github, делов на 10 минут, и у нас даже отпадает зависимость от сервера какого-то конкретного поставщика программы.
если устройство будет взломано, злоумышленнику еще придеться взломать приватный gpg ключ который рассшифровывает репозиторий с нашими паролями.
и что бы предупредить такой сценарий событий можно: поднять репозитории с паролями от сайтов, денежных счетов и каки-то серверов с разными приватными ключами, а приватные ключи от этих репозиториев тоже сохранить в репозитории. и на разных устройствах хранить только нужные приватные ключи.

Здравствуйте, Аноним, Вы писали:

А> W>Интересный тезис. А чем известен автор pass (кроме того, что у него есть сайт)? И как это добавляет секурности?

А> там скриптов c десяток строк, несколько часов читаем, анализируем, всю жизнь пользуемся tree

Ты упирал на связь секурности с известностью автора. Или это была просто фигура речи?

А> т.к. pass отлично работает с git, нам просто надо поднять git репозиторий, закрытый, если уже совсем лень или нет необходимости поднимать свой сервер, можно использовать bitbucket или подобные сервисы и даже настроить репликацию с другими серверами, напр. github

То есть таки в облаке.

А> и что бы предупредить такой сценарий событий можно: поднять репозитории с паролями от сайтов, денежных счетов и каки-то серверов с разными приватными ключами, а приватные ключи от этих репозиториев тоже сохранить в репозитории. и на разных устройствах хранить только нужные приватные ключи.

Представляю количество телодвижений для того, чтобы просто зайти на любимый сайт.

P.S. Агрессивное красноглазие detected. Я и сам не прочь покрасноглазить, но все же смысл прогресса в том, чтобы повернуть технологии лицом к обычным людям.

Здравствуйте, wildwind, Вы писали:

W>Ты упирал на связь секурности с известностью автора. Или это была просто фигура речи?

Как фигура речи, когда дело касаеться секурности, то каждая строчка кода в программе должна быть логически обоснована и прокоментированна почему она там присутствует, чем больше будет написано кода тем будет больше вероятность совершить фатальную ошибку/опечатку которая разрушит всю систему.
Автор keepass малоизвестен в нете, т.е. в нете известен тем что написал свою прогу keepass и все, нет публикаций, исследований в области криптографии и прочего.
Для шифрования используется самописная либа: KeePassLib\Cryptography
которая мало того что написанна в .net (потирована из кусков алгоритвом найденных автором в интернетах), т.е. на работу алгоритма может повлиять не предсказуемость .net, GC.
и даже не подтверждена хоть малым колличеством юнит тестов.

W>То есть таки в облаке.
да, это единственна проблема, сделать так что бы владельцы облака не были заинтересованны в брутфорсе зашифрованного архива, лучше всего что бы вообще не знали что у них храниться.

W>Представляю количество телодвижений для того, чтобы просто зайти на любимый сайт.

достаточно написать в консоле, или восспользоваться поиском.
zx2c4@laptop ~ $ pass -c Email/zx2c4.com
Copied Email/jason@zx2c4.com to clipboard. Will clear in 45 seconds.

для наиболее часто посещаемым сайтам можно даже прописать алиас, напр.
alias fb="pass -c Email/zx2c4.com"

т.е. в консоли нам понадобиться написать всего 2 буквы. что бы открыть консоль хоткеем и набрать две буквы. секунды три надо.

В keepass надо сначала восспользоваться поиском, потом глазами отсортировать из десятка, а может даже и больше, если есть похожие удаленные записи в "корзинке",
тыкнуть кнопкой мышки, подождать пока .net сообразит и обновит гуишное окно, клацнуть правой кнопки мышки, снова глазами отсортировать список и наконец нажать кнопку "скопировать в буфер".
секунд 10-15 надо. А когда уставший, то можешь ненароком мышкой перетащить одну ветку в другую или дропнуть запись, а потом тратить время на восстановление.
keepass больше забирает энергии на анализ своих действий пока копируешь пароль в буфер обмена.

Здравствуйте, Аноним, Вы писали:

А> Как фигура речи, когда дело касаеться секурности, то каждая строчка кода в программе должна быть логически обоснована и прокоментированна почему она там присутствует, чем больше будет написано кода тем будет больше вероятность совершить фатальную ошибку/опечатку которая разрушит всю систему.

С этими общими словами трудно не согласиться.

А> Автор keepass малоизвестен в нете, т.е. в нете известен тем что написал свою прогу keepass и все, нет публикаций, исследований в области криптографии и прочего.

Вот эту мысль поясни подробнее. Если у тебя нет исследований и публикаций, то не стоит браться за реализацию криптографии в коде? Прежде чем писать свою программу с криптографией, нужно распиарить себя в интернете? Я не вижу здесь никакой связи. Исследования и написание хорошего кода требуют в общем случае разных навыков.

Приведу контрпример. Авторы TrueCrypt вообще скрывались как могли, а аудит их кода показал, что код нормальный.

Кстати, на сайте KeePass есть пара рекомендаций, которые, полагаю, чего-то стоят:

KeePass is the recommended password manager in the BSI Cyber Security Recommendations BSI-E-CS 001/003 1.4 by the German Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik).

KeePass has received the Certification de Sécurité de Premier Niveau (CSPN) by the French Network and Information Security Agency (Agence Nationale de la Sécurité des Systèmes d'Information, ANSSI).

Ну и для полноты картины, повторю вопрос: чем известен автор pass?

А> Для шифрования используется самописная либа: KeePassLib\Cryptography
А> которая мало того что написанна в .net (потирована из кусков алгоритвом найденных автором в интернетах), т.е. на работу алгоритма может повлиять не предсказуемость .net, GC.

Хочешь сказать, что криптолибы должны быть unmanaged? Первый раз такое слышу, есть какие-то обоснования? По-моему, наоборот, переключения managed-unmanaged и необходимость поддержки нескольких портов либы под разные платформы создают дополнительные риски появления уязвимостей.

А> и даже не подтверждена хоть малым колличеством юнит тестов.

Согласен, хотя может они просто не включили юнит-тесты в дистрибутив.

А> В keepass надо сначала восспользоваться поиском, потом глазами отсортировать из десятка, а может даже и больше, если есть похожие удаленные записи в "корзинке",
А> тыкнуть кнопкой мышки, подождать пока .net сообразит и обновит гуишное окно, клацнуть правой кнопки мышки, снова глазами отсортировать список и наконец нажать кнопку "скопировать в буфер".
А> секунд 10-15 надо.

Нет. Видно, что ты не пользовался KeePass. Оказавшись в форме логина, нужно всего лишь нажать глобальный хоткей.

Здравствуйте, wildwind, Вы писали:

W>Вот эту мысль поясни подробнее. Если у тебя нет исследований и публикаций, то не стоит браться за реализацию криптографии в коде? Прежде чем писать свою программу с криптографией, нужно распиарить себя в интернете? Я не вижу здесь никакой связи. Исследования и написание хорошего кода требуют в общем случае разных навыков.

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

W>Приведу контрпример. Авторы TrueCrypt вообще скрывались как могли, а аудит их кода показал, что код нормальный.
Репутация у программы которая работает с криптографией должна быть идеальной. pdf
pdf 2

W>Кстати, на сайте KeePass есть пара рекомендаций, которые, полагаю, чего-то стоят:
Никогда не слышал об этих организациях и кто там работает.

W>Ну и для полноты картины, повторю вопрос: чем известен автор pass?
неважно кто писал pass, pass это всего-навсего несколько очень простых скриптов, которые помогут более удобно пользоваться программой gnupg для шифрования дерева с паролями , gnupg — это имплементация rfc4880 OpenPGP причем отлично продокументированна, протестированна.

W>Хочешь сказать, что криптолибы должны быть unmanaged? Первый раз такое слышу, есть какие-то обоснования? По-моему, наоборот, переключения managed-unmanaged и необходимость поддержки нескольких портов либы под разные платформы создают дополнительные риски появления уязвимостей.
либа должна быть написана на самом простом языке без излишеств(типа ооп и вирт. машины), который более не меняется, напр. С, т.к предсказуемость выполнения программы важна для правильной работы алгоритмов.

Здравствуйте, Аноним, Вы писали:

А> либа должна быть написана на самом простом языке без излишеств(типа ооп и вирт. машины), который более не меняется, напр. С, т.к предсказуемость выполнения программы важна для правильной работы алгоритмов.

Что-нибудь конкретное есть?

Здравствуйте, wildwind, Вы писали:

W>Что-нибудь конкретное есть?
После того как либа выполнит какую-то работу она должна после себя почистить память.
В пюсах, деструктор, напр. гарантирует что почистит память только в стеке, но не в куче — этим непосредственно должна заниматься сама программа. Если же для завершения программы будет вызвана виндовая функция, тоже не гарантируется даже очистка стека. Некоторые копиляторы могут соптимизировать код, делающий вычисления в локальных переменных функции и выпилить функцию для очистки памяти, напр. memset. И если такая память в последствие попадет в чужую библиотек, секурность будет нарушена.
В отличие от деструкторов плюсов, .net/java вообще не гарантируют что динамическия память сиеминутно будет почищена при вызове Finilize(), а GC впринцыпе вообще не гарантирует что объект будет уничтожен. Если будет выброшено исключение в .net/java программа начнет проходить по стеку вызова и сохранять ссылки на объекты и данные снова остаються в памяти.
секурные данные так же могут очутиться в регистрах процесора, быть слитыми в своп ОС, кеши проца.
На плюсах теоретически тоже можно писать секурную либу, но для этого надо оч. хорошо знать плюсы, во что будет компилиться код и как работать, а кто их, плюсы, знает?

Здравствуйте, Аноним, Вы писали:

А> После того как либа выполнит какую-то работу она должна после себя почистить память.

Что мешает почистить память в деструкторе, просто перезаписав ее чем-нибудь?

А> Если будет выброшено исключение в .net/java программа начнет проходить по стеку вызова и сохранять ссылки на объекты и данные снова остаються в памяти.

Тут да, надо быть внимательным.

А> секурные данные так же могут очутиться в регистрах процесора, быть слитыми в своп ОС, кеши проца.

Это от языка не зависит.

Здравствуйте, wildwind, Вы писали:

W>Что мешает почистить память в деструкторе, просто перезаписав ее чем-нибудь?
Ничего не мешает, только если вызовется системная функция ОС, данные могут не почиститься.

А>> секурные данные так же могут очутиться в регистрах процесора, быть слитыми в своп ОС, кеши проца.
W>Это от языка не зависит.
Не зависит, но не все языки могут норм. с ними работать, надо будет все-равно обращаться к unmanaged коду(для java/.net)

А>Для шифрования используется самописная либа: KeePassLib\Cryptography
А>которая мало того что написанна в .net (потирована из кусков алгоритвом найденных автором в интернетах), т.е. на работу алгоритма может повлиять не предсказуемость .net, GC.

С этого места поподробнее. Вы, вестимо, о KeePass2, который на .NET. Тогда как остальные, если я верно понимаю, о старом добром тёплом ламповом KeePass.

Здравствуйте, SkyDance, Вы писали:

SD>С этого места поподробнее. Вы, вестимо, о KeePass2, который на .NET. Тогда как остальные, если я верно понимаю, о старом добром тёплом ламповом KeePass.
Хм, наверно, вначале дискуссии надо было уточнить версию. keepass 1.x на плюсах написан, keepass 2.x на .net. keepass 1.x вроде как только под виндой работает, а вот еще немного интереного о keepass 2 .

Здравствуйте, SkyDance, Вы писали:

SD> С этого места поподробнее. Вы, вестимо, о KeePass2, который на .NET. Тогда как остальные, если я верно понимаю, о старом добром тёплом ламповом KeePass.

Какая разница, если разработчики одни и те же и обе версии поддерживаются.

А>Хм, наверно, вначале дискуссии надо было уточнить версию. keepass 1.x на плюсах написан, keepass 2.x на .net. keepass 1.x вроде как только под виндой работает, а вот еще немного интереного о keepass 2 .

Обычно если пишут KeePass, подразумевают 1.х. Потому что KeePass2 — это именно KeePass2.
А вообще вы всё перепутали. Как раз 1.х работает на всех платформах. И на винде, и на Линуксе (KeePassX, прямо сейчас пользуюсь — пароль от RSDN там), и на Android (KeePassDroid), и на iPhone. Причем поддерживается софт разными людьми (вопреки сообщению выше).

Зато KeePass2, действительно, ограничен в плане платформ. Не в последнюю очередь "благодаря" C#.

PS: ну и глюкодром на RSDN. Два раза набирал это сообщение. С первого раза вывалилась ошибка и весь набранный текст пропал Неужели нельзя нормально научиться ошибки выводить — вместе с текстом, который идёт в POST.