Задать вопрос
z3apa3a

Владимир Дубровин

Ответы пользователя по тегу Криптография

  • Какова вероятность взлома AES-128-ECB, если часть информации доступна?

    z3apa3a
    @z3apa3a
    Основной недостаток ECB заключается в том, что одинаковые данные будут шифроваться в одинаковые блоки шифротекста, поэтому зная шифрованный текст для одного открытого текста (например для одного JSON) можно понять что другой файл это тоже JSON в определенной структуре. Если какие-то блоки из 16 октетов у файлов совпадают, то и в шифротексте будут совпадающие блоки. Если у атакующего есть возможность получать шифротекст по открытому тексту (например инциировать запрос клиента и получать результаты шифрования, аналогично BEAST) то можно попытаться подобрать недостающие неизвестные данные в блоке, причем в отличие от BEAST просто прямым перебором.

    Имеет ли это значение зависит от того, как именно вы собираетесь использовать криптографию. Есть замечательное правило: "do not roll your own crypto". Если можно обойтись без криптографии - лучше обойтись без криптографии. Если вам надо шифровать данные - используйте готовые проверенные библиотеки и форматы криптоконтейнеров. Если вам надо шифровать потоки данных - используйте TLS с рекомендуемыми настройками.
    Ответ написан
    Комментировать
    Комментировать

  • Где хранить iv, если я могу запомнить только пароль?

    z3apa3a
    @z3apa3a
    IV не секретен и обычно хранится вместе с зашифрованными данными. Если IV не передается / не хранится отдельно, то, как правило, он находится в начале блоба с зашифрованными данными.
    Ответ написан
    9 комментариев
    9 комментариев

  • Как будет взломан алгоритм с генерацией бесконечного ключа шифрования?

    z3apa3a
    @z3apa3a
    Такой подход нарушает принцип Кергофса. Взломать ваш алгоритм можно двумя способами:
    1. Подобрав алгоритм генерации, это можно сделать, например, перебирая функционалы составляющие функцию вашего алгоритма.
    2. В вашем варианте алгоритм к тому же не устойчив к known plaintext атакам. Предположим Алиса передает Бобу сообщение которое известно атакующему - тогда зная это сообщение и проксорив его с "шифрованым" текстом можно получить сгенерированную последовательность и в дальнйшем дешифровать любое сообщение, поэтому в современные алгоритмы обязательно вносится обратная связь и/или какой-нибудь nonce.

    P.S. предположу, что вы пытаетесь переизобрести потоковый шифр
    Ответ написан
    Комментировать
    Комментировать

  • Сколькибитный пароль считается достаточно сложным, чтобы его не сломало брутфорсом ЦРУ/ФСБ?

    z3apa3a
    @z3apa3a
    Сформулируйте от какой атаки вы защищаетесь этим паролем. Если от подбора пароля по сети, то в предположении что сервис может обработать миллион запросов на авторизациюв секунду и не имеет никакой защиты от брутфорса (что странно для сервиса обрабатывающего много авторизаций), потребуется 10^14 секунд для полного перебора или что-то порядка миллиарда лет, но скорей всего если к сервису полетит миллион запросов на авторизацию в секунду - он ляжет. Если от подбора пароля в офлайне по слитой с этого сервиса базы хешей - то видимо вам будет все равно, раз сервис уже поломали и хеши слили, при условии что этот пароль вы больше нигде не используете, т.к. если взлом обнаружен, порядочный сервис форсирует смену паролей пользователями, если не обнаружен или сервис непорядочный - то в общем-то без разницы, какой у вас там пароль. Поэтому для пароля важна не столько длина, сколько уникальность и неугадываемость (энтропийность).

    Основная проблема паролей не в длине, а в том что пользователи пароли генерируют не случайно (т.к. не умеют использовать парольные менеджеры), переиспользуют, плохо хранят и ведутся на фишинг. При таких проблемах их длина практического значения не имеет, и по факту практически никогда не встречается брутов на которткие пароли, встречаются бруты на словарные, пароли с пользовательскими данными и стаффинг паролей с других сервисов, просто среди коротких гораздо больше словарных, пароль длиной 7 символов и меньше с высокой вероятностью будет словарным, даже если он случайно сгенерирован, случайный уникальный пароль 10+ символов практически никогда не будет взломан по сети, даже если в нем только маленькие буквы, т.е. в нем менее 50 бит энтропии.

    Если вы хотите защищаться от офлайнового брута (например речь идет про сид коршелька) - то вот тут уже надо учитывать и вычислительные мощности тех, кто может ваш кошелек атаковать и запас на будущее и потенциально квантовую криптографию. Допустимая битность в таком случае будет зависеть от используемых алгоритмов, мощностей атакующего и допустимого уровня риска (например вы можете взять достимый уровень как вероятность взломать за год на вычислителе с 1 Петафлопсом 0.001% и исходя из алгоритма посчитать необходимое количество бит энтропии)
    Ответ написан
    1 комментарий
    1 комментарий

  • Как сделать шифрованный канал между 2 приложениями?

    z3apa3a
    @z3apa3a
    Да, это, разумеется, возможно.
    Сертификат сервера будет проверять ваше клиентское приложение. При этом вы можете задать свою функцию для проверки сертифката через options.checkServerIdentity()
    https://nodejs.org/api/tls.html#tls_tls_checkserve...

    Обычно в таких случаях проверяется не имя и не цепочка доверия, а просто хэш сертификата сервера (fingerprint или fingerprint256 ) и годится совершенно любой самоподписанный сертификат, причем это гораздо безопасней и надежней чем доверие к корневым CA. Такой прием в приложениях обычно называют Certificate pinning.
    Ответ написан
    5 комментариев
    5 комментариев

  • Сколько будет стоить уязвимость?

    z3apa3a
    @z3apa3a
    Heartbleed это потенциально более серьезная уязвимость, чем просто получение секретного ключа, т.к. позволяет угонять любые данные из памяти сервера.
    Доступ к секретному ключу позволяет только проводить атаки MitM и обходить certificate pinning, но при наличии Forward Secrecy - только активные в реальном времени с подменой сертификата, т.е. декодировать данные при пассивной прослушке или восстановить ранее переданные и перехваченные данные нельзя, даже имея доступ к ключу.

    Суммы выплат за подобные уязвимости определяются реальным импактом уязвимости (при каких настройках она реально работает и какие сервисы затрагивает), текущим спросом на этот импакт, и умением торговаться, и тем, на каком рынке они продаются - белом, сером или черном, и могут быть очень индивидуальны, от десятков тысяч до миллионов долларов. За Heartbleed было выплачено $15000 в качестве поощрения https://hackerone.com/reports/6626 - но у репортера не было цели заработать, и даже эти деньги ушли в благотворительный фонд.
    Ответ написан
    Комментировать
    Комментировать

  • Можно ли создать нейросеть, которая предсказывает числа из псевдослучайной последовательности?

    z3apa3a
    @z3apa3a
    Для хорошего ГПСЧ нет, т.к. в хорошем ГПСЧ нет какой-либо видимой закономерности у выходных данных, если там что-то можно найти нейросетью, то он плохой по определению. Но если у вас ГПСЧ выдает повторяющуюся последовательность из 10 элементов - то да.
    Для плохого ГПСЧ можно использовать нейросеть для выявления странных аттракторов , например. Пример использования странных аттракторов для анализа ГПСЧ есть вот в этой статье:
    lcamtuf.coredump.cx/oldtcp/tcpseq.html

    P.S. и не надо путать генераторы случайных и псевдослучайных чисел. Генераторы случайных чисел обычно используют какие-либо физические принципы, например генераторы на шумных диодах. ГПСЧ обычно алгоритмические + может использоваться сбор энтропии.
    Ответ написан
    1 комментарий
    1 комментарий

  • Как расчитать контрольную сумму?

    z3apa3a
    @z3apa3a
    Оптимальным скорей всего будет Рида-Соломона, т.к. для Хэмминга достаточно 6 бит.
    Ответ написан
    3 комментария
    3 комментария

  • На сколько эллиптическая криптография защищена от квантовых компьютеров?

    z3apa3a
    @z3apa3a
    Эллиптическая криптография при используемых в настоящее время параметрах значительно менее устойчива к квантовым алгоритмам чем RSA. RSA кстати считается достаточно устойчивым, для взлома 2048-бит RSA требуется 4096 кубит.
    Ответ написан
    Комментировать
    Комментировать

  • [RSA] почему схема с шифрованием данных напрямую не является "практически надёжной"?

    z3apa3a
    @z3apa3a
    Проиллюстрировать можно примерно так: представьте что у вас есть огромный файл из нулей, в котором имеется очень малое (в процентном соотношении) количество единиц. Напрямую зашифровав блоки RSA вы легко увидите блоки состоящие только из нулей, и блоки содержащие единицы. А если распределение единиц не равномерно и известно, то накопив некоторую статистику вы сможете различать в какой позиции блока находится единица и сможете полностью декодировать текст.
    Поэтому для шифрования большого объема данных обычно используются потоковые шифры (или блочные в специальном режиме, защищающими от подобных атак - гаммированние с обратной связью) с уникальной гаммой (ключом). А с помощью RSA шифруются только либо одноразовые уникальные случайные либо не секретные данные.
    Ответ написан
    7 комментариев
    7 комментариев

  • Есть ли смысл хешировать уже захешированные пароли?

    z3apa3a
    @z3apa3a
    Да, есть смысл для bcrypt как минимум. Задача bcrypt в том, чтобы замедлить процесс брутфорса и сделать его ресурсоемким и сложно реализуемым на специализированном оборудовании / GPU / ботнетах и т.п. (см. например openwall.info/wiki/john/GPU/bcrypt). Это сильно замедляет возможности подбора даже относительно слабых паролей.
    Есть еще более интересные алгоритмы, например Argon2 и yescrypt.

    Вводить разные хэши для разных пользователей не стоит, решение с "перехэшированием" старых хэшей вполне безопасно.
    Ответ написан
    14 комментариев
    14 комментариев

  • Что означает аутентификация и авторизация с ЭП на стороне клиента?

    z3apa3a
    @z3apa3a
    Совершенно не обязательно использовать сторонние плагины, можно использовать аутентификацию посредством клиентского сертификата https://.
    Ответ написан
    2 комментария
    2 комментария

  • Какие плюсы и минусы конструктивного доказательства P=NP (с алгоритмом)?

    z3apa3a
    @z3apa3a
    В предположении, что доказательство будет алгоритмическим, и его можно будет использовать на практике, это сделает более эффективным решение всего класса NP-полных задач, их сложность станет не экспоненциальной, а полиномиальной.
    Список задач есть здесь:
    https://en.wikipedia.org/wiki/List_of_NP-complete_...

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

  • Сначала шифровать или сжать?

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

  • Шифрование. Надеяться ли на то, что алгоритм никому не известен?

    z3apa3a
    @z3apa3a
    Защищенность информации должна основываться только на знании ключа и не зависеть от того, известен алгоритм или нет (Принцип Керкгоффса, XIX век).
    Ответ написан
    Комментировать
    Комментировать

  • Trunderbird: Использование одного и того же сертификата для шифрования и подписи?

    z3apa3a
    @z3apa3a
    Вы даете сертификат с открытым ключем и письма для Вас смогут им шифровать.
    Ответ написан
    1 комментарий
    1 комментарий