Я имею дело с ненадежным внешним хранилищем и должен убедиться, что поставщик хранилища не скрывает никаких записей в запросе.
Пример:
У меня есть два доверенных объекта TA и TB, эти объекты должны иметь возможность изменять данные, хранящиеся в облачном/ненадежном хранилище, но никто другой. Поэтому мое решение я оснащаю TA и TB общедоступными ключами, и у меня есть структура данных, которую можно сравнить с таблицей с версиями:
Ver | Data | Signature | Signee
4 | ... | (AAAAAAAAA)_TA | TA
3 | ... | (ZZZZZZZZZ)_TB | TB
2 | ... | (YYYYYYYYY)_TA | TA
1 | ... | (XXXXXXXXX)_TA | TA
Поэтому, когда я извлекаю такую таблицу у поставщика хранилища, я могу легко проверить подписи и проверить правильность подписи, разрешено ли подписчику изменять таблицу или нет.
Однако я также хотел бы проверить полноту записи. Скажем, TA загружает версию 4, но TB знает только все записи до версии 3. Теперь поставщик хранилища может полностью отказаться от версии 4, когда TB запрашивает ее.
Поскольку между TA и TB нет прямого бокового канала, невозможно обменять текущую версию. Есть ли способ обойти это?
Я подумывал о том, чтобы периодически вставлять фиктивные записи, чтобы хотя бы некоторое время убедиться. Тем не менее, этот подход не обладает масштабируемостью и приведет к большому количеству накладных расходов на хранение и подписи. Каково фактическое системное свойство, которое я ищу (трудно найти исследование для чего-то, чего вы не знаете)?