Комментарии 36
Ещё одна причина для каждого перевода денег использовать новые адреса-получатели.
Да, трояны могут сразу пересылать закрытый ключ (и спалиться на первом же фаерволе),
Если пользователь проворонил такой троян, то вряд ли у него будет такой хитрый файрвол. Можно же пересылать информацию в DNS-запросах, к примеру.
НЛО прилетело и опубликовало эту надпись здесь
С одной стороны это на руку атакующему — можно не заморачиваться со случайными параметрами и тогда, как и у DJB параметр k будет всегда одинаковый для одного и того же сообщения.
С другой стороны пользователь может сам независимо от программы посчитать HMAC(key, hash) и убедиться, что там совсем не то.
НЛО прилетело и опубликовало эту надпись здесь
А по хорошему подпись одного и того же сообщения и должна быть всегда одинаковой, если ключ не менялся.

А как же такое понятие как семантическая стойкость и утечки информации об открытом тексте в детерминированных криптосистемах? Рандомизация это очень даже полезно, не стоит от нее добровольно отказываться, еще неизвестно выиграешь от этого или проиграешь.
НЛО прилетело и опубликовало эту надпись здесь
Я просто не согласен с тем, что подпись одного сообщения должна быть всегда одинакова. Это я не о какой то конкретной реализации говорю, а в целом. К примеру, если валидная подпись сообщения всегда одинакова, то это открывает широкие перспективы для всякого рода replay attack.
Я просто не согласен с тем, что подпись одного сообщения должна быть всегда одинакова.

… широкие перспективы для всякого рода replay attack.

Это разные вещи. Детерминированность — свойство алгоритма. Например, блочный шифр AES — это детерминированный алгоритм, и это хорошо, т.к. это псевдослучайная перестановка. От атаки на протоколы, которые используют детерминированный алгоритм, защищаются на уровне самого протокола: с помощью режимов шифрования, например. С помощью уникального номера для каждого сообщения, например. В общем, на алгоритм это не влияяет.

Подпись не обязана быть детерминированным алгоритмом, но в этом есть польза: проще делать безопасную реализацию (особенно на каких-нибудь чипах). Недерминированность самой подписи вообще не защищает от replay никак (ну кто мешает послать тот же блок данных еще раз?), поэтому лично я вот не вижу никакой пользы от рандома.
А знаете вы меня переубедили. Я почему то когда говорил о рандомизации держал в уме RSA. Но для ECDSA, вариант описанный Ivan_83 действительно лишен недостатков наивного RSA и при этом избавляет от проблем с PRNG.
Спасибо за ответы, Ivan_83 и grich
Оказывается, целая наука под названием клептография занимается передачей информации в так называемых «подсознательных» каналах. Таких, о которых никому не известно кроме отправителя и получателя. Вроде стеганографии, только внутри криптоалгоритмов.

а можно поподробнее — я не могу найти никаких упоминаний об этой науке
Спасибо, почитаю — я искал как cLyptography — вроде слова встречаются, но не то что надо, а на русском/укр. вообще ничего.
Такие атаки решают Дилемму заключённого.

При чем здесь это?

Есть такой пример в схемах с подсознательным каналом: заключенный Алиса пытается передать Бобу какую-то информацию, чтобы факт передачи не заметил охранник. Но при чем здесь теория игр?
Передавать в подсознательных каналах можно не только закрытый ключ, можно и сообщения
Я могу лишь спросить еще раз: «при чем здесь теория игр?»
Как методы клептографии могут заставить участников сотрудничать и придти к Парето-оптимуму?

Мне кажется, кроме слова «заключенный» тут ничего общего нет.
Об этом есть в книжке G. J. Simmons, The Prisoners' Problem and the Subliminal Channel, in: D. Chaum (Ed.), Proceedings of Crypto ’83, Plenum Press, 1984, ISBN 978-0-306-41637-8, но я её не смог найти
Если не смогли найти, то откуда знаете, что там написано?
Попробуйте вторую ссылку в гугле по запросу «The Prisoners' Problem and the Subliminal Channel». И найдите в тексте описание дилеммы заключенного из теории игр, на которую дали ссылку.

Не найдете, там его нет. Ставится другая проблема, тоже со словом «заключенный». Об этом я и говорю: это разные вещи в принципе.
Простите за глупый вопрос в столько серьезном топике. Я правильно понимаю, что для того, чтоб совершить какие-то вредоносные действия атакующий должен заставить жертву выполнить некий вредоносный код у себя на машине (затрояненный генератор ключевой пары, в данном конкретном случае должен быть затроянен биткойн-клиент). И только после этого злоумышленник сможет получить закрытый ключ жертвы?
Уже легче. А правильно ли я понимаю, что вся суть в том, что пока жертва не поймет сам факт выполнения ею этого вредоносного кода (что практически невозможно в случае отсутствия исходников ПО) факт утечки данных узнать никак не получится?
А в случае strong setup даже после понимания и полного «расковыривания» трояна узнать что именно за данные были переданы не получится.
Правильно. Можно будет по коду узнать что передавался именно закрытый ключ, например. Но что это за ключ — увы
Что-то ни как не могу понять, данный бакдор модифицирует клиента биткоин или просто ворует закрытые ключи от кошелька с целью из старых закрытых ключей, в определенных условиях (перевод с этих ключей), получить закрытые ключи от вновь сгенерированых после деинсталляции бакдора?
данный бекдор ничего не ворует, он модифицирует подписи так, что тот, кто об этом знает, может узнать закрытый ключ
А в каком конкретном месте происходит модификация? В системе или в клиенте биткоина?
Прочитал и не раз, однако хотелось бы пару строчек о том, как на практике это может быть реализовано и как от этого можно защититься. Какие конкретно действия троян незаметно произведет на удаленной машине с кошельком и как их можно обнаружить?

пока на затрояненных кошельках появятся серьезные суммы.

затрояненные кошельки, это как вообще?
как на практике это может быть реализовано

Там выше целая статья на тему как это может быть реализовано на практике. Даже код есть! Если вам оттуда ничего непонятно, то я ничем больше помочь не могу, это все таки хабр, а не школа
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Проблема в том, что навыками аудита исходного кода криптографических программ обладают единицы, а пользуются такими программами все. И это не считая закрытых программ. И встроить туда подобный бекдор — не проблема.
А в моем произношении из-за дефекта дикции «клептографию» от «криптографии» совсем почти не отличить :)
такой класс атак на криптоалгоритмы называется SETUP (Secretly Embedded Trapdoor with Embedded Protection)

… у меня получается SETEP…
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.