Хранение и передача зашифрованных данных другому владельцу

Я довольно долго думал об этой ситуации, и мне интересно, есть ли способ решить эту проблему в общедоступной цепочке блоков Ethereum.

Пользователь A хранит некоторые данные в блокчейне, каким-то образом зашифрованные. (например, с закрытым ключом A). Таким образом, эти данные доступны для чтения только A. Теперь A хочет «передать» право собственности на эти данные B, опять же в зашифрованном виде, при этом гарантируя, что данные не будут подделаны во время процесса. Это означает, что шифрование не может происходить вне цепочки: во-первых, B не может отправить свой закрытый ключ A по понятным причинам, но более того, если A повторно зашифрует данные с помощью ключа B вне цепочки, не было бы никакого способа проверить, остались ли данные прежними.

Я знаю, что нет простого способа реализовать эту логику с помощью смарт-контракта. Очевидная проблема здесь заключается в том, что смарт-контракты «не могут» шифровать, потому что для этого вам нужно предоставить им ключ, что делает шифрование бесполезным с самого начала.

При этом есть ли способ добиться точного результата с помощью других инструментов, сохраняя при этом максимальную безопасность?

Когда вы говорите «передача», вы имеете в виду процесс, к которому A больше не имеет доступа после передачи B? Если да, то это невозможно (хотя потенциально вы можете создать что-то, через что A не получит будущие версии данных). Если вы имеете в виду, что B также имеет доступ, A может зашифровать данные, используя открытые ключи B с системой открытых ключей. Теперь его можно опубликовать публично (в том числе в блокчейне, но это кажется излишним для больших данных).
@lungj да, я имею в виду, что у A больше нет доступа к будущим версиям данных - они все еще могут получить доступ к более старым версиям. Какой тогда был бы обходной путь? Огромное спасибо!
Наименее сложный способ, вероятно, состоит в том, чтобы иметь ключ дешифрования, который A отправляет B, зашифрованный с использованием открытого ключа B, так что только B может прочитать сообщение. Зашифрованные данные могут быть переданы B по каналу, доверенному или иному. B повторно вводит данные. Без изменения данных А знает, что это за данные (поскольку у А есть ключ дешифрования для версии, которой поделился с Б). Но если данные изменены, A не может определить их содержимое (при условии, что выбрана соответствующая схема шифрования).
У меня был такой же вопрос: ethereum.stackexchange.com/questions/48540/… лучшего ответа не нашел

Ответы (3)

Во-первых, информация шифруется с помощью открытого ключа и расшифровывается с помощью закрытого ключа, а не наоборот (т . е. подписывается и проверяется ).

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

После этого Aсначала зашифрует данные, используя вновь сгенерированный открытый ключ, а затем зашифрует вновь сгенерированный закрытый ключ, используя свой собственный открытый ключ. При передаче Aбудет расшифрован вновь сгенерированный закрытый ключ и зашифровано его использование Bоткрытого ключа.

Затем он Bможет расшифровать этот закрытый ключ, используя свой собственный закрытый ключ, а затем расшифровать данные, используя этот закрытый ключ, и подтвердить, что это действительно те же данные (поскольку он может их расшифровать , и если Aпоместить неверные данные в блокчейн, она не сможет их расшифровать . ).

Теперь вы можете решить, будете ли вы генерировать пару ключей каждый раз, когда данные изменяются, или вы собираетесь использовать пару ключей из первой записи данных в блокчейне. И если вы Bхотите ограничить доступ, Aкогда в Bследующий раз изменятся данные, Bпросто нужно сгенерировать новую пару ключей из измененных данных.

Контракту потребуется одно событие со строкой, зашифрованнойPrivateKey и строкой, зашифрованнойДанные.

При передаче вы просто поместите Bадрес пользователя вместе с закрытым ключом B, зашифрованным с помощью открытого ключа в другом событии.

В dapp вы заметите B, находится ли его адрес в событии передачи, и попытаетесь расшифровать данные, и если это работает, передача является законной.

вы можете зашифровать с помощью общедоступного или частного и расшифровать с помощью другого в зависимости от необходимости. (Нам приходилось делать это в школе 25 лет назад)
Есть исследовательский документ под названием SmartDHX, который реализует это, как вы описали.

Смарт-контракты не должны шифровать важные данные с помощью закрытых ключей по двум причинам:

1.- Чтобы зашифровать любые данные, им необходимо знать данные, а это означает, что они общедоступны в поле данных транзакции блокчейна.

2.- Смарт-контракт, использующий чей-то закрытый ключ, означает, что закрытый ключ передается в качестве аргумента заданной функции контракта, и он также будет записан в реестре как поле данных транзакции. Никогда не раскрывайте закрытые ключи.

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

Чтобы передать актив, шифрование также должно выполняться вне сети, когда DApp/кошелек отправляет новые зашифрованные данные в контракт.

Спасибо за Ваш ответ. Я определенно понимаю эти 2 пункта, поскольку я надеялся прояснить их в своем посте, и я уже исключил прямой подход, заключающийся в том, что смарт-контракт выполняет шифрование. Как я могу гарантировать, что расшифровываемые данные и новые зашифрованные данные, хранящиеся вне сети, являются одними и теми же данными? И как один пользователь выполняет расшифровку и шифрование с помощью закрытого ключа другого пользователя?
Офчейн DApp или кошелек, который выполняет шифрование, должен знать данные, первый открытый ключ и второй открытый ключ. Таким образом, он может выполнять шифрование для двух разных пользователей одних и тех же данных и проверять, соответствует ли первый результат предыдущей версии.
Означает ли это, что если кошелек/dApp, используемый для шифрования вне сети, будет заброшен разработчиками, например, не будет поддерживать будущий хардфорк, то «dApp» перестанет работать? Таким образом, это не настоящий dApp?

У меня был аналогичный вариант использования ( как хранить личные данные в эфириуме ). Лучшее, что я нашел, это следующее:

в то время как A является владельцем данных, он хранит эти данные в блокчейне, используя свой открытый ключ. Таким образом, А — единственный, кто может его расшифровать.

Когда A передает право собственности B, он считывает данные и декодирует их вне цепочки, затем перекодирует их с использованием открытого ключа B, а затем сохраняет их в цепочке.....

Если вы действительно хотите доказать, что это сделал А, вы можете легко сделать это с помощью смарт-контракта, например, убедившись, что именно А сохранил данные Б.

Например, если права собственности хранятся в смарт-контракте, только текущий владелец может изменять права собственности (или связанные данные), поэтому только А может изменять данные и назначать их Б.

Хранение и передача зашифрованных данных другому владельцу
СпросиСетьПолитика конфиденциальности1y, 0v