Чересчур уверенные в себе разработчики, пишущие собственный криптографический код, были проклятием отрасли информационной безопасности ещё до того, как она вообще стала отдельной отраслью.
Само по себе это необязательно плохо, несмотря на то, что одна из аксиом информационной безопасности запрещает делать именно это. Написание криптографического кода (но не его развёртывание или публикация!) — важный первый шаг в обучении алгоритмам.
Я заметил такую тенденцию (как в примере с Session): разработчики некорректно утверждают, что не реализуют собственную криптографию, ведь они используют низкоуровневую криптографическую библиотеку.
Эта ошибка свойственна не только сомнительным приложениям, форкающим мессенджеры со сквозным шифрованием, чтобы вырезать прямую секретность (forward secrecy).
Криптография уровня «стартап»
Насладитесь репринтом How we share secrets at a fully-remote startup за январь 2025 года поста за 2024 год о том же криптографическом коде, который изначально пал жертвой Padding Oracle Attack Блейхенбахера 1998 года (наверно, это самая старая ошибка при реальном применении криптографии и одна из причин, по которой профессиональные криптографы советую перестать использовать RSA).
Уточню, что прошу насладиться статьёй не для того, чтобы раскритиковать её автора.
Он далеко не первый, кто реализует собственную криптографию. И даже не первый, кто делает это на этой неделе.
Зато он любезно разобрал свой код и рассказал о том, что же они написали; я думаю, это проливает свет на то, как люди рассуждают о криптографическом коде.
Пост начинается с повторения правила, которое мы постоянно слышим от специалистов по безопасности:
Не реализуйте собственную систему безопасности
Как и во многих сложных областях человеческого знания, чем больше вы знаете в безопасности/криптографии, тем глубже осознаёте, сколь многого не знаете.
И это действительно хороший совет!
Но если пролистать пост чуть дальше, то вы увидите и следующее:
Реализовали ли мы собственную систему безопасности?
Едва ли. В нашем решении используется криптографический код из надёжных источников: Node.js, его криптомодуля и библиотеки OpenSSL, на которой он основан. Это уважаемые, качественно поддерживаемые и популярные опенсорсные инструменты, за которыми внимательно наблюдают исследователи безопасности.
Хм, это утверждение чем-то нам знакомо, не так ли?
Да, автор понимает, что «реализовывать собственную криптографию» нежелательно, но он каким-то образом убедил себя, что не сделал именно этого.
Конкретно этим-то данный пост и интересен для меня.
Описываемый в нём код выглядит именно так, как должен выглядеть код из поста с подобным когнитивным диссонансом:
- Сначала он пытается напрямую зашифровать ключи при помощи RSA.
- Если ему это не удаётся, то он откатывается к шифрованию случайного симметричного ключа при помощи RSA, а затем использует этот ключ для шифрования сообщения… неаутентифицированным AES-CBC.
О, и я ведь ещё не сказал о том, что другие люди пытались отговорить автора от развёртывания собственной реализации ещё в первый раз (то есть полгода назад).
Дополнение к моему посту: автор изменил свой код, теперь RSA используется только для обёртывания ключа, а AES-CBC заменён на AES-GCM.
Это существенное улучшение по сравнению с тем, что они делали раньше. В данном конкретном примере мы дождались хэппи-энда.
Бесчисленное количество нерассказанных историй
Да, мы можем раскритиковать код и пост, но, по крайней мере, разработчики здесь честны и прозрачны.
А знаете, сколько людей совершают похожие ошибки проектирования и выпускают их в продакшен каждую неделю без малейшего контроля со стороны сообщества безопасников?
В этой части поста я бы мог рассказать десяток историй, дополняющих пост CEO стартапа.
К сожалению, все мои лучшие работы выполнялись под NDA. То есть я при всём желании не мог бы привести подробности. Разговоры, которые я вёл в течение долгих лет, могли бы вызвать мурашки у большинства неофитов в сфере информационной безопасности. К счастью, мы с коллегами успешно убеждали разработчиков, что ситуацию нужно менять.
Вот некоторые из ярких примеров:
- Я видел, как люди использовали
md5($password)в качестве функции генерации ключей для libsodium. - Я видел, как люди шифровали поля базы данных, а потом сохраняли ключ дешифровки прямо рядом с зашифрованным текстом. Затем они совершали гениальный ход: писали логику дешифровки на SQL, чтобы можно было выполнять запросы к базе данных по зашифрованным полям.
- Как минимум один раз при анализе проекта со сквозным шифрованием, в котором криптография была реализована на JavaScript и должна была выполняться в веб-браузере, я задавал вопрос: «Откуда вы знаете, какому публичному ключу можно доверять?». Мне ответили что-то вроде: «О, мы просто храним их в MySQL и получаем их с сервера».
Очевидно, что эти ошибки серьёзнее, чем в рассмотренном выше посте. Каждый раз, когда вы видите чужие ошибки в прикладной криптографии, напоминайте себе, что, вероятно, существует ещё десяток, который вы ещё не видели. Но, скорее всего, вы никогда о них не услышите, потому что эти ошибки совершают в проприетарных системах без какого-либо контроля или прозрачности. То же самое можно сказать о вышеупомянутом коде и посте.
Перед кустарной криптографией могут не устоять даже крупные технологические компании.
Гордыня побеждает
Разработчики продолжают реализовывать собственную криптографию. При этом они часто считают, что их действия нельзя расценивать, как реализацию собственной криптографии (как мы видим из примера выше).
Я считаю, что это явление продолжает существовать по следующей простой причине:
У большинства людей нет фундаментального понимания того, что же такое реализация собственной криптографии.
Их несогласие с этим состоит из нескольких слоёв.
▍ Ошибочно понятые границы
Самое важное значение реализации собственной криптографии заключается в трате любого количества «очков инноваций» на любом уровне абстракций без адекватного обеспечения корректности и/или контроля со стороны специалистов по криптографии (предпочтительно тех, у кого есть хотя бы какой-то опыт во взломе чужих реализаций).
И это касается не только людей наподобие разработчика Crystalline!
То, что вы отдаёте реализации блочного шифрования на аутсорс модулю
crypto своего языка программирования, не означает, что вы не реализуете собственное крипто.Криптография существует не только на примитивном слое. Любые протоколы, использующие криптографию — это тоже крипто! Это радиоактивный и биологически опасный материал.
▍ Что вообще такое «собственная криптография»?
В этой часто повторяемой фразе теряется понятие того, что же такое на самом деле ваша собственная криптография.
Размазывает ли работа в команде ответственность за её наличие?
Только ли в новизне проблема? Разумеется, нет. Если бы всё было так просто, то достаточно было бы придерживаться готовых стандартов.
Так почему же столь многие реализации JSON Web Token совершают ужасные ошибки?
▍ Будут слёзы
По моему скромному мнению, эта луковица состоит из множества слоёв: чем глубже вы режете, тем больше придётся плакать.
- Написание кода UI, обёртывающего libsignal для реализации E2EE — это не что-то новое, но перед развёртыванием вам всё равно стоит отдать этот код на проверку людям с опытом в атаках на криптографию.
- Написание собственной реализации стандартных криптографических протоколов? Вот в этом уже есть определённая новизна. Двигайтесь осмотрительно.
- Проектирование собственного криптографического протокола поверх стандартных криптографических библиотек? Это намного более ново, чем вы себе представляете.
- Разработка собственной криптографической библиотеки из стандартных конструкций криптографических алгоритмов? Если вы не являетесь опытным специалистом, то это опасная территория.
- Новые конструкции криптографических алгоритмов (например, похожие на те, которые я неформально реализовал в своём посте)? Вы забрались уже слишком глубоко.
- Альтернативы криптографическим алгоритмам? Здесь торопиться не стоит.
- Идеи, представляющие конкуренцию фундаментальной математике, используемое в современной криптографии? Если вы ещё не пробили успешно все предыдущие слои и не продемонстрировали атаки на стандарты, существующие в соответствующих слоях, то вы, вероятно, не совсем здоровы.
Когда человек из сферы информационной безопасности говорит «не реализуйте собственное крипто», то не совсем понятно, где нужно остановиться.
Я думаю, считается, что недопустимы «новые конструкции», и если вы всего лишь «проектируете собственный криптографический протокол», то можно легко прийти к выводу, что вы не реализуете собственную криптографию, хотя на самом деле так и есть!
Никаких инструментов, одна некомпетентность
Я считаю, что в фундаментальном смысле базовая проблема заключается в отсутствии доступных и надёжных криптографических инструментов для разработчиков.
Что бы вы ни думали об OpenSSL, вы должны признать, что это далеко не «полнофункциональная» низкоуровневая криптографическая библиотека.
Если вы пользуетесь OpenSSL, например, для того, чтобы реализовать Messaging Layer Security (RFC 9420), то не можете заявлять, что не реализуете собственное крипто.
Tink и libsodium ближе к идеалу, но их нельзя считать полными готовыми реализациями высокоуровневых протоколов, которые разработчики могут просто вставить в свои приложения.
Даже когда за дело берутся криптографические умники, они часто делают упор на простые задачи (обёртывание стандартных AEAD асимметричной криптографией), а не на решение более сложных задач.
А именно на управление ключами.
И поэтому я в первую очередь делаю упор на управление ключами в своём проекте Fediverse E2EE. Я даже не задумываюсь о самой логике сквозного шифрования, пока не разберусь с управлением ключами.
Если изучить доступные разработчикам инструменты, предлагаемые языками программирования и экосистемами менеджеров управления пакетами опенсорсного ПО, то сложится ощущение, что все пытаются отдать пас кому-то ещё, надеясь, что проблему решат другие.
▍ Добро пожаловать в мой ад
Пока я работаю над реализацией надёжного решения задачи управления ключами для моего собственного проекта сквозного шифрования, слишком уверенные в себе разработчики по всему миру продолжают реализовывать собственное шифрование. И часто при этом утверждают, что не делают этого.
Человеку свойственно ошибаться, но люди постоянно совершают ошибки, которых можно было избежать. Это происходит потому, что специалисты пока не реализовали простой в использовании инструментарий для языков программирования.
Это крайне меня расстраивает.
Я не хочу сказать, что в чём-то уникален. Это совершенно точно не так. Но есть множество людей, способных на всё то же, что и я (а некоторые и даже больше), однако эта проблема сохраняется, как будто назло мне.
Поэтому я чувствую ответственность каждый раз, когда кто-то совершает ошибки, хоть и люди получше меня тоже не преуспели в их устранении. Разумеется, я не собираюсь сдаваться, но это всё равно очень печалит.
Изучающие историю вынуждены беспомощно наблюдать, как окружающие повторяют её. Наблюдение же за тем, как разработчики изобретают заново одни и те же уязвимости — моё проклятие как специалиста в криптографии.
Дополнение к статье
В комментариях начали задавать вопросы «Какими инструментами следует пользоваться?» и «Как всё это изучать?»
К счастью, я уже написал об этом пару постов.
- What To Use Instead of PGP — подробное описание криптографического ПО для применения в конкретных сценариях использования.
- How to Learn Cryptography As A Programmer — знакомство со множеством ресурсов, необходимых для совершенствования знаний в криптографии, если у вас уже есть опыт в разработке ПО.
Telegram-канал со скидками, розыгрышами призов и новостями IT ?
Комментарии (93)
jahr2
10.02.2025 14:02Нет вреднее предрассудка, чем "Не пишите собственной криптографии". Как будто при работе с файловой системой или сетевой библиотекой, например, не допускают ошибок, которые могут привести к взлому системы. Никто же не пытается говорить "Никогда сами не работайте с файлами или сетью!".
Если бы все сами работали с криптографией, то все имели бы представление о том, как верифицировать собственный протокол или какие типичные ошибки существуют. А сейчас все это воспринимается как какая-то магия, разбираться с которой бесполезно, а можно только обратиться к магу-криптографу.
PatientZero
10.02.2025 14:02Так в статье и говорится, что практиковаться и изучать криптографию можно и нужно, не стоит только свои изобретения пускать в продакшен
jahr2
10.02.2025 14:02Сравните с "Изучать работу с сетью можно и нужно, не стоит только свои изобретения пускать в продакшен".
unreal_undead2
10.02.2025 14:02Скажем так - писать свои ФС и сетевые протоколы тоже надо, в том числе и для production, но в большинстве случаев лучше (дешевле, безопаснее и т.д.) использовать то что есть. С криптографией примерно так же.
Abstraction
10.02.2025 14:02Если бы все сами работали с криптографией, то все имели бы представление о том, как верифицировать собственный протокол или какие типичные ошибки существуют.
К сожалению нет. Есть фундаментальное различие между ошибками функциональности и ошибками безопасности: первые могут быть обнаружены при обычном использовании, и обычно достаточно легко предъявить тест который демонстрирует проблему вне разумных сомнений. Вторые никак не сказываются на нормальной работе ПО (за совсем клиническими исключениями), и даже демонстрирующий уязвимость proof-of-concept вполне можно не понять или убедить себя что проблема несущественна.
Более педантичное правило звучало бы так: реализуйте безопасность всерьёз и с серьёзными затратами или не реализуйте её вовсе, потому что полумеры практически дают результат хуже чем если бы не реализовывали ничего - оно так же небезопасно, но теперь у вас есть ложные иллюзии.
jahr2
10.02.2025 14:02Ошибки безопасности возможны не только при работе с криптографией, об этом я и говорю (всем известнгый пример - обработка пользовательского ввода в веб-формах). Почему при этом с придыханием говорят именно о работе с криптографией - непонятно.
rsashka
10.02.2025 14:02Потому, что тебе не известны все требования к безопасности по криптографии (т.к. это сведения ограниченного доступа), и чтобы ты не написал, это с большой долей вероятности будет недостаточно (в силу неизвестности требований).
johnfound
10.02.2025 14:02Бред – если что-то фигурирует в библиотеке, тем более с открытым кодом, то оно секретным не может являться по определению. А на нет и суда нет – вы секретные криптографии использовать не сможете как бы вам и не хотелось.
jahr2
10.02.2025 14:02"Требования к безопасности по криптографии" как раз и не известны массам, потому что всем вдалбливают в голову про "не пишите своей криптографии" первым делом при попытке с этой криптографией познакомиться (я надеюсь Вы не имели в виду мистические сверхсекретные знания "требований к безопасности" всяких фсбшников, простым смертным недоступные? "Ограниченный дрступ" меня смутил)
Abstraction
10.02.2025 14:02Это как раз спорное ограничение. Оно иногда играет на руку (как когда АНБ порекомендовало определённые матрицы
AESDES, а несколько лет спустя выяснилось что они устойчивы к новому методу атаки), но может играть и против (как неслучайность матриц "Стрибога" наводит людей на подозрения что они выбраны такими не из-за устойчивости, а, напротив, из-за внедрённого бэкдора).Фундаментально, криптография - это наука об управлении доверием. Одно дело использовать библиотеку, в отношении которой вы доверяете что авторы приложили больше усилий чем можете приложить вы, и заметно другое - полагаться на таинственные рецепты, корректность которых вы в принципе не можете проверить.
Abstraction
10.02.2025 14:02Потому что обрабатывать пользовательский ввод приходится самим, коль скоро нужна уникальная логика. Да, здесь тоже есть место для проблем, и применяется то же правило: либо вы делаете всерьёз, либо полагаетесь на принцип Неуловимого Джо (возможно плюс минимальная защита от script kiddies, хотя с пришествием языковых моделей этот "минимум" тоже может оказаться чертовски высоко).
А необходимости писать свой безопасный протокол почти никогда нет, то есть узкий совет звучит как "не делайте этой ошибки на совсем уж ровном месте".
kenomimi
10.02.2025 14:02Почему при этом с придыханием говорят именно о работе с криптографией - непонятно.
Там в корне лежит математика, которая простым смертным недоступна ввиду своей дикой сложности. Потому свое свежеизобретенное криптографическое решение никак невозможно протестировать на стойкость... Примерно тоже самое, что придумывать лекарства без специального медицинского образования - кастомное зелье может и сработает против болезни, но потом у больного рога с копытами отрастут.
А еще товарищ майор не хочет разбираться с вашими кастомными шифрованиями, он и стандартные-то с трудом осиливает /s
johnfound
10.02.2025 14:02Там в корне лежит математика, которая простым смертным недоступна ввиду своей дикой сложности.
Вы за всех не говорите. За себя говорите.
IUIUIUIUIUIUIUI
10.02.2025 14:02Я отдалённо знаком с алгеброй (ну, той, которая Chapter 0 у Паоло Алюффи — собсна, проботал значимую часть упражнений в этой книге и понимаю
такие шутки целиком
без открытия справочников) и некоторыми другими ветвями математики, используемыми в криптографии, вроде эллиптической всякой ерунды или решёток. Кроме того, я, хотелось бы думать, неплохо знаком с кое-какими ещё более абстрактными и глубокими ветвями математики (теоркат всякий, типы там, логика). При этом я полностью согласен с предыдущим оратором, и сам бы тоже не полез бы в написание своей крипты без существенной и многомесячной подготовки.
Теперь расскажите, пожалуйста, за себя, и что вас заставляет думать, что проблемы в криптографии нет.
M_AJ
10.02.2025 14:02Потому свое свежеизобретенное криптографическое решение никак невозможно протестировать на стойкость
Если мне не изменяет склероз, доказанной стойкостью обладает только шифр Вернама, а стойкость остальных алгоритмов -- предположительна.
Abstraction
10.02.2025 14:02В асимметричной криптографии чуть лучше. К примеру, можно показать что если у нас есть оракул, ломающий Диффи-Хеллмана, то его можно использовать для разложения на множители произвольного числа. (Т.е., конечно, у нас нет хорошего нижнего предела для задачи факторизации, но такая гарантия всё-таки не совсем ничего.)
Uporoty
10.02.2025 14:02Ошибки безопасности возможны не только при работе с криптографией, об этом я и говорю (всем известнгый пример - обработка пользовательского ввода в веб-формах). Почему при этом с придыханием говорят именно о работе с криптографией - непонятно.
Потому что при обработке данных с веб-форм для того, чтобы вас с треском не поимели, достаточно соблюдать ряд вполне простых правил, смысл который поймет любой разработчик от миддла и выше (не рассматриваем случаи, когда бэкенд написан на Си или плюсах и эксплоит использует уязвимости в результате UB и перезаписи памяти, такого в наши дни все меньше и меньше, а в популярных на бэкенде языках ногу отстрелить гораздо сложнее, и от многих гадостей защищает рантайм). Это не значит, что ошибок там точно не будет, но самые популярные и простые для использования вы точно закроете.
А в случае с криптографией нюансов на порядки больше, и разобраться в них сможет даже далеко не каждый инженер с математическим образованием. И ошибки там могут быть такие, что сократят требуемое время взлома с сотен лет и до нескольких минут, и вы об этом даже не узнаете.
lea
10.02.2025 14:02а можно только обратиться к магу-криптографу.
Настораживает то, сколько софта завязано на алгоритмы Daniel J. Bernstein...
Newbilius
10.02.2025 14:02Да ладно? Нет вреднее предрассудка? А скажем "при любой простуде обязательно принимайте антибиотики" не страшнее будет?)
ToSHiC
10.02.2025 14:02Криптография в среднем на порядок сложнее, чем работа с файловой системой или сетевой библиотекой. Ради интереса, попробуйте указать, не подглядывая в интернете решение, в чём заключается уязвимость в этой программе:
from Crypto.Cipher import AES from Crypto.Util.Padding import pad,unpad import os def encrypt(key, plaintext): cipher = AES.new(key, AES.MODE_CTR, nonce=IV) return cipher.encrypt(pad(plaintext, 16)) def decrypt(key, ciphertext): cipher = AES.new(key, AES.MODE_CTR, nonce=IV) return unpad(cipher.decrypt(ciphertext), 16) def menu(): print("1. Encrypt Message") print("2. Get Flag") print("3. Exit") choice = int(input(">> ")) return choice key = os.urandom(16) IV = os.urandom(8) while True: choice = menu() if choice == 1: plaintext = input("Message: ") print("Encrypted Message (hex):", encrypt(key, plaintext.encode()).hex()) elif choice == 2: print("Encrypted Message (hex):", encrypt(key, b"COMPFEST16{RETACDED}").hex()) elif choice == 3: breakСкрытый текст
Если всё же хочется подсмотреть - https://medium.com/@raihansltn/reduce-reuse-recycle-cryptography-ctf-hacker-class-compfest16-d9ca4824c558
mayorovp
10.02.2025 14:02Не, ну это слишком просто, такое школьники ломают в восьмом классе...
Я же прав, что
Я же прав, что тут за такими сложными словами как AES.MODE_CTR скрыто банальное шифрование через XOR с длинным случайным, но неизменным ключом?
vesper-bot
10.02.2025 14:02Вообще нет, шифрование даже 16 байт через AES-CTR со сброшенной длиной не эквивалентно XOR'у. Однако переиспользование IV+key в этом коде есть, и именно на эту уязвимость алгоритма (а не кода) де-факто идет атака в этой задаче. Но надо ещё почитать, как именно запилить эту атаку.
mayorovp
10.02.2025 14:02Но ведь AES-CTR - это поточный режим, а поточный шифр - это всегда XOR текста с гаммой?
ToSHiC
10.02.2025 14:02AES-CBC тоже поточный шифр, и это тоже XOR текста с гаммой. Если поменять в задаче выше AES-CTR на AES-CBC, что-то поменяется?
StJimmy
10.02.2025 14:02Неправда, CBC - не поточный режим. Там не простой XOR с гаммой а именно chaining, т.е. следующие блоки будут зависеть от предыдущих.
ToSHiC
10.02.2025 14:02Да, я тут плохо написал. Смысл - станет ли в питон скрипте хорошо, если заменить AES-CTR на AES-CBC, и почему именно. Но вы, судя по замечанию, эту причину понимаете :)
event1
10.02.2025 14:02Если бы все сами работали с криптографией, то все имели бы представление о том, как верифицировать собственный протокол или какие типичные ошибки существуют.
Ага. А если бы все сами работали с выделением/освобождением памяти , то все имели бы представление, о том, как верифицировать свой код и избегать NPE, Use-after-Free и тому подобных проблем
Wesha
10.02.2025 14:02Вот прямо так и хочется у автора поинтересоватсья — что условному агентству из трёх букв, первая Ф, проще взломать: нечто, зашифрованное широко известной библиотекой, которая у всех одинаковая, или какой-то самописной реализацией, которых вокруг 100500? Нет, понятно, что самописку взломать можно не за 10^100 лет, а на много порядков быстрее — но если всё равно получается число Дохуа — то так ли уж это принципиально?
arokettu
10.02.2025 14:02Самописную реализацию хакнуть проще: если это опенсорс, если это легко дизассемблировать (скорее да чем нет), если автор этого доступен для терморектального криптоанализа. Лушче всё же взять широко известную библиотеку
buratino
10.02.2025 14:02даже если опенсорс и лежит на гитхабе - это ж надо поднять попу и попытаться понять чужой код, для чего нужно как-то простимулировать читальщика и понимальщика чужого кода
xenon
10.02.2025 14:02Зависит от сложности (качества) самодельного решения. Самодельный S-box с уникальными случайными перестановками (A->B, B->G, C->Z, ...) может казаться разработчику охренеть каким простым, эффективным и надежным. Но его взлом - уровень лабораторной работы.
Другие, более сложные методы - тоже имеют причины (методы атаки), по которым от них отказались.
Беда самописной криптографии не в уполовиненном Дохуа, а в том, что разработчик сам не компетентен и не может квалифицированно оценить его "криптостойкость". Ему-то кажется что Дохуа или даже тройной Дохуа (но как пессимист и скептик, он допускает, что всего лишь 1% от Дохуа). А по факту это - 20 минут на взлом.Или (но тут я повторю мысль из статьи) - алгоритм не так уж и плох, но разраб ошибся в какой-то неожиданной мелочи (например, инициализировал свой PRNG из time() как в школе учили). И вот пароль юзера Wesha из 27 символов в котором есть цифры-буквы-эмодзи-иероглифы и даже соло на саксофоне - он имеет не хреналлион комбинаций и даже не пол хреналлиона, а всего лишь 86400, потому что все знают, что он с нами с 18 сентября 2015.
Wesha
10.02.2025 14:02А по факту это - 20 минут на взлом
Но речь-то как раз о том, что этот факт надо для начала узнать — а это денег (в смысле времени = зарплаты высококвалифицированных специалистов) стОит.
vvzvlad
10.02.2025 14:02Поэтому лучше считать, что если вы не взяли стандартную реализацию типа https, что ваша реализация это 20 минут на взлом.
Wesha
10.02.2025 14:02Лучше вообще считать, что Злобная Гебня Знает Всё, но на практике оно так очень-очень не всегда.
AuroraBorealis
10.02.2025 14:02<...> на практике она (гебня) очень-очень не всегда это знание показывает
fixed for the great justice
S1re10k_4f99
10.02.2025 14:02Если не сложно, можете объяснить каким образом получается именно 86400 комбинации? Меня не учили инициализировать PRNG из даты, никогда так не делал, поэтому не знаю в чём прикол.
Wesha
10.02.2025 14:02Дяденька просто взял первое вспомнившееся число. Любой
более-менее приличныйне-AIшный программист в курсе, что это число секунд в сутках.S1re10k_4f99
10.02.2025 14:02Вот именно, а дат в системе в разы больше же.
mk2
10.02.2025 14:02> (например, инициализировал свой PRNG из time() как в школе учили)
Но дату-то мы знаем, то самое 18 сентября. А раз мы знаем дату, когда был вызван time() - у нас остаётся всего 86400 вариантов, в какую именно секунду его вызвали.S1re10k_4f99
10.02.2025 14:02Спасибо, наконец то догнал откуда ноги растут.
А вот зачем использовать такие плохие генераторы, так и не догнал. Выглядит как какая-то дичь. Что тогда туда передавать то, захардкоженое число огромного размера что-ли? Или числа одного генератора пускать в другой, что тоже выглядит странно.
А у криптостойких генераторов тоже такой прикол с инициализацией?
JerleShannara
10.02.2025 14:02Инициализировать ПГСЧ от настоящего ГСЧ, предварительно проверив распределение выдваемых им значений. А вот какой диапазон у этого должен быть и какой должен быть объём входных данных - этому и учат магов-криптографов. Аппаратных генераторов случайных чисел сейчас полно, даже в микроконтроллерах оные присутствуют.
Felixx
10.02.2025 14:02Псевдослучайные генераторы для некоторых задач, не криптографических, вполне применимы, тот же рандом в играх с виду подходящая задача. Криптостойкие же используют "честную" случайность - случайный ввод (то самое "подергайте мышкой пока мы генерируем ваш ключ шифрования"), сетевую активность, а так же существуют аппартные, на основе шума радио-эфира, ядерного распада и т.п.
S1re10k_4f99
10.02.2025 14:02Ну да, так и было, использовали генераторы просто для генерации чисел для массивов и строк, чтобы ручками не заполнять и не хардкодить, когда нужно много чисел. Ну и чтобы было видно, что программа работает как нужно с любыми данными.
AntonLarinLive
10.02.2025 14:02Аппаратные ГСЧ уже давно встраивают прямо в процессор.
johnfound
10.02.2025 14:02Только их не хотят использовать, потому что небезопасные.
AntonLarinLive
10.02.2025 14:02Ничего нового: баг нашли, баг пофиксили, едем дальше. Не отказались же от OpenSSL после heartbleed.
mayorovp
10.02.2025 14:02Меня не учили инициализировать PRNG из даты
Вероятно, потому что вы пишете на языке, где такая инициализация идёт просто по умолчанию (хотя обычно используется немного другой таймер). Прикол в том, что генераторы псевдослучайных числе обычно детерминированы, и при их использовании не может получиться больше различных последовательностей чем было подано на вход. И если на входе было 86 400 возможных значений системного времени - то и возможных случайных паролей можно сгенерировать лишь 86 400.
Чтобы этого избежать, нужно использовать либо недетерминированные генераторы псевдослучайных чисел, где в состояние генератора регулярно подмешивается энтропия; либо просто глобальный общесистемный генератор, который был инициализирован хрен знает когда и генерировал числа хрен знает сколько раз. А, ну ещё безопасный генератор должен быть криптостойким для защиты от некоторых других атак.
S1re10k_4f99
10.02.2025 14:02такая инициализация идёт просто по умолчанию
Возможно так и есть, в учебном заведении использовал pascal, basic, C#. А сейчас работаю на 1С. Вообще не помню, чтобы в генератор нужно было что-то передавать, кроме параметров для определения множества чисел, которые он будет рандомить.
где в состояние генератора регулярно подмешивается энтропия
А вот это видел и не раз, всякие там покрути мышкой или понажимай кнопки, при создании контейнера для ЭЦП.
mayorovp
10.02.2025 14:02На Паскале и Бейсике генератор псевдослучайных чисел в инициализации нуждается, должны были научить его инициализировать (если вообще про него хоть что-то рассказывали). На C# так вообще можно любое число генераторов создать (и самая популярная ошибка новичка - создавать новый генератор каждый раз когда понадобится случайное число).
Насколько старый Бейсик вы учили? Не помните случайно конструкцию "RANDOMIZE TIMER"?
S1re10k_4f99
10.02.2025 14:02На паскале инициализировал его, но не помню, чтобы туда что-то передавалось при этом, вроде метод без параметров.
На бейсике вообще не помню чтобы пользовались рандомайзером, может быть его там и не было, потому-что это был Visual Basic в Excel 2007 - 2013.
На C# создавал 1 раз, а потом получал числа. Вроде бы про это сразу препод сказал.
Но это всё было 7-10 лет назад, так что достоверность воспоминаний такая себе, может быть я больше сейчас придумал. Ну в любом случае по несколько раз не инициализировал его.
Uporoty
10.02.2025 14:02На паскале инициализировал его, но не помню, чтобы туда что-то передавалось при этом, вроде метод без параметров.
Потому что, как сказали выше, по умолчанию он берет текущее время в качестве параметра.
А вот в C, например, srand() явно принимает на вход параметр типа unsigned int, который используется для инициализации генератора.
S1re10k_4f99
10.02.2025 14:02В С не использовали рандомайзер. Ну и мы его использовали только для генерации чисел для массивов и строк. Ну и чтобы было видно, что программа работает как нужно с любыми данными. Так что по сути нам бы подошёл любой.
Felixx
10.02.2025 14:02Если в вашем гипотетическом случае предполагается, что неизвестностью самописной реализации улучшается ее защищенность, то это нарушает принцип Керкгоффса.
johnfound
10.02.2025 14:02Так то оно так, но вот прямо сейчас в этом обсуждении есть много людей, которые почему-то считают, что «Security through obscurity» это хорошая практика, которая увеличивает безопасность.
kipar
10.02.2025 14:02Не факт что ломать будет агентство из трех букв. Хакер-самоучка наоборот не осилит сломать общеизвестную библиотеку, а вот самописный код - заинтересуется и расколет.
rendov
10.02.2025 14:02А если сделать двойное шифрование, (сначала самописным кодом, а поверх уже общеизвестной библиотекой), то хакер -самоучка отсеется, а агенство получит лишнюю головную боль. Это же самый очевидный вариант, win-win.
JerleShannara
10.02.2025 14:02Агенство посмотрит, как вы обращаетесь с открытым текстом и ключами шифрования до и после передачи в магическую идеальную криптолибу и сделает выводы. Кроме того такой двойной велосипед может и снизить криптостойкость.
Alexander_Tamirov
10.02.2025 14:02Ну да, Закон Шнайера имеет место быть ))
Wesha
10.02.2025 14:02«От меня не требуется создавать принципиально невзламываемую систему. Мне достаточно создать систему, которую не сможет взломать тот, кого назначат расследовать моё дело.»
(Джим Санборн смотрит на этих ваших профессионалов, ехидно посмеиваясь.)
Alexander_Tamirov
10.02.2025 14:02'..По причине того что Санборн не имел достаточных знаний о криптографии, он обратился за помощью к Эду Шейдту, который незадолго до этого закончил свою деятельность как глава криптографического центра ЦРУ..'
dersoverflow
10.02.2025 14:02отличная Тема! и мои пять копеек :)
если автор доступен для терморектального криптоанализа
вот! это ГЛАВНОЕ.
и не важно на все остальное, если можно давить гражданина.реализуйте безопасность всерьёз и с серьёзными затратами или не реализуйте её вовсе, потому что полумеры практически дают результат хуже чем если бы не реализовывали ничего
смиялсо.
а вот вам цитата Серьезного Безопасника из 90х годов: ЛЮБОЕ минимальное шифрование ВСЕГДА лучше ограничения прав доступа! ваш текст не должен СРАЗУ читаться. точка.
но сначала поговорим про ГОСТы ;)
ГОСТ — это аббревиатура от словосочетания «государственный стандарт». он есть в любом государстве. и в любом государстве вас ЗАСТАВЯТ его использовать!почему?
ну, прежде всего нужно четко себе представлять, что весь Мир сейчас жестоко разделен на дружественные и вражественные юрисдикции:
вражеские государства вас заставят использовать ГОСТ, потому что всегда смогут вскрыть все шифровки. они это используют для продвижения терроризма, наркомании и детской порнографии!
дружеские государства вас заставят использовать ГОСТ, потому что всегда смогут вскрыть все шифровки. они это используют для защиты от терроризма, наркомании и детской порнографии!
не перепутайте!
и что же крестьянину делать?
2. обязательно использовать ГОСТ страны пребывания. это Закон!1. но перед этим шифровать свои данные любым доступным способом.
да, есть подвох.
сразу после вашего наивного шифрования (но перед ГОСТом) его нужно чуточку исказить:переставить немножко байтики
что-то заксорить во имя тёщи
в общем, любое дилетантское искажение, делающее невозможным АВТОМАТИЧЕСКОЕ декодирование "всем известного" наивного шифрования...
вы тем самым поможете Злым человекам стать немножко Добрее.
alexsavochkin
10.02.2025 14:02Справедливости ради, необходимость и обязательность использования государственных стандартов регулиируется законодательством о стандартизации. В России, например, за некоторыми исключениями использовать ГОСТы не обязательно. Например, ядерный реактор надо обязательно строить по профильным ГОСТам, а вот писать пояснительную записку к вузовской выпускной квалификационной работе, в принципе, по ГОСТу не обязательно, и вузу никто не запретит утвердить какие-то другие требования к её оформлению.
randomsimplenumber
10.02.2025 14:02а вот писать пояснительную записку к вузовской выпускной квалификационной работе, в принципе, по ГОСТу не обязательно,
Ну, может где-то не слишком строго соблюдают.. Но обязательно. Вам ведь диплом выдадут стандартный, и квалификационная работа тоже должна быть выполнена с выполнением стандартов.
masuk0
10.02.2025 14:02Применение гостов дело добровольное. Ну вот если у вас есть госзаказчик который требует делать по ГОСТу, то делайте. Обязательными для всех являются технические регламенты, их дума принимает, это законы. Регламента на шифрование нет.
Хотя погодите, регламенты кажется распространяются только на продукцию обращаюся на территории ЕАЭС. Для себя или забесплатно можно что угодно.
vvsstriker
10.02.2025 14:02Когда-нибудь те, кто пишут статьи про крипту, перестанут путать дешуфровку и расшифровку. А что такое ключ дешифровки?
supercat1337
10.02.2025 14:02Мне понравился вопрос "Откуда вы знаете какому публичному ключу можно доверять". Спец по кустарной криптографии будет держать этот ключик, доступный по урлу, может еще в блокчейн записать и т.п. Но это все небезопасно. А якобы кошерный способ - это пользоваться услугами сторонней организации - УЦ, которой безусловно необходимо доверять.
event1
10.02.2025 14:02Проблема не в том, что разработчик не знает какому ключу можно доверять, а какому нет. Проблема в том, что разработчик не задумался над вопросом: "Откуда я знаю, что ключу можно доверять?" И не записал ответ в документацию. Потому что 100%-ой гарантии не бывает, а ограничения системы должны быть задокументированы
AndreyAf
10.02.2025 14:02У большинства людей нет фундаментального понимания того, что же такое реализация собственной криптографии.
Это потому что начиная с главных - техдир больше астроном чем итишник, и команду себе подбирает соответствующую.
У меня был случай мне присылали json с логином зашифрованным паролем (симметричный алг) и рядом еще ключ расшифровки, типа никто не догадается.
Одним словом астрономы.
Vasya1209
10.02.2025 14:02обычно, никто нахрен не полезет ломать вашу криптосистему, ибо видно что там заморочено, и мало ли как оно там...время ток терять.....надеяться что идиоты зашифровали все для вида - можно , но только если очень надо, времени разбираться много, и если что ну не срослось, ладно )) проще мож договориться и купить пароль чей-то
randomsimplenumber
10.02.2025 14:02обычно, никто нахрен не полезет ломать вашу криптосистему
если она никому не нужна
В далёких 2000-х кейгены были к каждой более-менее полезной программе. (по факту, это реверс -инжиниринг самодельных криптосистем)
johnfound
А криптографические библиотеки пишет Бог и коммитит в гитхаб по воскресеньям.
mynameco
Мне кажется имеется ввиду следующее. был прикол, когда разработчик на плюсах, для управления памятью, заюзал стандартный умный указатель, но так как он каждое копирование, лочит себя и работает с счетчиками, разработчик, чтобы ускорить работу с умным указателям, передавал указатель везед по ссылке! и у него периодически умирал указатель. Так и тут. есть библиотека хорошая, написаная умными людьми с тестами, и разработчик ее заюзал, но пароль положил рядом, или приватный ключ оставил в коде.
nochkin
Конечно, код пишут люди. Но это специальные люди, у которых есть справка от врача.
johnfound
Вот, а в статье об этом ни слова. :)
nochkin
Врачи не разрешили об этом писать. Санитары строго следят за выполнением.
sdramare
Интересно, какая была справка у чела, который встроил эксплойд в ΧΖ
xenon
Любая мысль сведенная к короткому заголовку, лозунгу или правилу - искажается.
Я как раз хотел возразить - "пишите свою криптографию! пишите свою аутентификацию!" - потому что именно это - единственный способ набить все шишки и научиться. Но надо понимать, что шишки - будут.
Безопасность и особенно криптография - особые области. Во всех остальных, если ты плохо сделал - ты это видишь сам, или быстро найдется пользователь, у которого не работает. Студент просто не сделает сложную задачу в сложной области - все это увидят. А в безопасности - все всегда работает. (Чем больше механизмов безопасности ты отключишь или не включишь - тем даже лучше будет работать!). Давно известные правила из жизни теряют смысл, как только доходит до безопасности, вплоть до того что PRNG инициализировать из таймера нельзя. То, чему мы научились в 14 лет и всю жизнь делали, оказывается, нельзя делать!
Keeper11
Потому что суббота -- это шаббат.
SADKO
Ой-вэй во имя Тора, песня-то не о библиотеках которые используют пациенты.
Автор всего-лишь о том, что криптография не сводится к вычислительным методам предоставляемыми библиотеками. Она ещё про сценарии, использования оных! Вырванные из контекста методы теряют всякий смысл, чему приводятся примеры. Как замок на калитке она вроде-бы и висит, но не факт что что-либо запирает ;-)
Всё это можно было-бы изложить коротко и понятно, не создавая иллюзии посягательства на священное право людей всяко по вертеть данными перед шифрованием, тут вестимо, на богов надейся, а сам не лошай.
kipar
есть интересное чтиво от одного из авторов своей криптобиблиотеки https://loup-vaillant.fr/articles/rolling-your-own-crypto https://loup-vaillant.fr/articles/implemented-my-own-crypto
спойлер - хотя он разбирается в математике и был уверен что багов нет т.к. реализация занимает меньше тысячи строк, вдумчивые исследователи несколько уязвимостей таки отыскали. Зато теперь она выглядит уж точно понадежнее OpenSSL.