Тут в другой моей теме затронули другую интересную
Здравствуйте, velkin, Вы писали:
"Например, некто создаёт "полный ресурс" и хранит в нём данные. С этого ресурса можно скачать данные и ключи для расшифровки. Если сторонний пользователь скачал данные, а условно главный "полный ресурс" недоступен, то другие пользователи качают недостающие части с ретрансляторов, то есть тех пользователей, которые разрешили скачивание. Но сами пользователи не смогут подменить содержимое "полного ресурса" без ключей для шифровки."
я там вижу проблемы скорее политическое, чем технические
1. Хостя где-то БД, вы по умолчанию доверяете, что хостер не будет раскрывать базу целиком, а только то что выдает ваш бэкэнд
и соотв можно держать некоторые данные недоступными всем желающим
если же вы ее децентрализуете, то вам придется открывать всё
2. Частично это можно решить криптографией, но например если у вас авторизация производится по цифровой подписи, то утеря онного означает полную окончательную потерю доступа к аккаунту
пипл будет недоволен
А юзание централизованного авторизатора херит всю идею децентрализации
3. Личные данные типа переписки тоже придется шифровать с такими же проблемами как выше. Но возможно это можно разрулить если будет использоваться щифрование, при котором расшифровать может не только юзер, но и админ. Психологически это приемлемо потому что щас никто не знает в каком виде хранится его переписка и никто не парится по этому поводу особо.
3. Вы раскрываете не тока бд, а и всю логику бэкэнда, сам целиком он как показывает практика никому не интересен в плане украсть, но какие-то алгоритмы могут оказаться ценным ноу-хау.
4. Сложность и размер бэкэнда может быть такой, что на рядовом мобильнике его не запустишь, если мы конечно хотим универсальное решение, а не только для криптозадротов
Поэтому я пока не вижу как сделать чистый р2р бэкэнд
Зато можно сделать по другому — открытый облачный протокол
Это когда вам предоставляется не облако с одним владельцем, а облачные провайдеры выступают как пиры небольшой р2р сети, а может и не такой большой. Пиром может быть как датацентр так и 1 сервер, просто датацентр потянет 10 тыщ клиентов, а домашний сервер только 10.
И вы можете хоститься на любом не предопределенном подмножестве в зависимости от
качества, потребности в масштабировании, политических ограничений и т.д. причем добавление/удаление и провайдера не требует участия человека, оптала может работать в крипте, а приложение само анализировать насколько его устраивает тот или иной провайдер
(я кста для своего проекта между делом написал простейший движок распределенной (как блокчейн) но реляционной БД с мерами обеспечения криптогарфической целостности, заточенной на свободную р2р репликацию налету, но у меня там нет задачи чтото скрывать, задача была сделать "блокчейн без блокчейна". Причем нашлось простое и элегантное решение как их клонировать и синхронизировать налету не используя историю транзакций, даже если она такая огромная что это может занять дни или недели.
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Barbar1an, Вы писали:
B>"Например, некто создаёт "полный ресурс" и хранит в нём данные. С этого ресурса можно скачать данные и ключи для расшифровки. Если сторонний пользователь скачал данные, а условно главный "полный ресурс" недоступен, то другие пользователи качают недостающие части с ретрансляторов, то есть тех пользователей, которые разрешили скачивание. Но сами пользователи не смогут подменить содержимое "полного ресурса" без ключей для шифровки."
B>(я кста для своего проекта между делом написал простейший движок распределенной (как блокчейн) но реляционной БД с мерами обеспечения криптогарфической целостности, заточенной на свободную р2р репликацию налету, но у меня там нет задачи чтото скрывать, задача была сделать "блокчейн без блокчейна". Причем нашлось простое и элегантное решение как их клонировать и синхронизировать налету не используя историю транзакций, даже если она такая огромная что это может занять дни или недели.
Про БД и криптографическую целостность нечто похожее на днях в HackerNews в новостях было.
tldr: SendSecurely is a secure platform to send sensitive documents and files to others. All files are encrypted locally before uploading to SendSecurely. The decryption keys are also encrypted and managed by a new audited database system. Anytime anyone accesses the decrypted keys, an audit log is created letting you keep track of everyone you have shared the file with and when they have accessed it. We would love for you to try this new system and share feedback!
long (and technical) story: My partner and I have been working for the past 2 years on building a new privacy-oriented database system called EthicalDB. EthicalDB utilizes blockchain technology to codify both database schema and database permissions. All data in EthicalDB must be associated with an entity in the database and predefined by the schema as public or private data. Permissions are also defined in the schema. Private data is stored encrypted within EthicalDB in a special way that requires multiple nodes to provide decryption keys to access the private data. This forms the basis of governance and accountability in the system such that no one node can access the private data. For private data to be accessed, a private data request must be submitted to the blockchain ledger from an entity existing within EthicalDB. The nodes validate that the entity has permission to access the requested private data and then submit decryption keys for the entity to be able to access the data. In this way, there is no separation between data access and audit — you must submit a data request to get access to the data.
