Менеджер доступа в смарт-контракте

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

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

Есть ли известный способ решить эту проблему?

Вы можете использовать асимметричное шифрование. Я не буду вдаваться в подробности, но вы можете попросить отправителя данных зашифровать их с помощью открытого ключа получателя и сохранить их либо в блокчейне, либо в IPFS, либо в чем-то еще, и в этом случае вы можете сохранить хэш данных. на цепочке для проверки. Открытый ключ не совпадает с адресом. Он должен быть либо предоставлен получателем, либо получен из подписи получателя. Есть способы сделать это. После того, как данные сохранены в IPFS, получатель может расшифровать данные, используя свой собственный закрытый ключ.
Дело в том, что я хочу иметь возможность динамически управлять разрешением на этот ключ, так как владелец может добавлять зрителей и удалять их на ходу.
Как бы вы поступили со зрителем, копирующим данные перед их удалением?
Все могут копировать данные, все могут делать скриншоты или что-то еще, здесь не в этом дело :)
В этом случае можно было просто не шифровать и публиковать данные с помощью открытого ключа удаленного вьювера после обновления.
Мое видение состоит в том, чтобы зашифровать данные с определенного ключа, а затем разрешить или запретить адресам получать ключ из блокчейна для расшифровки этих данных.

Ответы (1)

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

Менеджер доступа в смарт-контракте
СпросиСетьПолитика конфиденциальности1y, 0v