4. Иван, вы проявляете удивительное незнание базовых принципов криптографии. Повторение нонсов — это ужаснейшая проблема, которая делает автоматически любую шифросхему потенциально небезопасной. Почему? Да потому что это дает одинаковый ключевой поток k и k'. Тогда если k == k', то (P ^ k) ^ (P' ^ k') дает на выходе P ^ P', что явно отличимо от random output. Это даже *без* знания P и P' позволяет статистически выделить закономерности в таком шифротексте. Более того, в случае счетчика повторение нонса однажды значит повторение его и впоследствие, что позволит однозначно выделить закономерности и расшифровать содержимое. Повторение нонсов безопасно только в случае, если вы и так передаете /dev/random через зашифрованный канал. Что, очевидно, крайне редко применимый кейс. Зная открытый текст, конечно, все еще проще, но это знание необязательно в огромном количестве реальных случаев.
Ну как, ваяешь ты, такой, статический сайтик на bootstrap + jekyll, все получается красиво, в едином стиле. Хочешь сгенерить документацию, и тут бах — привет из 90-х: html от doxygen. Конечно, те, кто познал дао css + html, допускаю, смогут из этого сделать что-то вменяемое (хотя в gnome, например, забили на это и тоже написали свой велосипед gtk-doc, который, к слову, выглядит заметно приятнее); но для обычного человека этот ужас никак уже не привести в единый вид с общим сайтом. Кроме того, документацию в markdown можно прямо с разметкой читать через github (https://github.com/vstakhov/libucl/blob/master/doc/lua_api.md).
Doxygen — это ужасная система. Генерить сырой html при существующих стандартах веба для документации — это преступление. Не использовать синтаксические парсеры, вроде clang-ast, для контроля соответствия описания и реальных функций — это преступление. В общем-то, я бы рекоммендовал закопать пациента, но, увы, какой-то нормальной замены ему нет. Сам же колхозил нечто подобное с выводом в markdown без всяких мерзких html: github.com/vstakhov/doxydown Но по функционалу, конечно, до doxygen ему далеко. С другой стороны, для моих задач его хватает (например, так: rspamd.com/doc/lua/config.html).
Пользуясь случаем, хочу обратить внимание, что мой проект — rspamd в этом году приняли. Так что если вдруг кто-то заинтересуется какими-то из идей, то можно пообщаться.
В TLS сервер подписывает random cookie, чтобы обеспечить replay protection для сессии. А рост сложность подписи растет квадратично. Для сравнения, в ECC сложность подписи (применяя правильные алгоритмы умножения точек, типа лестницы Монтгомери или Карацубы на некоторых платформах и кривых) растет практически линейно. Вот результаты nistp256 (аналог RSA 3072):
256 bit ecdh (nistp256): 5391.8 op/s
256 bit ecdsa(nistp256): 9483.1 signs/s
Предлагаемый новый стандарт 128 бит кривых (что предполагает 256 бит ключа в ECC) — curve25519 — работает еще быстрее, давая где-то 20к ecdh в секунду на той же машине.
Алгоритм Диффи-Хельмана, конечно, не имеет ничего общего с тем, что вы пытаетесь описать (а пытаетесь вы описать forward secrecy, видимо). Свойство forward secrecy можно обеспечить и с RSA, но генерация эфемерного rsa ключа — это, конечно, очень затратная операция по сравнению с генерацией DH группы.
Насчет GCM vs CBC-SHA1 хочу отметить следующее: если во второй схеме заменить SHA1 на тот же SHA256/512, то схема аутентификации становится вполне себе адекватной. А вот реализовать в софте GMAC, который был бы еще constant time, — ужасно трудная задача (без шуток). Все реализации AES-GCM, как правило, используют PCLMULQDQ (intel core +) для умножения в поле Галуа, что требует минимум SSE2 инструкций. Поэтому для embedded или минималистичных реализаций TLS я бы советовал как раз cbc-sha2, а не GCM.
А озвучьте, пожалуйста, чем примитивы, описанные вами, более безопасны, чем примитивы, описанные автором этой статьи, в условиях отстуствия авторизации сервера. Пока что, с моей точки зрения, подобное заявление выглядит в стиле «я знаю каратэ, кунфу и еще много других страшных слов».
В 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 параллелизуется только дешифрация блоков.
Статья написана исключительно для студентов гуманитарных специальностей. То есть, там, где интеллект действительно вторичен, — тогда скилл подвешенности языка и начинает играть ведущую роль. В технических специальностях неприменим ни один совет, кроме, пожалуй, связей. Да и то, способ их получения не имеет ничего общего с описанным в статье.
Есть еще классический алгоритм rolling хеша. Хотя меня всегда больше волновала задача, как обеспечить быстрый лукап по нечетким хешам, потому как считать расстояние Хемминга крайне затратно. Вариант с сортировкой был бы неплох, но там есть свои проблемы, особенно когда база хешей быстро меняется.
Насчет sqlite3 мне нравится их требование. Потому что оно позволяет иметь весь код под одной лицензией (например, той же MIT), не парясь по поводу отдельных кусков. Кто писал когда-либо debian/copyright наверняка может понять, почему. Меня самого просили разрешить заимствование кода под CC0 (правда, в коммерческий проект).
Думаю, есть некая корреляция с количеством фолловеров и языках, на которых написаны ваши проекты. Очевидно, что хаскель имеет значительно более высокий порог вхождения, нежели python/js/php, и количество контрибьюторов в проектах на хаскеле тоже обычно меньше. В моих проектах на C, например, очень мало контрибьюторов (и с большинством из них я знаком через irc), хотя звездочек у некоторых из них немало.
Я использую этот логгер в одном своем проекте. Не нравится ровно две вещи: во-первых, нельзя без смены макросов логировать в syslog/stderr (типа, выбора бэкэнда логирования), во-вторых, при парсинге argc/argv он не выкидывает свои опции из списка аргументов, поэтому следующий за ним getopt не очень удобно применять (например, указывая на неправильный формат аргументов). Впрочем, первое ограничение является самым неудобным, а кроме того, достаточно сложным в фиксе.
Как мне кажется, aes — это один из самых неудобных алгоритмов для реализации в микроконтроллере, как с точки зрения скорости, так и с точки зрения сложности реализации. Ваша статья прекрасно это демонстрирует. Если взять, например, chacha20, то вы получите как простоту реализации, так и большую скорость операций (более того, chacha20 — это PRP, которая работает симметрично в обе стороны, и обеспечивает она не 128 bit security, а 256). А для еще большего прироста скорости, можно снизить число раундов до 12, что также приемлимо.
В FreeBSD в этом году есть такой GSoC проект — machine readable output для всех утилит в базе. Человек, работающий над ним, пока смотрит в сторону yajl, который умеет выводить json потоково, но я, наверное, добавлю подобное в своем libucl, и мы будем использовать для этой задачи именно libucl (а, следовательно, поддержку всех форматов, что понимает ucl).
Потому что в случае Британии это лимит на посылки внутри UK или ЕС. За смартфон из Китая ценой в $200 пришлось отдать порядка 20 фунтов пошлины (VAT + фиксированная сумма). Другое дело, что оплатить эту пошлину элементарно.
У меня были такие же мысли после окончания универа, и даже была рекоммендация от дипломного совета на поступление и был руководитель, готовый со мной заниматься. Но заботами о семье, о собственном жилье и, в конечном итоге, о деньгах оказались заполнены несколько последующих лет. А сейчас я решил поступить более радикально и пошел в аспирантуру университета Кембриджа. Возможно, вам тоже стоит присмотреться к этому варианту — аспирантуре зарубежом. В конце-концов, вернуться и преподавать вам никто не мешает, а уровень зарплат в России уже вплотную приближается к зарплатам в Европе (в IT сфере, конечно). Чего сказать про аспирантуру в России, я не могу. Хотя серьезные исследования в сфере computer science ведутся и у нас, но попасть туда крайне сложно.
В TLS сервер подписывает random cookie, чтобы обеспечить replay protection для сессии. А рост сложность подписи растет квадратично. Для сравнения, в ECC сложность подписи (применяя правильные алгоритмы умножения точек, типа лестницы Монтгомери или Карацубы на некоторых платформах и кривых) растет практически линейно. Вот результаты nistp256 (аналог RSA 3072):
Предлагаемый новый стандарт 128 бит кривых (что предполагает 256 бит ключа в ECC) — curve25519 — работает еще быстрее, давая где-то 20к ecdh в секунду на той же машине.
Насчет GCM vs CBC-SHA1 хочу отметить следующее: если во второй схеме заменить SHA1 на тот же SHA256/512, то схема аутентификации становится вполне себе адекватной. А вот реализовать в софте GMAC, который был бы еще constant time, — ужасно трудная задача (без шуток). Все реализации AES-GCM, как правило, используют PCLMULQDQ (intel core +) для умножения в поле Галуа, что требует минимум SSE2 инструкций. Поэтому для embedded или минималистичных реализаций TLS я бы советовал как раз cbc-sha2, а не GCM.
Насчет параллелизации, я не знаю, что вы пытались сказать словом «формально», но как раз параллелизация шифрации блоков данных — это как раз очень важное свойство CTR режима, а не конкретных PRF, используемых в этом режиме. В CBC параллелизуется только дешифрация блоков.