Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 62
Спасибо за статью. Всем заинтересовавшимся хабравчанам рекомендую курс Cryptography I, который начался неделю назад.
Замечательный курс. Очень жаль, что его продолжение уже два года задерживают.
Да нет. Уже есть и Cryptography II
Если мы можем подавать какому-то сервису шифротексты, а он будет возвращать нам информацию, корректно ли дополнение — мы сможем вскрыть ЛЮБОЙ шифротекст.
Так по этим дополнениям и выясняют, нормально ли расшифровалось или нет. Ну и вообще CBC такая штука, что даже если в какой то блок внесут изменения, то уже через 1 блок всё нивелируется, толку от него немного. Давно пора использовать более совершенные режимы
Плюс ко всему — CBC не распараллеливается. Имхо в современном мире, CTR куда более актуален.
Этих режимов огромное множество. Я выделил бы GCM или OCB (но на него вроде патент есть).
Как раз CTR один из самых уязвимых режимов работы, google в помощь ctr cipher mode vulnerability.
И если говорить формально, то распараллеливаются не режимы работы, а базовые циклы конкретного симметричного шифра.
И если говорить формально, то распараллеливаются не режимы работы, а базовые циклы конкретного симметричного шифра.
Почему это CTR стал одним из самых уязвимых? И вообще, что такое «самый уязвимый»? Режим или фундаментально уязвимый, как ECB, или неуязвимый, при правильном использовании.
Школота минусует, я смотрю, ну вперед, продолжайте в том же духе.
Как вы правильно подметили, при «правильном» использовании. Вот пример tools.ietf.org/html/draft-ietf-ipsec-ciph-aes-ctr-00. Опять же сам факт неправильного использования сводит на нет все преимущества использования такого режима. Найдите в рекомендуемых параметрах SSL например вот здесь wiki.mozilla.org/Security/Server_Side_TLS хоть один CTR режим.
+ вот еще ссылка www.nsa.gov/ia/programs/suiteb_cryptography/
The Galois/Counter Mode (GCM) is the preferred AES mode.
Для общего развития можно почитать habrahabr.ru/post/120096/
Как вы правильно подметили, при «правильном» использовании. Вот пример tools.ietf.org/html/draft-ietf-ipsec-ciph-aes-ctr-00. Опять же сам факт неправильного использования сводит на нет все преимущества использования такого режима. Найдите в рекомендуемых параметрах SSL например вот здесь wiki.mozilla.org/Security/Server_Side_TLS хоть один CTR режим.
+ вот еще ссылка www.nsa.gov/ia/programs/suiteb_cryptography/
The Galois/Counter Mode (GCM) is the preferred AES mode.
Для общего развития можно почитать habrahabr.ru/post/120096/
Спасибо за ссылку на tools.ietf.org. Но Вам не кажется, что «волков бояться — в лес не ходить?». Например для шифрования сессии с одноразовым ключём, переданным асимметрично, и для счётчика, инициализированным для этой же самой сессии — велик ли риск повтора значений?
А по-поводу TLS, вот хорошее описание ситуации: crypto.stackexchange.com/questions/11307/what-is-wrong-with-aes-ctr-hmac-sha256-or-why-is-it-not-in-tls
А по-поводу TLS, вот хорошее описание ситуации: crypto.stackexchange.com/questions/11307/what-is-wrong-with-aes-ctr-hmac-sha256-or-why-is-it-not-in-tls
Любое шифрование и любой режим работы шифра использовать бессмысленно, если оно применяется неправильно.
По вашим ссылкам нет CTR просто потому что CBC — более старый и «проверенный» режим. Зато там есть такие шифры, как RC4 и 3DES.
И CBC, и CTR подвержены элементарным атакам на целостность данных, поэтому в чистом виде не используются. Но если добавить код проверки аутентичности сообщения GMAC к режиму работы блочного шифра CTR, получится… режим GCM, который рекламируется самим NSA и вами.
По вашим ссылкам нет CTR просто потому что CBC — более старый и «проверенный» режим. Зато там есть такие шифры, как RC4 и 3DES.
И CBC, и CTR подвержены элементарным атакам на целостность данных, поэтому в чистом виде не используются. Но если добавить код проверки аутентичности сообщения GMAC к режиму работы блочного шифра CTR, получится… режим GCM, который рекламируется самим NSA и вами.
Чувствуется, что беседа заходит в тупик, и пропадает всякое желание тратить свое время на ни к чему не ведущую полемику. Где вы нашли RC4 и 3DES? На всякий случай, восклицательный знак стоит трактовать как «кроме». Я ничего никому не рекламирую, но призываю думать, и разумеется, без фанатизма.
P.S.
“Just because you're paranoid doesn't mean they aren't after you”
P.S.
“Just because you're paranoid doesn't mean they aren't after you”
Здесь написано, что RC4 использовался раньше, но сейчас удален, а 3DES оставлен для обратной совместимости т.е. где-то в глубинах интернета применяется.
Вы утверждали, что CTR — «самый уязвимый режим работы», при этом, цитировали NSA, которая рекомендует везде использовать GCM. В GCM непосредственно для шифрования используется чистый режим CTR. GMAC, превращающий CTR в GCM, напомню, предоставляет защиту только от фальсификации данных и на другие криптографические свойства режима не влияет.
Можете посмотреть схему работы GCM, чтобы в этом убедиться.
Вы утверждали, что CTR — «самый уязвимый режим работы», при этом, цитировали NSA, которая рекомендует везде использовать GCM. В GCM непосредственно для шифрования используется чистый режим CTR. GMAC, превращающий CTR в GCM, напомню, предоставляет защиту только от фальсификации данных и на другие криптографические свойства режима не влияет.
Можете посмотреть схему работы GCM, чтобы в этом убедиться.
Проверил, какой режим используется у меня в SSH (две машинки со стабильным дебианом) и нашёл aes128-ctr. Неужели в одной из ключевых программ в стабильном дебиане используют один из самых уязвимых режимов?
Позвольте не согласиться по поводу уязвимости. CTR ничем не хуже других, если его правильно использовать — не повторять значения счётчика для сообщений зашифрованных одним и тем же ключём (ага, для 128битного ключа это делает ~ 10^38 уникальных значений).
В CTR, в отличие от CBC, на вход шифра подается счетчик, содержимое которого достаточно строго детерменировано. В CBC на вход шифра подается непосредственно ciphertext, что требует от шифра правильной работы при любых входных данных. Это свойство malleability шифров достаточно часто использовалось для атак на шифры в режиме CBC, но абсолютно не затрагивало CTR. Из конкретных примеров: www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/
Насчет параллелизации, я не знаю, что вы пытались сказать словом «формально», но как раз параллелизация шифрации блоков данных — это как раз очень важное свойство CTR режима, а не конкретных PRF, используемых в этом режиме. В CBC параллелизуется только дешифрация блоков.
Насчет параллелизации, я не знаю, что вы пытались сказать словом «формально», но как раз параллелизация шифрации блоков данных — это как раз очень важное свойство CTR режима, а не конкретных PRF, используемых в этом режиме. В CBC параллелизуется только дешифрация блоков.
CBC такая штука, что даже если в какой то блок внесут изменения, то уже через 1 блок всё нивелируется, толку от него немного. Давно пора использовать более совершенные режимы
Разобраться в трёх режимах (CBC, OFB, CFB) мне помогла статья на opennet.ru.
В итоге в Пандоре я перешёл с CBC на CFB.
С практической точки зрения я чувствую достаточную уверенность пересылая зашифрованный gpg файл (gpg -c) через ssh-соединение внутри vpn-туннеля, работающего на pki-ssl.
С практической точки зрения возможно будет проще взломать ваш ПК, с которого вы всё это проделываете. Софта много, багов много.
Для этого надо иметь доступ к софту.
Тройное шифрование — это не защита от targeted атаки, а от сниффинга трафика с последующим «ой, есть эксплоит, позволяющий расковырять трафик». То есть защита против чего-то уровня xkeycode, а не directed attack.
Тройное шифрование — это не защита от targeted атаки, а от сниффинга трафика с последующим «ой, есть эксплоит, позволяющий расковырять трафик». То есть защита против чего-то уровня xkeycode, а не directed attack.
А вы знаете, какой алгоритм используется по умолчанию для шифрования в GPG?
The default symmetric cipher used is CAST5, but may be chosen with the --cipher-algo option.
А так, да, крипто-карго-культ. Сырцы gpg я не читал, в ssh только заглядывал (не в криптосекцию), openvpn тоже не читал.
А так, да, крипто-карго-культ. Сырцы gpg я не читал, в ssh только заглядывал (не в криптосекцию), openvpn тоже не читал.
А зачем используете -c? Почему не ключи?
Чтобы потом расшифровать можно было «из головы». Это очень полезно, когда хоть что-то не хранится в машиночитаемом виде.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
А как вы говорите красным тогда? Или это только для шифрования файлов?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: https://keybase.io/valdikss
iQIcBAEBCAAGBQJUs6l/AAoJEFzXIC7viPdyFMIP/0U5EkPxuB7irQUvBi//4inA
CmRCzmFrNPswHK+SFTm5IuU2Or8y9DZkr6BGY/qr+9zXikkA2fHQvKH+Ai5SAxUs
dilz1i2ZW3W+x8m2GH1I7ahYvB6oYsmPPph7O7SoRUbIW6/NtHYi0R5/MYP8FPKB
a1H8jkNglE2HPwJNErKH8P3I0cACXaN991sXCFFldm8lE0fLkFfAUgVQJNsvDrcS
Bj8Boc1x7GtGHZPyqXFPI0+1faqfD+6tWD9E7A9H5ck2DOoLYFg04aU7FLHZWC1e
brZJj9oHRe+v87ImBieN1YIGi2kzqHsqej59lJ+HJ0r5r7wKxUktj+Q6GkBb2BrB
PpbWcQeST9E6Hdf1mKWM1OG+gG0E4KlK7gAYPzGdYjwGTBy/PxEO4GMpt1nlGHHV
B/v4Om7HdlF2IzUxmz6knTs2bgJuX2LGYUyVUHwO+SZPBrnXLD03uWUGZQEfV+91
3wRSd/9+TZcYMTAQ/VimFAl51rlfUA0krLXx/DqRyO6QERvB4WRNkX7UhgMiL+sb
QZ2GRmLv0CixdYTOmMTrsPhEhP6iMBKBCBSGqI2vTxRL+GEZPKyS95ze55COS97L
Gd7zJpL46HO1m90CGrkP+CKvXltGMQ4+luR7xuQgSIUf09nB8yu/aZr4mh13Vqon
4w/XdsgDO9XyBVWiR7d0
=7FaC
-----END PGP SIGNATURE-----
У меня (arch, gnupg 2.1.1, libgcrypt 1.6.2, gnutls 3.3.11) в мане пишут "-с Encrypt with a symmetric cipher using a passphrase. The default symmetric cipher used is AES128, but may be chosen with the --cipher-algo option." Параметры сборки gnupg, libgcrypt и gnutls обычные, ничего специфичного по симметричному шифру по умолчанию не видно на первый взгляд.
Видимо, настройка по умолчанию менялась, т. к. сейчас в www.gnupg.org/documentation/manuals/gnupg/Operational-GPG-Commands.html указан aes128, а в 2011 году в рассылке говорилось, что там cast5 (см lists.gnupg.org/pipermail/gnupg-users/2011-January/040276.html)
Видимо, настройка по умолчанию менялась, т. к. сейчас в www.gnupg.org/documentation/manuals/gnupg/Operational-GPG-Commands.html указан aes128, а в 2011 году в рассылке говорилось, что там cast5 (см lists.gnupg.org/pipermail/gnupg-users/2011-January/040276.html)
Предлагаю такое решение: ноут шифруется паролем и ключом (для расшифрования нужны оба). Пароль человек хранит в голове, ключ автоматически подцепляется с удалённого сервера во время загрузки. (На хабре была статья, в которой предлагалась практическая реализация такой схемы, но не могу её найти.) На удалённом сервере в cron установлен скрипт, который ежедневно удаляет ключ, если человек не отменил это действие явно. (Примерно таким же способом L сделал оповещение о своей смерти.) Если человека хватают, то его задача продержаться первые сутки, а потом уже никто не сможет восстановить информацию.
От кого вы защищаетесь? Модель атаки какая?
Это попытка защититься от правой части комикса: есть данные, которые допустимо потерять, но абсолютно недопустимо, чтобы они попали в чужие руки (вариант задачи: чтобы нельзя доказать наличие этих данных у пользователя). При этом пользователь допускает, что атакующий может применять жесткие методы, включая те же наркотики, но сначала будет пытаться получить данные по-хорошему (за это время ключ и испарится). Важный момент: удалённый сервер не делает бекапов, а ещё лучше, чтобы был устойчив перед всеми возможными атакующими.
Во-первых, люди, готовые использовать наркотики и насилие — не будут ждать сутки.
Во-вторых, ничего вы никому не объясните — вас будут продолжать колоть и бить, бить и колоть.
В-третьих, когда вы наконец объясните свою супер-хитрую схему — ну, забьют вас окончательно и всё на этом.
Повторим вопрос: от кого вы защищаетесь?
Во-вторых, ничего вы никому не объясните — вас будут продолжать колоть и бить, бить и колоть.
В-третьих, когда вы наконец объясните свою супер-хитрую схему — ну, забьют вас окончательно и всё на этом.
Повторим вопрос: от кого вы защищаетесь?
Повторю ответ: защита от получения противником доступа к данным, любой ценой.
Объяснять схему насильникам как раз не нужно, так как они успеют добраться до сервера до того, как он сотрёт ключ. Задача спасти данные, а не себя (тем более, всё равно могут убить, как вы отметили).
Примерный вариант практического применения. Допустим, есть юридическая фирма с филиалами по всему миру, в том числе в странах с полицейским произволом. Как предотватить захват данных местными правоохранителями и заодно уничтожить какие-либо доказательства касательно сотрудников филиала? Напрашивается именно такая схема: сервер в филиале зашифровывается паролем, который знает сотрудник филиала, и ключом, который каждый раз прилетает из центрального офиса. Сотрудника можно захватить и выпытать из него пароль, но в центре за это время узнают и отключат отправку пароля. Теперь представим, что никакого центра нет, а есть удалённый сервер, на котором ключ сотрётся автоматически через сутки.
Похожая схема может применяться политическими активистами и разведчиками.
Объяснять схему насильникам как раз не нужно, так как они успеют добраться до сервера до того, как он сотрёт ключ. Задача спасти данные, а не себя (тем более, всё равно могут убить, как вы отметили).
Примерный вариант практического применения. Допустим, есть юридическая фирма с филиалами по всему миру, в том числе в странах с полицейским произволом. Как предотватить захват данных местными правоохранителями и заодно уничтожить какие-либо доказательства касательно сотрудников филиала? Напрашивается именно такая схема: сервер в филиале зашифровывается паролем, который знает сотрудник филиала, и ключом, который каждый раз прилетает из центрального офиса. Сотрудника можно захватить и выпытать из него пароль, но в центре за это время узнают и отключат отправку пароля. Теперь представим, что никакого центра нет, а есть удалённый сервер, на котором ключ сотрётся автоматически через сутки.
Похожая схема может применяться политическими активистами и разведчиками.
А кто сотрет данные из головы сотрудника филиала?
Из данных, представляющих интерес для неприятеля, у него в голове есть только пароль, ставший бесполезным. Данные как таковые содержатся на этом зашифрованном сервере филиала и понемногу в головах остальных сотрудников. Их всех отлавливать и пытать — не вариант, тем более неизвестно, кто что знает. А вот сразу все данные с сервера были бы ценной добычей. Кстати, если многие будут применять такую схему, то и захваты сотрудников прекратятся — зачем захватывать, если до данных всё равно не добраться.
Из данных, представляющих интерес для неприятеля, у него в голове есть только пароль, ставший бесполезным
Такое может быть только в том случае, когда с данными никто не работает. В выбранном государстве, по крайней мере. Но раз данные есть и есть задача их защитить, значит с ними работают.
Данные как таковые содержатся на этом зашифрованном сервере филиала и понемногу в головах остальных сотрудников. Их всех отлавливать и пытать — не вариант, тем более неизвестно, кто что знает. А вот сразу все данные с сервера были бы ценной добычей.
В совокупности все сотрудники будут знать обо всех данных, с которыми они работали. Игнорировать такой ценный источник информации глупо. И отсутствие информации о том, кто с какими данными работал, – это препятствие, но лишь до тех пор, пока атакующий не будет принуждать к раскрытию всей имеющейся у людей информации или пока один сотрудник не расскажет о том, что знают другие.
Кстати, если многие будут применять такую схему, то и захваты сотрудников прекратятся — зачем захватывать, если до данных всё равно не добраться.
Типичная попытка решить нетехническую проблему исключительно техническими методами. Можно уничтожить криптографический ключ, можно уничтожить компьютерную информацию, но заставить человека не раскрывать информацию можно лишь одним способом. Пока с данными будут работать люди, именно эти люди и будут одним из самых слабых звеньев, вне зависимости от применяемых технических средств. Разумеется, можно каким-то способом подставить под удар сотрудника, который только вводит пароль, а с данными не работает, но такая попытка решения поставленной задачи носит сугубо организационный характер (основная проблема – как организовать работу с данными и людьми, а не какое шифровальное средство выбрать и в каком режиме его использовать).
Чтобы данные были в безопасности, надо прокачать и людей, и технику. Мне кажется более важной техническая сторона, а вам, судя по всему, человеческая, но они обе обязательны в нормальной схеме. Согласитесь, что грош цена любой схеме, в которой данные хранят и передают в незашифрованном виде, даже если сотрудники строго следуют уставу и устойчивы к пыткам.
Чтобы не ходить далеко за примером, рассмотрим известный Силк Роад, в гибели которого виновата именно техническая сторона, а не социальная. Ни один из «сотрудников» (кроме владельца) не знал слишком много, но на сервере хранилось всё. Подкачала техническая реализация, из-за чего неприятель и добрался до сервера, а потом и до владельца и его биткоинова теперь продаёт их оптом.
Чтобы не ходить далеко за примером, рассмотрим известный Силк Роад, в гибели которого виновата именно техническая сторона, а не социальная. Ни один из «сотрудников» (кроме владельца) не знал слишком много, но на сервере хранилось всё. Подкачала техническая реализация, из-за чего неприятель и добрался до сервера, а потом и до владельца и его биткоинов
Что это за «юридическая фирма с филиалами по всему миру», ради данных которой сотрудникам предлагается аж жизнью жертвовать? Это вообще глупо предполагать, что кто-то (а хоть бы и ты сам) отдаст жизнь или здоровье ради каких-то там данных. Реализовывать такую схему — опасно и глупо.
«Абсолютно» не бывает, и в простейшем случае я оцениваю ценность всех моих данных, включая те, которые я старательно скрываю, в пару фингалов. Ну ладно, в одну сломанную кость, если включить сюда все пароли от всех аккаунтов.
Для меня это тоже было бы весомым аргументом. Поэтому и придумали анонимность — чтобы не было ясно, кому ставить фингал. Мало кто способен противостоять пыткам, вот мне и захотелось придумать схему, устойчивую к таким ситуациям. Выше я привёл примерный сценарий использования. В общем случае это можно свести к ситуациям, когда вам дают доступ к чужим важным данным и хотят защитить данные от того, что кто-то выпытает у вас пароль.
Обидно, что человека в итоге могут запытать до смерти, но какие ещё варианты решения можно предложить, когда преступники ловят сотрудника и ставят выбор данные или жизнь, а данные организация отдать никак не может. Допустимо ли рисковать жизнью одного сотрудника ради сохранности данных компании?
Обидно, что человека в итоге могут запытать до смерти, но какие ещё варианты решения можно предложить, когда преступники ловят сотрудника и ставят выбор данные или жизнь, а данные организация отдать никак не может. Допустимо ли рисковать жизнью одного сотрудника ради сохранности данных компании?
Отдать данные и не париться. Под шумок можно набрать что-нибудь аварийное на телефоне с выключенным звуком.
Вообще, я не понимаю, каким образом криптографические воздушные замки могут помочь, когда «пришли». Меньше рыпаешься — больше шансов, что обойдётся.
Вообще, я не понимаю, каким образом криптографические воздушные замки могут помочь, когда «пришли». Меньше рыпаешься — больше шансов, что обойдётся.
Если я правильно понял, вы предлагаете набрать на телефоне команду аварийного уничтожения данных. Это и есть «рыпаться» и не всегда возможно, а если заметят, то костей сломают больше. По-моему, надежнее, если данные будут уничтожены сами собой при полном бездействии как пользователя, так и захваченного оборудования (допустим, пользователя неожиданно схватили и отобрали телефон, а компьютер вынесли). Такая схема напоминает свидетельство канарейки тем, что действие вызвано бездействием.
Про «отдать данные и не париться» я уже писал. Если для отдельного человека это выглядит самым логичным вариантом, если он не маньяк, то в компании могут предпочесть спасти данные, а не захваченного сотрудника. Сделать так, чтобы с момента похищения сотрудник не мог предать компанию, даже если его будут пытать.
Про «отдать данные и не париться» я уже писал. Если для отдельного человека это выглядит самым логичным вариантом, если он не маньяк, то в компании могут предпочесть спасти данные, а не захваченного сотрудника. Сделать так, чтобы с момента похищения сотрудник не мог предать компанию, даже если его будут пытать.
Нет, я предлагаю набрать 112, выключить звук и оставить «как есть».
Насчёт «страдать для компании» — извините, в условиях силовой конфронтации я отдам все пароли без дополнительного стресса. А в компании, «в которой предпочтут спасти данные» я предпочту не работать.
Насчёт «страдать для компании» — извините, в условиях силовой конфронтации я отдам все пароли без дополнительного стресса. А в компании, «в которой предпочтут спасти данные» я предпочту не работать.
Нет, я предлагаю набрать 112, выключить звук и оставить «как есть».Хороший вариант, но что если напавшие сами работают в правоохранительных органах?
А в компании, «в которой предпочтут спасти данные» я предпочту не работать.А другой согласится. Люди соглашаются и в боевых действиях участвовать, была бы достойная оплата и склад характера. Предложенная схема не является серебряной пулей, но некоторым, без сомнения, может пригодиться. Разумеется, большинство компаний готовы отдать все данные человеку с автоматом и им такая схема не нужна.
Этот комикс был нарисован в эпоху воображения криптоманьяков. После Сноудена это не воображение, а суровая реальность — если мой трафик идёт в США, то с высокой вероятностью он пишется на жёсткие диски NSA. И мне не хочется, чтобы они из-за нелепой дырке в протоколе могли эти файлы прочитать.
… используя всезде один и тот же ключ.
Начнем с того, что мы заполним C1'[1..15] случайными байтами, а C1'[16] заполним нулем (0x00). Теперь подадим C1' + C2 серверу. Если сервер ответит, что дополнение получилось корректное, то мы можем быть уверены (с большой вероятностью), что P2'[16] равно 0x01 (т.к. дополнение корректно). Если сервер отвечает ошибкой — посылаем сообщение с C1'[16], установленным в 0x01, затем в 0x02 и.т.д. пока не получим нужный нам ответ.
нипонятно, почему p2[16] должен быть равен 0x01
нипонятно, почему p2[16] должен быть равен 0x01
Теперь мы можем быть уверены, что P2' будет заканчиваться на 0x02, и поэтому единственный вариант, при котором P2' будет иметь корректное дополнение — если P2[16] == 0x02.
15й байт, а не 16й, т.е. P2[15] == 0x02.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Padding Oracle Attack или почему криптография пугает