Криптография *

Европейский Центральный Банк выпустил 55ти страничную публикацию, посвященную исследованию существующих виртуальных платежных систем. В документе подробно рассматриваются в качестве примера валюты Second Life и Bitcoin. Самое интересное, что, во первых, Bitcoin посвящено не менее четверти документа, а, во вторых, выводы исследования кажутся вполне объективными и более того содержат положительную характеристику для этой валюты и системы ее обращения.

Это событие фактически означает официальное признание существование данной валюты, ее состоятельности и платежеспособности. Кроме того открываются перспективы для легализации работы фьючерсных бирж, таких как icbit.se. Последние, к слову, запустили беспоставочные фьючерсные торги на кокаин, золото и нефть

• www.ecb.europa.eu/pub/pdf/other/virtualcurrencyschemes201210en.pdf — сам документ.

Национальный институт стандартов и технологий США (NIST) выбрал победителя в конкурсе криптографических хэш-алгоритмов для стандарта SHA-3. В нём участвовало 64 претендента. Пять финалистов конкурса определились почти два года назад. Победителем стал алгоритм Keccak (читается «кэтчэк» или «кетчак» — устоявшегося варианта русского написания и произношения пока нет), созданный командой криптологов из Италии и Бельгии.

Как сообщает Брюс Шнаер в своём блоге Национальный институт стандартов и технологий США (National Institute of Standards and Technology, NIST) собирается в скором времени представить новый хеш-алгоритм, который будет называться SHA-3.

За право бороться в финале на звание нового SHA-3 NIST выбрало 5 финалистов: BLAKE, Grøstl, JH, Keccak, и Skein. Последний является детищем самого Брюса Шнаера.

Когда на хабре был опубликован пост о том, что компания Stripe проводит конкурс Capture the Flag, я незамедлительно зарегистрировался как участник.

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

Уровни с 0-го по 6-й не представляли особого труда — стандартные SQL- и JavaScript-инъекции, загрузка на сервер PHP-скрипта вместо картинки и т.п.

А вот 7-й уровень заставить меня поломать голову…

Это продолжение темы, поднятой в предыдущем посте о Едином Портале Госуслуг (ЕПГУ) и аппаратных ключах ЭЦП eToken-ГОСТ.
Сначала традиционное описание граблей.

Квест номер 1

После того, как я получил токен, мне захотелось вытащить из него сертификат ключа, чтобы в случае чего отдавать заинтересованным лицам для проверки моей ЭЦП.
Грабля первая — ни SDK 4.55, ни SDK 5.1 не хотели признавать eToken ГОСТ инициализированным и с наличествующим ключом.
Грабля вторая — КриптоПро 3.6 — тоже. Что странно — в бланке сертификата указывалось, что ключ сгенерирован КриптоПро CSP 3.6.
В поисках истины хоть чего-то, что могло бы помочь доступиться до содержимого токена, я набрел на аладдиновский же плагин JC-Web.
Плагин опознавал токен, выдавал SN, список сертификатов числом 1 с ID=3 и названием «Certificate». Но не более. Попытка скормить PIN, или передать данные на подпись вызывали исключение.
Оставалась последняя надежда — расковырять плагин, используемый ЕПГУ для целей авторизации. По сути тот же JC-Web, только сильно проще.
И я полез на сайт Госуслуг.

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

Алгоритм Диффи — Хеллмана позволяет двум сторонам получить общий секретный ключ, используя незащищенный от прослушивания, но защищённый от подмены канал связи. Полученный ключ можно использовать для обмена сообщениями с помощью симметричного шифрования.

Предлагаю ознакомиться с принципом работы алгоритма Диффи – Хеллмана в замечательном видео от Art of the Problem в моем переводе.

Всё нижеописанное относится к физлицам Российской Федерации.

Зачем это надо?

Как вы, возможно, знаете — авторизация на портале госуслуг возможна тремя способами — при помощи логина и пароля (где роль логина играет номер СНИЛС), при помощи USB-ключа ЭЦП (криптографического токена), и при помощи CSP.
Мне проще помнить небольшой ПИН к токену, чем каждый раз держать перед глазами карточку СНИЛС с цифрами номера, и вспоминать пароль (а требования к паролю у ЕПГУ серьезные).Поэтому я решил получить аппаратный токен с ключом ЭЦП.
До кучи — квалифицированую подпись токеном можно использовать и помимо портала госуслуг.

Пользователи игрового форума OwnedCore обнаружили скрытые водяные знаки, которые автоматически внедряются в JPG-файлы, если вы делаете скриншот в игре World of Warcraft. Если сделать скриншот чистой области, открыть файл в IrfanView или каком-нибудь редакторе, увеличить резкость с максимальной настройкой фильтра, повторить процедуру несколько раз, то заметен явный паттерн, который многократно повторяется.

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

В продожение темы взлома Bitcoin-бирж.

Ночью c 4 на 5 сентября ещё одна биржа пала жертвой хакеров. На этот раз объектом атаки стала биржа Bitfloor (№ 4 по объёму в долларах США), которой владеет американец российского происхождения Роман Штильман. Злоумышленникам досталось 24,000 BTC что по текущему курсу составляет около 250 тысяч долларов США.
Как всегда, история взлома довольно загадочна.
31 августа появился неприметный топик о том, что Bitfloor в дауне. Официальный комментарий Романа, — «Не волнуйтесь, всё окей, просто в датацентре выключали электроэнергию (?! а как же резервные источники)», -и уверения всех в том, что с безопасностью проблем нет.
“All funds are secure and things should be operating normally soon.”

Доброго времени суток, уважаемые читатели. Те из вас кто интересуется криптографией наверняка знают, что такое гомоморфное шифрование и для чего оно нужно. Для тех кто пока не понимает о чем речь приведу определение из русскоязычной википедии:

Гомоморфное шифрование — криптографическая система, которая позволяет проводить определенные математические действия с открытым текстом путем произведения операций с зашифрованным текстом.

Долгое время полностью гомоморфная криптосистема оставалась для всех криптографов мира священным Граалем, недостижимым идеалом. И вот в 2009 году Craig Gentry в своей диссертации впервые описал полностью рабочую схему гомоморфного шифрования.
Несколько математических подробностей идеи Gentry а также пример реализации его алгоритма вы найдете под катом.

Приветствую тебя, Хабрачитатель!

Последнее обновление мультипротокольного мобильного клиента IM+ принесло с собой поддержку протокола шифрования OTR (Off-the-Record). Примечательно что функция шифрования доступна независимо от того, каким IM-протоколом вы пользуетесь при общении (OSCAR, Jabber, Gtalk, MSN, YIM или другой).

Основные свойства этого протокола:

• шифрование сообщений — никто иной не сможет прочитать сообщения;
• аутентификация собеседников — уверенность в том, кто является собеседником;
• если потеряны секретные ключи, прошлая переписка не будет скомпрометирована;

С тех пор как в этом году сенатор Джо Мэнчин призвал к «немедленному закрытию» «дерзкого» сайта по продаже запрещенных к свободному обороту веществ Silk Road, одна из самых знаменитых нелегальных аптек в мире не просто выжила. Напротив, с продажами на 22 миллиона долларов в год и двукратными комиссионными для владельцев сайта по сравнению аналогичными показателями шестимесячной давности, черный рынок испытывает просто взрывной рост.

или взломана ещё одна bitcoin-биржа.

“День бабла” продолжается

Итак, на сей раз жертвой хакеров стала биржа BTC-E. Админ биржи оказался скуп на комментарии и в новостях сайта никакого события не значится, но я имел возможность наблюдать за разворачивающимися событиями.

Здравствуйте, хабражители!

В далеком декабре прошлого года я впервые столкнулся с Data Protection Application Programming Interface (сокращенно DPAPI). Тогда я изучал способ хранения логинов/паролей в браузере Chrome. Я обещал, что распишу эту систему подробно и на пальцах. Негоже врать, поэтому добро пожаловать под кат!

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

Метод не предназначен для массового повседневного использования — на подсознательное запоминание пароля требуется около 45 минут тренировки, кроме того, он не даёт особых преимуществ в случае удалённого доступа — злоумышленники всегда могут силой или угрозами заставить пользователя войти в систему. Основное его назначение — физический контроль доступа в закрытые зоны и помещения, например секретные лаборатории или банковские хранилища.

В минувшую пятницу, 13 июля (что очень соответствует общей драматичности ситуации) появилось сообщение от Амира Тааки, что в Биткойнике, где после двух краж только постепенно начался процесс выплат пострадавшим, произошёл ещё один, уже третий по счёту, серьёзный взлом.
Только за этот взлом, без учёта предыдущих, были украдены 40 тысяч BTC (что по сегодняшнему курсу соответствует 332 тысячам долларов США).

Доброе утро, дорогие хабралюди!

Как все мы знаем, пароли следует всегда хэшировать с помощью медленного алгоритма с использованием соли. Чаще всего применяют scrypt, bcrypt или PBKDF2, но этот пост не о том, какой алгоритм использовать. Вместо этого мы поговорим о том, что делать с хэшами дальше.

20- (или 32-) байтовые соль и хэш должны храниться в энергонезависимом, зарезервированном, надёжном хранилище, то есть обычно в реляционной базе данных. Но в каких именно таблицах их хранить? Чаще всего используется таблица со столбцами (user_id, salt, hash) или столбцы salt и hash могут быть в общей таблице Users. В обоих случаях хэш и соль находятся в отношении один-к-одному с пользователями.

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

В детстве меня завораживали детективные или приключенческие книги, в которых героям приходилось взламывать шифры и извлекать спрятанные сообщения из совершенно невинного на вид текста. Впрочем, и сейчас красивый шифр и извилистый путь, которым герой приходит к его разгадке, заставляет мое сердце биться чаще :-) Отчасти поэтому в июне я начала смотреть стенфордский онлайн-курс «Основы криптографии». Первое же практическое задание (взлом шифра одноразового блокнота, неосмотрительно использованного больше одного раза) восхитило меня и подтолкнуло на создание своего собственного zip-квеста по истории криптографии — по тем шифрам, которые ни в коем случае не используются в быту в наше время, но которые так весело взламывать вручную — или почти вручную.

Собственно, вот сам квест. Принцип тот же, что и в новогоднем квесте: на каждом уровне дается задание в виде текстового файла, решив его (то есть взломав шифр), получаем пароль к архиву, в котором лежит следующий уровень. Архив нулевого уровня (cryptoquest.zip) без пароля. В каждом случае зашифрован не только сам пароль, но и достаточно длинное осмысленное сообщение — иначе криптоанализ становится слишком трудоемким.

Здравствуйте. Примерно два года назад на Хабрахабре я из некого комментария познакомился с интересным способом хранения паролей без их сохранения. Фраза выглядит странно, но более точно описать род этой программы мне не получилось. Способ заключается в том, что для получения пароля к конкретной учетной записи на конкретном сайте необходимо загнать в хэш-функцию строку, «склеенную» из мастер-пароля, адреса сайта, и логина на сайте.
keyword+sitename+login
В данной строке keyword – это мастер-пароль, используемый для «хранения» паролей ко всем сайтам. Далее идет адрес сайта, затем логин. Загнав в хэш-функцию данную строку, мы получим на выходе строку символов, которую полностью или частично можно использовать в качестве пароля к данной учетной записи на данном сайте. Ключевое слово в начале строки обеспечивает невозможность узнать пароль, если известны адрес сайта и логин. Длина результата хэш-функции более чем предостаточна для пароля. Но надежность пароля все равно оставляет желать лучшего. Каждый символ такого пароля может принимать только одно 16-ти значений, так как результатом хэш-функции является строка чисел в шестнадцатеричном представлении.
Я попытался исправить этот недостаток. Далее расскажу как.