vitus_wagner: My photo 2005 (Default)
Тут, посколькуо в Debian stable пришла openssl 1.1, из которой ГОСТ-ы из дистрибутива выкинули, [personal profile] beldmit сподвиг меня собрать gost-engine в отдельный пакет

Поэтому теперь на github в организации gost-engine завелись два новых репозитория debpkg и rpm где содержится все необходимое чтобы собрать deb- или rpm- пакеты с gost-engine для систем, где в комплекте идет openssl 1.1.0

Пробовалость пока только под Debian stretch и Fedora 26. Ну и всякие мелочи типа аккуратного заполнения файла copyright еще предстоят.
vitus_wagner: My photo 2005 (Default)
Выяснилось, что stretch я похвалить немного поторопился.

Как оказалось он молча, без вопросов апгрейдит keepass 0.43 на keepass 2.0.3.

Засада в том, что keepass <2 и keepass 2.x это программы у которых нет ничего общего, кроме названия и назначения.

Например, несовместим формат файлов. То есть keepass 2.x умеет один раз симпортировать базу от 1.x но записать обратно - уже никак.

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

Поставил пока пакеты из jessie на hold. И думаю - стоит переходить на keepass 2.x
или не стоит?

Что-то мне все андроидные клиенты, совместимые с keepass2 вызывают подозрение:

У keepass2android интерфейс переписан с java на mono. Это для андроид-то!
KeePassMob содержит в себе код работы с сетью (dropbox), что по-моему для пассворд-менеджера под андроид категорически недопустимо. Поскольку уж если в этой дырявой системе есть способ защититься от доступа в сеть, то именно пассворд-менеджер обязан это сделать.

Поэтому я думаю о том, что может быть стоит еще какой password-manager поискать.

Требования:

1. Наличие клиентов для linux и android
2. Приемлемая usability для android, у которого жутко неудобная работа с clipboard
3. Приемлемая юзабилити под X11.
4. Возможность копирования базы паролей с устройства на устройство как файла по ЛЮБОМУ
протоколу передачи файлов scp, obex, smb.
5. Наличие в базе хотя бы пары дополнительных колонок кроме имя и пароль.
В качестве бонусов:
5. Команд-лайн интерфейс под linux.
6. Возможность хранения базы паролей в version control.
vitus_wagner: My photo 2005 (Default)
Для статьи про постквантовую криптографию: "Revenge of SIDH".

Но, блин, 200мс на 2.6ГГц процессоре.,,
vitus_wagner: My photo 2005 (Default)
https://eprint.iacr.org/2017/351.pdf

Я конечно, считаю что все изделья Бернштейна относятся к категории "может это не практично, согласитесь - эстетично" и не понимаю тех, кто держит qmail в продакшне, да и основная претензия к tox у меня такова - почему они DJB-шную криптобиблиотеку используют, но тем не менее штука забаваная.
vitus_wagner: My photo 2005 (Default)
Что-то я не нашел очевидного (казалось бы) решения по защите хранящегося на (хостинговом, доступном всяким нехорошим людям) сервере почтового архива, которое бы работало так:

1. В распоряжении MDA есть открытый ключ gpg/сертификат X,509 для каждого пользователя.
2. Любое письмо, прилетающее по SMTP (в наше время в норме защищенное TLS по дороге) шифруется этим ключом конечного получателя перед тем, как сложиться в его maildir (но после того как оно прошло через фильтры sieve). Ну да, сеансовый ключ придется каждый раз генерировать. Ну и что?
3. В распоряжении IMAP-сервера есть зашифрованный приватный ключ. Когда пользователь логинится на IMAP-сервер, его аутентификация производится путем расшифровки этого ключа. После этого можно любую хранящуюся почту расшифровывать и пользователю выдавать.


Причем шифровать письма совершенно спокойно можно вместе с заголовками.
То есть и метаинформацию without user consent хрен достанешь.

Модификации требуемые для IMAP-сервера достаточно тривиальные.


Но почему-то никто так не сделал. Во всяком случае я такого не нашел.

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

Видиом, идея full-disk encryption (каковая есть зло) людям глаза застит. В то время как никто не мешает maildir шифровать пофайлово.

Правда, немножко непонятно как быть с тренировкой байесовского антиспама в такой ситуации. Ну ладно, допустим ham мы будем в sa-learn скармливать непосредственно в ходе сессии, когда мы его можем расширфровать (а спам и шифровать не обязательно). Но не явится ли байесовская база, которая должна быть доступна на чтение MDA каналом утечки информации?
vitus_wagner: My photo 2005 (Default)
Задумался над идеей назначать клиентам OpenVPN ip-адреса по значению поля subjectAltName в их сертификатах.
RFC 5280 предусматривает тип поля IP в SubjectAltName, и OpenSSL его вполне поддерживает.

Идея хороша тем, что при подключении нового клиента не нужно вообще ничего делать на сервере. Удостоверяющий центр, выписывая клиенту сертификат (что все равно надо сделать) выделяет ему IP и DNS-имя и прописывает иъ в этот сертификат. А задача сервера - просто согласиться с тем что подписано удостоверяющим центром.

Правда, похоже просто так не получится. Что-то я не вижу там, чтобы client-connect скрипто получил доступ ко всему сертификату или хотя бы к subjectAltName.

Upd Благодаря [personal profile] dzz родилось более простое решение:
Сейчас у меня в скрипте client-connect соответствие CN сертификата клиента и выданного ему IP записывается в динамическую зону DNS. Чтобы на того клиента логиниться по имени.

Так вот - сначала надо в DNS посмотреть, и если там это CN есть, то сказать openvpn-у "этому дай вот этот адрес". А вот уж если адреса такого в DNS нет - назначать первый свободный.
Это, конечно, не гарантирует от того что адрес будет переисиользован пока клиент будет в оффлайне. но все же.
vitus_wagner: My photo 2005 (Default)
[personal profile] beldmit где-то раскопал что стандартный набор персонажей для криптографических сказочек пополнился:

Nancy is the Nation-State attacker interested in mass surveillance and breaking as many protocols as possible rather than breaking any particular single instance of a protocol. Traffic analysis, attacks on entire families of keys, hardware and expertise both well beyond other attackers, subversion of cryptographic standards, using legal force to make otherwise trustworthy Trents and Harolds act in bad faith, etc.

Harold is the manufacturer of hardware like routers and NAT boxes, etc. He is often located in nations with adversarial interests in the
activities of the nations or companies where the hardware gets used.

Считайте меня расистом и чинофобом, но я бы второго из этих персонажей обозвал не Гарольдом, а "дядюшкой Хо".
vitus_wagner: My photo 2005 (Default)
http://spectrum.ieee.org/telecom/security/protecting-gps-from-spoofers-is-critical-to-the-future-of-navigation

Интересная статья в IEEE Spectrum про то как подделывается сигнал GPS и как с этим можно пытаться бороться.

Сюжет

Jan. 23rd, 2016 08:38 am
vitus_wagner: My photo 2005 (Default)
Грустная история о том, как девочка по имени Ева Мэллори попала в какую-то тусовку юных криптографов, не имея не малейшего представления о сложившихся названиях для ролей.
vitus_wagner: My photo 2005 (Default)
Сижу, читаю с утра openssl-dev, никого не трогаю...

И вдруг вижу.

А-а-а, это уже не зомби, это прям личи какие-то атакуют! 2016 год послезавтра, а тут народ активно патчит OpenSSL на предмет сборки DJGPP и работы с Waterloo TCP.

Когда я десять лет назад Tcl 8.5 под DJGPP портировал я уже себя некромантом чувствовал...

Ох, чувствую, ждет нас через 22 года веселое разбирательство в том, в каком количестве унаследованных систем остался 32-битный time_t...
vitus_wagner: My photo 2005 (Default)
http://slashdot.org/story/15/12/09/1438201/alleged-bitcoin-creator-raided-by-australian-authorities

Стоило появиться хотя бы слухам о том, кто такой Сатоши Накомото, как подозреваемого в изобретении биткойна посетила полиция (австралийская) с обыском. Делая невинные глаза и утверждая что "биткойны тут ни при чем, мы по поводу уклонения от налогов" (налогов с чего? Не с половины же запасов мировых биткойнов, которыми, опять же по слухом владеет Сатоши).

А когда я заявлял что Сатоши Накомото не надо появляться живьем на Нобелевской лекции, если он получит премию, а надо читать лекцию по видеосвязи через Tor, мне не верили.
vitus_wagner: My photo 2005 (Default)
Брюс Шнаейр, озабоченный последними нововведениями в US и UK по части ограничений на использование криптографии, которые обозвал Crypto War II, озаботился сбором информации о криптографических продуктах, производимых за пределами этих стран.

По последней ссылке - список из почти двух сотен продуктов для 2/3 которых известна страна разработки.

Вот кто-то импортозамещает, а американцы и англичане готовятся к прямо противоположному - замещению локальных разработок импортом, не связанным национальными ограничениями.
vitus_wagner: My photo 2005 (Default)
Если Сатоши Накомото и правда получит Нобелевку по экономике, то Нобилевскую лекцию ему следует читать по видеосвязи через Tor или i2p, ну и саму премию выплачивать, естественно, должны биткойнами.
vitus_wagner: My photo 2005 (Default)
http://www.telegraph.co.uk/news/uknews/terrorism-in-the-uk/11970391/Internet-firms-to-be-banned-from-offering-out-of-reach-communications-under-new-laws.html

Вернее запретили фирмам предоставлять своим клиентам такие решения в области шифрования, которые нельзя будет вскрыть по запросу полиции. Какие утечки, какие бэкдоры? У невиновных нет оснований подозревать британскую полицию в том что она будет необоснованно вторгаться в их privacy.

Интересно, сколько времени понадобится англичанам для того, чтобы запретить open source?

Потому что OpenSource реализаций OTR имеется штабель. И тут нет никаких "компаний", к которым можно докопаться. Каждый пользователь берет и сам устанавливает (скачав исходник из-за пределов UK, например из US, где это дело первой поправкой покрывается) реализацию OTR.
vitus_wagner: My photo 2005 (Default)
ФБР предлагает платить выкуп владельцам криптолокеров.
Поскольку взломать грамотно зашифрованные файлы ни ФБР, ни NSA не смогут. Я бы на их месте предлагал считать, что носители данных смертны, и от криптолокера также как от сдыхания диска, спасает только своевременный бэкап.
NSA не рекомендует возиться с переходом на EC-криптографию предлагая дождаться появления post-quantum cryptographу, алгоритмов, устойчивых к взлому с помощью квантовых компьютеров. Не знаю что на них нашло. По ссылке там большая и серьезная статья с кучей математики, но как мне показалось, авторы её, рассмотрев кучу вариантов, приходят к тому же выводу.
Директор ЦРУ не в состоянии защитить свой почтовый ящик от тинейджера. Шнайер полагает что это не потому что Бреннан плохо разбирается в компьютерной безопасности и не уверен что смог бы сам успешно противостоять аналогичной атаке. Я тоже не уверен. Хотя я не храню ничего ценного в ящике на gmail-е, и не использую его для восстановления паролей но ведь достаточно determined атакующий может попытаться перехватить аналогичными методами социальной инженерии мой домен wagner.pp.ru и подменить там MX-запись. А за то время, которое мне понадобится, чтобы добиться восстановления контроля над доменом от Руцентра, можно много на каких аккаунтах пароли поменять успеть. Поэтому даже наличие физического контроля над почтовым сервером вообще говоря, не спасает от попыток перехвата электнонной почты. В конце концов, Шнайер описывает атаку на систему с одноразовыми СМС-кодами. Точно такими же методами с перехватом контроля над сим-картой путем социальной инженерии.
vitus_wagner: My photo 2005 (Default)
http://www.mezoamerica.ru/indians/north/warriors_xx04.html

Известно, что во время Второй Мировой американцы использовали индейцев в качестве радистов-шифровальщиков. И расшифровать переговоры на языке навахо было куда труднее, чем взломать "Энигму".

По ссылке большая статья про то, как именно это работало. В частности, как втискивалась военная терминология индустриальной эпохи (включая географические названия) в язык маленького индейского пленмени.
vitus_wagner: My photo 2005 (Default)
Попробовал воспользоваться выданным на работе eToken для доступа на линукс-машину по ssh.

Естественно, на машине, куда я втыкал токен, уже установлен Safenet Authentication Client, родной софт от производителя токена, который содержит PKCS11-модуль libeTPkcs11.so. С его помощью можно использовать этот токен в firefox-е и еще много где, причем с ключами и сертификатами, созданными виндовым софтом.
Интерес представляло, насколько хорошо поддержка pkcs11 интегрирована в OpenSSH.

Наибольшую сложность составило почему-то преобразование открытого ключа, извлеченного из сертификата средствами OpenSSL в формат openssh-вого identity.pub. Команда

ssh-keygen -i -m pem -f filename.pem


злобно ругается на нераспознаваемый формат.

Это потому что, openssl полностью перешла на PKCS8 форматы а под pem в опции -m ssh-keygen понимается старый формат.

Правильная команда выглядит как

openssl x509 -in fromtoken.crt -noout -pubkey >filename.pem
ssh-keygen -i -m PKCS8 -f filename.pem


Получить старый формат средствами OpenSSL можно, Для этого в команде rsa есть ключик -RSAPublicKey_out
Можно взять ключик, выдрранный командой x509 (выше) из сертификата и сконвертировать.

Сертификат из токена достается командой:
pkcs11-tool --module libeTPkcs11.so --type cert --id <какой-там-у-вас-id> --read-object


Эта команда выдает сертификат в формате der на stdout, поэтому надо либо переназначить в файл, либо сразу направлять в openssl x509, не забыв ей сказать -inform DER.

Пин-кода чтение сертификата по очевидным причинам не спрашивает.

После того, как ключ получен и положен куда надо в authorized_keys дальше все просто:

Либо

ssh -I libeTPkcs11.so куда.надо

и мы попадаем на нужный хост, одноразово обратившись к токену.

Либо

ssh-add -s libeTPkcs11.so


и золотой ключик у вас в агенте. В обоих случаях, конечно PIN спросят.

Агент нормально переживает внезапное выдергивание токена. Правда, ключ в списке остается.
Что интересно, при попытке его удалить (командой
ssh-agent -e libeTPkcs11.so
спрашивают пассфразу.
При выдернутом токене.

Поиграться что-ли еще с pam-pkcs11?

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

Кроме того, в состав pkcs11 входит pkcs11_eventmgr, который позволяет, например, лочить экран при выдергивании токена. Интересно, удастся ли сделать так, чтобы ssh-agent при выдергивании токена "забывал" пассфразу от него, но когда после вставления токена она вводится в screensaver, получал бы ее оттуда средствами pam.
vitus_wagner: My photo 2005 (Default)
Погонял сегодня ctypescrypto на разных платформах (после того как мне отрепортили баг, что на MacOS у меня динамическая библиотека неправильно ищется)

Под Windows пришлось поправить 1 тест. Любимая моя привычка - создавать временный файл и не закрывать. А потом удивляться - а что это на некторых платформах его по второму разу открыть не могут.

Под linx/armhf - ну даже не интересно.

Под pypy - работает. Сходу.

Под python3 - ожидаемо не работает. Для модуля который активно работает как с байтами, так и с юникодом, это неудивительно. Вопрос в том, а можно ли принципиально сделать этот модуль таким, чтобы был совместим с обоими версиями. По-моему нет.
Потому что полно объектов, у которых определены методы __str__ и __unicode__, которые должны быть переименованы, соответственно, в __bytes__ и __str__
vitus_wagner: My photo 2005 (Default)
Вообще. интересно, а можно ли сделать протокол, обеспечивающий надежную криптографическую защиту от инжекции или подмены данных, но без шифрования, и при этом экономящий ресурсы более чем вдвое, по сравнению с полноценным TLS.

Про существование в TLS ciphersuit-ов с NULL-шифрованием я в курсе.

Там как раз получается, что остается только (H)MAC для контроля целостности.
Поскольку затраты на вычисление MAC и на шифрование сравнимы, то экономия на длинных сессиях (а речь в предыдущем посте шла про rsync) примерно вдвое.

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

Вычисление криптографически защищенной контрольной суммы сильно дешевле шифрования не будет.

Но есть ведь альтшуллеровский подход - когда подсистемы нет, а функция её выполняется.

Вот, например, тот же rsync считает контрольные суммы с целью проверки, а надо ли вообще этот блок передавать, или он не менялся. Соответственно, если там не просто хэш, а (H)MAC, то приехали - инжекция невозможна - прежде чем обмениваться данными, стороны обменялись MAC-ом. (правда, я не уверен, что в rsync передается хэш от новых данных, а не от старых. С точки зрения заведомо надежного канала это логично - передавать хэш-сумму посчитанную получателем, чтобы отправитель мог принять решение - слать или не слать блок).
vitus_wagner: My photo 2005 (Default)
Попробовал тут поставить putty посвежее, текущий снапшот, и выяснил что генерировать ключи с нормальным алгоритмом puttygen уже научили, а вот работать с ними - ни pageant, ни сам putty - нет.

pageant ругается на invalid format, a putty просто молча игнорирует и пытается аутентифицироваться с паролем (чего, конечно, ему никто не позволяет)

Profile

vitus_wagner: My photo 2005 (Default)
vitus_wagner

August 2017

S M T W T F S
  1 2 3 45
6 78 9 10 11 12
13 14 1516171819
20212223242526
2728293031  

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Aug. 17th, 2017 01:42 pm
Powered by Dreamwidth Studios