В этой ситуации отправитель должен по умолчанию должен уже раскрыть (в сети) их открытого ключа, так что я мог зашифровать данные (вероятно хэш) Я хочу, чтобы вернуться к ним, и хранить его в ТХ (где-то), который возвращаются в передающем адрес (я знаю, я знаю, плохую Bitcoin практику и LukeJR, вероятно, будет полевой день с моей терминологией, если он видит это), но, надеюсь, вы можете понять некоторый свет на то, что я имею в виду здесь делает, и пусть меня знаю, если это может быть возможно?
Ну, нет "отправка адрес" в протоколе Bitcoin, поэтому эти данные должны быть переданы вне группы. Это не "проблема терминологии" и не является мнением Люк-младший. Это факт о Bitcoin.
Тогда существует общая проблема с использованием тех же ключей для подписи и шифрования. Насколько мне известно, нет никакого нападения на основе ключа использования одновременно в ECDSA и ECIES, но я также не знаю о каких-либо доказательствах безопасности, что это безопасная комбинация. Это обычно верно, что алгебраическая структура двух неродственных криптосистем могут быть объединены, чтобы произвести атаку. Так, например, в
CryptoNote Whitepaper схема кольцевой подписи предлагается, которая имеет два хэш-функции. Оказывается, вы можете удалить одну из этих хэш-функций и заменить тождественной функции, и до сих пор доказать безопасность кольцевых подписей --- и на самом деле я сделал это, думая, что это хэш-функция была только там по историческим причинам (в
схема кольцевой подписи, что схема CryptoNote основана на, эта хэш-функция обеспечивает сжатие, которая не нужна больше в CryptoNote). Но на самом деле, я был неправ, чтобы удалить этот хэш, потому что, как они наблюдают в нижней части страницы 17, без хэш-функции их схема кольца подписи взаимодействующий очень плохо с их скрытности схемы адреса. Я рад, что они упоминали об этом, потому что я, конечно, не поймал бы это. (Вы можете возразить, что в этом случае я просто не очень умный, но представьте себе, что стелс адреса и подписи кольца были предложены отдельными сторонами, и были объединены не-криптограф, который лечил их, как черные ящики. Вы можете увидеть что "не смешивать криптосистемы!" был бы очень продуктивным совет.)
Еще одно общее беспокойство у меня есть о проводках в этой теме, являются комментариями по линиям "wellll, я думаю, что я могу сделать это безопасно, до тех пор, пока пользователь не делает X или Y или Z", Проблема с этой линией мышления, что приводит к очень привередливы и нестандартным свойствам безопасности, а это значит, что кто-то с помощью криптосистемы нужно будет очень тщательно думать о том, как именно используются схема. В профессиональной криптографии, есть множество "Стандартные свойства безопасности" которые носят весьма общий характер и что криптосистемы обязаны придерживаться. Например, схема подписи должна быть безопасным EUF-CMA "экзистенциально неподдельны при выбранной атаке сообщения"Это означает, что даже злоумышленник, который может запросить подписи на произвольных сообщений не может подделать один. Обратите внимание, что нет никакой зависимости от того, что здесь сообщения могут быть подписаны, что злоумышленник имеет право делать и т.д.
Есть несколько свойств безопасности, схемы шифрования с открытым ключом должны удовлетворять, которые так же вообще. Эти свойства известны криптографам и (относительно) легко для них рассуждать о. (Обратите внимание, что они делают
не охватывают атаки бокового канала, и доказать безопасность только тогда, когда их предположения удовлетворены --- например, что все генераторы случайных чисел производят значения, которые действительно неотличимы от равномерно случайных.) Имея математическое доказательство того, что криптосистема удовлетворяет одному из этих свойств являются необходимым условием для системы даже не стоит анализировать. Тогда мы можем рассмотреть контекст, который будет использоваться в, является ли это свойство безопасности применяется, защита от боковых каналов, как получить необходимую хаотичность, кто имеет доступ к тому, что секретным данным, как секретные данные хранятся или передано, и т.д. ., и т.д.
Существует много к этому, и если вы не можете получить основную доказуемую безопасность примитивов вниз вашей системы безнадежно. И это просто невозможно сделать это с помощью аргументов узкоспециализированных или отводок нестандартных предположений о том, как будет использоваться криптосистема.
У меня нет времени, чтобы проверять код (по крайней мере, не достаточно хорошо, чтобы публично дать свое благословение), но стоит учесть, что
Javascript криптография практически невозможно сделать безопасно.