Получается нужно два ключа: один для передачи по сети, а второй для
хранения и дедупликации.
Минуса этого дела два:
1) Нужно шифровать и дешифровать на сервере --- лишняя нагрузка на процессор
2) В случае взлома сервера возможно поиметь весь контент всех пользователей.
Или недалеко с шифрованным файлом хранить его ключ. Тогда при получении
файла дешифруем его считаем хэш и решаем дубль или нет.
08.06.2014 15:40, Alexander Lourier пишет:
1. А хранить тогда файл, зашифрованный чьим ключом?
2. Что будет, если клиент соврёт, что он прислал зашифрованный файл с
контентом A, а на самом деле - там контент B? Сервер потом попытается
дедуплицировать данные другого пользователя, который пытается
сохранить контент A, а сервер уже имеет такой файл (как он думает), и
не сохранит его. Потом второй пользователь запросит свой файл обратно,
и получит B.
По поводу п. 2 можно подумать в сторону алгоритмов доказательства с
нулевым разглашением. Клиент, сохраняя файл, должен доказать, что
зашифрованный файл, который он присылает, имеет указанную контрольную
сумму. Не уверен, что даже если это получится, будет хоть сколь-либо
быстро работать.
8 июня 2014 г., 13:07 пользователь Walery Studennikov
<[email protected] <mailto:[email protected]>> написал:
Считать хеш на клиенте, перед отправкой шифрованного контента,
пока он ещё не зашифрован.
--
Moscow.pm mailing list
[email protected] <mailto:[email protected]> | http://moscow.pm.org
--
Moscow.pm mailing list
[email protected] | http://moscow.pm.org
