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

Привет, %username%!
Многим известно, что стандартом по умолчанию в области симметричного шифрования долгое время считался алгоритм DES. Первая успешная атака на этот неубиваемый алгоритм была опубликована в 1993 году, спустя 16 лет после принятия его в качестве стандарта. Метод, который автор назвал линейным криптоанализом, при наличии 2⁴⁷ пар открытых/зашифрованных текстов, позволяет вскрыть секретный ключ шифра DES за 2⁴³ операций.
Под катом я попытаюсь кратко изложить основные моменты этой атаки.

Шифр FEAL обладает таким же уровнем стойкости что и DES. Более того, увеличенная длина ключа (64 бита по сравнению с 56 битами в DES) затрудняет возможность перебора. Шифр FEAL обладает хорошим распределением шифротекстов, близким к случайному. И это тоже говорит в пользу FEAL по сравнению с DES.

Это краткое содержание спецификации алгоритма шифрования FEAL, опубликованного в 1987 году.

Ничто не вечно под луной. В данном топике я расскажу как при наличии всего 40 пар открытых-закрытых текстов получить полный ключ FEAL4 за несколько минут.

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

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

В далекие времена, для IT-индустрии это 70-е годы прошлого века, ученые-математики (так раньше назывались программисты) сражались как Дон-Кихоты в неравном бою с компьютерами, которые тогда были размером с маленькие ветряные мельницы. Задачи ставились серьезные: поиск вражеских подлодок в океане по снимкам с орбиты, расчет баллистики ракет дальнего действия, и прочее. Для их решения компьютер должен оперировать действительными числами, которых, как известно, континуум, тогда как память конечна. Поэтому приходится отображать этот континуум на конечное множество нулей и единиц. В поисках компромисса между скоростью, размером и точностью представления ученые предложили числа с плавающей запятой (или плавающей точкой, если по-буржуйски).

Арифметика с плавающей запятой почему-то считается экзотической областью компьютерных наук, учитывая, что соответствующие типы данных присутствуют в каждом языке программирования. Я сам, если честно, никогда не придавал особого значения компьютерной арифметике, пока решая одну и ту же задачу на CPU и GPU получил разный результат. Оказалось, что в потайных углах этой области скрываются очень любопытные и странные явления: некоммутативность и неассоциативность арифметических операций, ноль со знаком, разность неравных чисел дает ноль, и прочее. Корни этого айсберга уходят глубоко в математику, а я под катом постараюсь обрисовать лишь то, что лежит на поверхности.

Не так давно, была опубликована статья «Пастильда — открытый аппаратный менеджер паролей». Так как данный проект является открытым, то мы решили, что будет интересно, если мы будем писать небольшие заметки о процессе проектирования, о задачах, которые перед нами стоят и о трудностях, с которыми мы сталкиваемся.

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

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

Данный функционал является скелетом нашего проекта, поэтому первая заметка будет посвящена именно ему.

Иногда сложно найти в Сети правильные, а главное актуальные «best practices» для языка. Документация, конечно же, содержит всю необходимую информацию, но отсеять нужную вещь в абзацах подробного (на то она и документация) описания довольно сложно. Но недавно мне улыбнулся поиск Google, и я наткнулся на очень полезные «паттерны» языка Python от одного из core разработчиков — Raymond Hettinger.

Примечание: Все рекомендации даны в нескольких вариантах: сначала идут самые «плохие» варианты, а дальше предлагается лучшая альтернатива. Актуально для версии языка 2.7, отличия для версии 3.3 читайте в примечаниях к конкретному «паттерну».

С некоторых пор фирма Segger предлагает технологию Real Time Terminal (RTT) для своих JTAG адаптеров J-Link. Суть ее в том, что программа на микроконтроллере может выводить и принимать отладочную информацию из JTAG/SWJ-DP порта, как это обычно делается через UART. И тогда нам больше не нужен реальный отладочный UART. Далее чуть подробнее о возможностях этой технологии.

Этот список возник «благодаря» нескольким обзорным топикам в блоге «Космонавтика». Любовь Хабра к всему космическому привела к тому, что даже откровенно бредовый поток мыслей, написанный Шляхтичем многие приняли за чистую монету — и это далеко не единственный (хотя и наиболее вопиющий) пример того, о чём я пытаюсь сказать.

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

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

Для шифрования в SQLite были найдены следующие возможные решения:

• SEE — официальная реализация.
• wxSQLite — c++ wxWidgets обертка для шифрования SQLite.
• SQLCipher — использует в реализации openSSL.
• SQLiteCrypt — модифицированная реализация API.
• botansqlite3 — шифрующий кодек для SQLite3 использующий библиотеку botan.
• SQLiteCrypto — java API для Android, использует AES-256 и SHA-256.
• QtCipherSqlitePlugin — SQL плагин для Qt с поддержкой шифрования.

Из рассмотренных решений SEE, SQLiteCrypt and SQLiteCrypto требуют приобретения лицензии. SQLCipher доступен в версии Community Edition, но требует libcrypto.

Наиболее интересным решением из представленного списка, на мой взгляд, является QtCipherSqlitePlugin.
Плагин шифрует «на лету» и полностью интегрирован в API Qt.

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