Господа,
у меня уже давно крутится в голове вопрос, на который я не могу найти ответа.
Вот его формулировка:
Пускай у нас есть файловое хранилище — пускай, тот же MegaUpload Кима Доткома.
Для надежного хранения фалов мы берем, и шифруем файл, прежде чем его положить на хранение.
Каждый пользователь шифрует его своим собственным открытым ключом шифрования.
Соответственно, для расшифровки скачанного из хранилища файла пользователь использует свой собственный закрытый ключ.
(ну, или тайную часть открытого ключа, как это правильнее назвать?)
Все хорошо, секьюрно, но пропадает возможность дедупликации данных:
если Алиса и Боб решили положить туда фильм "унесенные ветром", то этот файл будет присутствовать в ДВУХ экземплярах,
каждый из которых представляет собой уникальный набор байтов.
Хотя оба эти набора шифруют ОДИН И ТОТ ЖЕ исходный набор байтов.
Каков должен быть механизм, который бы позволил с одной стороны — шифровать данные,
а с другой стороны — их дедуплицировать?
На язык просится "давайте отдадим в хранилище незашифрованный файл, а там его дедуплицируют и потом уже зашифруют" — но вы сами понимаете, что это никуда не годится.
С другой стороны, очень похожая задача сущестует в мессендежрах,
которые осуществляют end-to-end шифрование.
Там каждая инсталляция такого мессенджера — это отдельный клиент.
А когда я перехожу с компа на мобилку, то я хотел бы в своимх зашифрованных сессиях видеть историю тех сообщений, которые я написал на компе.
ТО есть видите — оченьпохожая задача: есть данные, которые должн быть зашифрованы "от всех", но некая маленькая группа "я и все мои устройства" должан иметь к ним доступ.
Хотя каждый конкретный экземпляр данных зашифрован своим ключом.
Мне кажется, что у криптографов есть ответ на этот вопрос, и может даже есть специальное название для такого механизма.
Но я поискал — не нашел.
Не будет ли кто нибудь любезен указать мне верное направление?
Здравствуйте, SteeLHeaD, Вы писали:
SLH>Господа, SLH>у меня уже давно крутится в голове вопрос, на который я не могу найти ответа. SLH>Вот его формулировка: SLH>Пускай у нас есть файловое хранилище — пускай, тот же MegaUpload Кима Доткома. SLH>Для надежного хранения фалов мы берем, и шифруем файл, прежде чем его положить на хранение.
SLH>Каждый пользователь шифрует его своим собственным открытым ключом шифрования. SLH>Соответственно, для расшифровки скачанного из хранилища файла пользователь использует свой собственный закрытый ключ. SLH>(ну, или тайную часть открытого ключа, как это правильнее назвать?)
Тут достаточно будет симметричного алгоритма шифрования с одним ключом. Вообще нужно сначала определиться от чего мы защищаемся при помощи криптографии,а уже потом думать как это реализовать.
Здравствуйте, SteeLHeaD, Вы писали:
SLH>Каков должен быть механизм, который бы позволил с одной стороны — шифровать данные, SLH>а с другой стороны — их дедуплицировать?
Общего решения, насколько мне известно, нет. Сервисы с честным e2e шифрованием либо не дедуплицируют, либо дедуплицируют в рамках одного аккаунта.
SLH>А когда я перехожу с компа на мобилку, то я хотел бы в своимх зашифрованных сессиях видеть историю тех сообщений, которые я написал на компе. SLH>ТО есть видите — оченьпохожая задача: есть данные, которые должн быть зашифрованы "от всех", но некая маленькая группа "я и все мои устройства" должан иметь к ним доступ.
Это задача попроще. Когда оба устройства в сети, они могут обменяться ключами.
WhatsApp решил задачу еще проще — он не хранит историю на серверах.
Еще кто-то (не помню, Signal кажется) для работы с desktop версией требует, чтобы мобильный клиент также был в сети, и весь трафик идет через него.
Здравствуйте, wildwind, Вы писали:
W>Общего решения, насколько мне известно, нет. Сервисы с честным e2e шифрованием либо не дедуплицируют, либо дедуплицируют в рамках одного аккаунта.
Спасибо.
Но смотрите, я придумал "наколенный" алгоритм, который может работать:
Пускай Алиса и Боб хотят хранить фильм "унесенные ветром" в зашифрованном виде в облачном хранилище.
Я делаю вот что:
1) я беру исходный файл, и считаю его хеш Х.
2) на основе Х я создаю пару (публичный+приватный) ключей.
3) я шифрую файл публичным ключом, а приватный помещаю в некое моё частное защищенное хранилище (я же всё равно гед то храню приватные ключи).
При расшифровке:
4) У меня загрузился из облака файл Х.
5) я просто пробую КАЖДЫМ ИЗ ИМЕЮЩИХСЯ у меня приватным ключом расшифровывать этот файл.
6) После расшифровки файла любым ключом я считаю его хеш Х1, на его основе созадю тем же самым алгоритмом, что и в пункте 2), пару ключей.
И сверяю: если приватный ключ, полученный только что совпал с тем, который хранится у меня в защищенном хранилище — значит, я подобрал для расшифровки правильную пару ключей и получил исходный файл.
Получается, что на основе одного и того же файла я получу одну и ту же пару ключей.
И это позволяет одинаково зашифровать файл, и таким образом получить дедупликацию.
Но, так как я не раскрываю приватный ключ, я не даю КОМУ УГОДНО возможности расшифровать файл.
Проблема только в том, что это у этого алгоритма вычислительная сложность растёт пропорционально кол-ву файлов.
(Я бы предпочёл, чтобы она росла пропорционально кол-ву участников "частной группы", которым доступен файл, или как то так)
Но я этот алгоритм придумал за 15 мину, и я не знаком с криптографией.
Как то не верится, что люди, профессионально этим занимающиеся, не придумали решения этой задачи.
Здравствуйте, SteeLHeaD, Вы писали:
SLH>Здравствуйте, wildwind, Вы писали:
W>>Общего решения, насколько мне известно, нет. Сервисы с честным e2e шифрованием либо не дедуплицируют, либо дедуплицируют в рамках одного аккаунта.
SLH>Спасибо. SLH>Но смотрите, я придумал "наколенный" алгоритм, который может работать:
SLH>Пускай Алиса и Боб хотят хранить фильм "унесенные ветром" в зашифрованном виде в облачном хранилище. SLH>Я делаю вот что:
SLH>1) я беру исходный файл, и считаю его хеш Х. SLH>2) на основе Х я создаю пару (публичный+приватный) ключей.
SLH>3) я шифрую файл публичным ключом, а приватный помещаю в некое моё частное защищенное хранилище (я же всё равно гед то храню приватные ключи).
У тебя в основе системы лежит алгоритм без ключа. В криптографии по умолчанию пологается, что алгоритм шифрования известен, а ключ не известен. В итоге шифрование есть, а защиты нет.
Здравствуйте, SteeLHeaD, Вы писали:
SLH>2) на основе Х я создаю пару (публичный+приватный) ключей.
Подробнее, только на основе хэша или чего-то ещё? То есть зная хэш файла, Алиса сможет расшифровать файл Боба?
SLH>3) я шифрую файл публичным ключом, а приватный помещаю в некое моё частное защищенное хранилище (я же всё равно гед то храню приватные ключи).
А публичный что? Выбрасываешь?
SLH>Получается, что на основе одного и того же файла я получу одну и ту же пару ключей. SLH>И это позволяет одинаково зашифровать файл, и таким образом получить дедупликацию.
Я так и не понял, как будет работать дедупликация. Она ведь должна выполняться в облаке. Какую именно информацию использует сервер и откуда ее получает?
Здравствуйте, wildwind, Вы писали:
W>Это задача попроще. Когда оба устройства в сети, они могут обменяться ключами. W>WhatsApp решил задачу еще проще — он не хранит историю на серверах.
Здравствуйте, SteeLHeaD, Вы писали:
SLH>Каков должен быть механизм, который бы позволил с одной стороны — шифровать данные, SLH>а с другой стороны — их дедуплицировать?
Если данные можно дедуплицировать, это значит, что не зная ключа шифрования, можно, тем не менее, узнать, совпадают ли данные с некими другими данными. А это уже некая утечка информации. Не все будут этому рады.
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, SteeLHeaD, Вы писали:
SLH>>2) на основе Х я создаю пару (публичный+приватный) ключей.
W>Подробнее, только на основе хэша или чего-то ещё? То есть зная хэш файла, Алиса сможет расшифровать файл Боба?
SLH>>3) я шифрую файл публичным ключом, а приватный помещаю в некое моё частное защищенное хранилище (я же всё равно гед то храню приватные ключи).
W>А публичный что? Выбрасываешь?
SLH>>Получается, что на основе одного и того же файла я получу одну и ту же пару ключей. SLH>>И это позволяет одинаково зашифровать файл, и таким образом получить дедупликацию.
W>Я так и не понял, как будет работать дедупликация. Она ведь должна выполняться в облаке. Какую именно информацию использует сервер и откуда ее получает?
Первое — да, зная хеш файла — можно расшифровать файл.
Но Алиса и Боб и так принадлежат к "клубу любителей унесенных ветром" — им не надо шифровать файл друг от друга, он у них одинаковый.
второе (насчет "А публичный что? Выбрасываешь?") — да, тут я погорячился.
Можно просто шифровать файл с использованием его хэша.
Тогда получается вот что:
у одинаковых файлов — одинаковые хэши.
А все люди, которые обладают этими файлами — им не надо шифровать файлы друг от друга.
Им надо зашифровать файл от всех, у кого этого файла нет.
Так у кого нет файла — тот и хэша его не знает, потому что нет файла, на основе которого его можно посчитать.
На основе одних и тех же хэшей файлы шифруются в одинаковые наборы байтов — то есть, работает дедупликация.
Достаточно хранить одну зашифрованную копию файла, и выдвавать её всем кто попросит.
Если они знают хэш — они знают ключ расшировки, и расшифруют файл.
Я не говорю, что это рабочий алгоритм.
Но он демонстрирует, что задача не так сложна, как кажется.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, SteeLHeaD, Вы писали:
SLH>>Каков должен быть механизм, который бы позволил с одной стороны — шифровать данные, SLH>>а с другой стороны — их дедуплицировать?
Pzz>Если данные можно дедуплицировать, это значит, что не зная ключа шифрования, можно, тем не менее, узнать, совпадают ли данные с некими другими данными. А это уже некая утечка информации. Не все будут этому рады.
Да, я осознаю это.
По настоящему секретные данные — лучше не дедуплицировать.
Но применительно к файлохранилищу — всё равно там большая часть людей котиков держат.
Ну да, мы узнали, что у Алисы и Боба есть фото одного и того же котика.
Но это — не очень высокий риск в случае "некритичных" данных.
То есть, я ставлю цели так:
на первом месте по значимости, самое главное — дедупликация.
На втором месте — шифрование. То есть, файл не должен помещаться в хранилище НЕЗАШИФРОВАННЫМ.
И не должно быть механизма, который позволяет кому то (например, поставщику услуг) получить доступ к исходному файлу.
Здравствуйте, SteeLHeaD, Вы писали:
SLH>По настоящему секретные данные — лучше не дедуплицировать. SLH>Но применительно к файлохранилищу — всё равно там большая часть людей котиков держат. SLH>Ну да, мы узнали, что у Алисы и Боба есть фото одного и того же котика. SLH>Но это — не очень высокий риск в случае "некритичных" данных.
Хуже, если мы узнали, что у Алисы и Боба одна и таже порнокартинка с изображением малолетних, и при этом Боб на нее дрочит, а Алиса работает в полиции. На основании этих данных Боба могут и посадить.
SLH>То есть, я ставлю цели так: SLH>на первом месте по значимости, самое главное — дедупликация. SLH>На втором месте — шифрование. То есть, файл не должен помещаться в хранилище НЕЗАШИФРОВАННЫМ. SLH>И не должно быть механизма, который позволяет кому то (например, поставщику услуг) получить доступ к исходному файлу.
Если бы такой алгоритм сущесвовал, это означало бы, что существует некая форма хранения файла, которую могут расшифровать и Алиса и Боб, не раскрывая при этом своих секретов ни друг другу, ни серверу. Интуитивно мне кажется, что этого сделать нельзя. Могу ошибаться.
Здравствуйте, SteeLHeaD, Вы писали:
SLH>Им надо зашифровать файл от всех, у кого этого файла нет.
Часто кроме этого, нужно зашифровать информацию о том, какие файлы у них есть.
SLH>Так у кого нет файла — тот и хэша его не знает, потому что нет файла, на основе которого его можно посчитать.
Если говорить о файлах типа "унесенных ветром", то они есть в интернете, можно скачать и посчитать хэш.
Предположим, в интернет выкладывается очередной файл с ЦП. Или с казнью в ИГ. Или с критикой ПуЭрдогана. Полиция его скачивает, считает хэш и отправляет в наше облако с запросом "у каких пользователей есть файл с данным хэшем". Получает список и выезжает к ним. Кстати, именно такая система налажена в DropBox, и для полиции, и для правообладателей.
SLH>На основе одних и тех же хэшей файлы шифруются в одинаковые наборы байтов — то есть, работает дедупликация.
Вместо того, чтобы повторять это как мантру, ты попробуй расписать, как именно она работает. Пока я не вижу, чтобы она работала.
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, SteeLHeaD, Вы писали:
SLH>>Им надо зашифровать файл от всех, у кого этого файла нет.
W>Часто кроме этого, нужно зашифровать информацию о том, какие файлы у них есть.
SLH>>Так у кого нет файла — тот и хэша его не знает, потому что нет файла, на основе которого его можно посчитать.
W>Если говорить о файлах типа "унесенных ветром", то они есть в интернете, можно скачать и посчитать хэш.
W>Предположим, в интернет выкладывается очередной файл с ЦП. Или с казнью в ИГ. Или с критикой ПуЭрдогана. Полиция его скачивает, считает хэш и отправляет в наше облако с запросом "у каких пользователей есть файл с данным хэшем". Получает список и выезжает к ним. Кстати, именно такая система налажена в DropBox, и для полиции, и для правообладателей.
SLH>>На основе одних и тех же хэшей файлы шифруются в одинаковые наборы байтов — то есть, работает дедупликация.
W>Вместо того, чтобы повторять это как мантру, ты попробуй расписать, как именно она работает. Пока я не вижу, чтобы она работала.
Спасибо за пояснения на примере дропбокс.
В общем, я согласен с критикой.
Лучше было бы, если бы шифрование файла осуществлялось на основе тех данных, которые есть у "клуба обладателей данным файлом",
и эта операция была бы не обратимой — то есть, скачав файл из интеренета, нельзя было на его основе найти тех,К то хранить этот файл у себя в облаке.
Но тот пример алгоритма, который я привел — это только пример.
Для меня ответ довольно очевиден:
если у меня есть N копий файла объема M, и эти файлы шифруются каждый своим ключём, превращаясь в файлы объема M1, M2 и т.п.
(На больших файлах можно принять — приблизительно — что M=M1=M2....)
Но эти зашифрованные файлы не могут быть "объявлены одинаковыми", поэтому каждый из них надо хранить отдельно, и они займут место M*N
Если же один и тот же файл зашифрован с одним и тем же ключём — то достаточно хранить только одну его копию, и это займёт место М.
Выиигрыш с первой схемой в N раз, где N — кол-во людей с одним и тем же файлом.
Вот это я и называю дедупликацией. (дедупликацийе на уровне файлов, если угодно. в отличие от дедупликации на уровне блоков, напрмиер,в ZFS)
Здравствуйте, Pzz, Вы писали:
Pzz>Если бы такой алгоритм сущесвовал, это означало бы, что существует некая форма хранения файла, которую могут расшифровать и Алиса и Боб, не раскрывая при этом своих секретов ни друг другу, ни серверу. Интуитивно мне кажется, что этого сделать нельзя. Могу ошибаться.
я с Вами согласен.
Это кажется контринтуитивным.
Но подумайте: ведь и шифрование с открытым ключем — это вещь, в которую веришь не сразу.
Это некая схема, которую надо понять, привыкнуть, и тогда она перестаёт казаться невозможной
Здравствуйте, SteeLHeaD, Вы писали:
SLH>Насчет дедупликации: SLH>может,я неправильно понимаю Ваш вопрос? SLH>Для меня ответ довольно очевиден:
Вопрос не в том, как работает дедупликация вообще, это я понимаю. Вопрос в том, как она будет работать вместе с твоей криптосхемой.
Представь себя на месте сервера в облаке. К тебе поступает запрос от клиента: сохранить файл. Дальше передается имя файла, сами данные и т.д. В общем, протокол в твоей власти. Тебе нужно придумать такой протокол, чтобы сервер мог выполнить дедупликацию, и содержимое файлов оставалось зашифрованным end-to-end. Как я понял, этим ты все еще не готов поступиться.
Аналогично с запросом на чтение.
Здравствуйте, Pzz, Вы писали:
Pzz>Если бы такой алгоритм сущесвовал, это означало бы, что существует некая форма хранения файла, которую могут расшифровать и Алиса и Боб, не раскрывая при этом своих секретов ни друг другу, ни серверу. Интуитивно мне кажется, что этого сделать нельзя. Могу ошибаться.
Сервер шифрует файл случайно сгенерированным симметричным ключом. Этот ключ шифруется отдельно публичными ключами Алисы и Боба. Эти два зашифрованных ключа сохраняются вместе с файлом.
Здравствуйте, SteeLHeaD, Вы писали:
SLH>Тогда получается вот что: SLH>у одинаковых файлов — одинаковые хэши.
Это смотря что считать "одинаковым".
SLH>А все люди, которые обладают этими файлами — им не надо шифровать файлы друг от друга.
У одного жалкая пиратская экранка, у другого купленная за дорого Blu-ray FullHD.
А так да, файлы "одинаковые".
SLH>Им надо зашифровать файл от всех, у кого этого файла нет.
Особенно это нужно Бобу, который заплатил за коллекционное издание Blu-ray FullHD и рассчитывает приглашать Алису на приватный ночной просмотр.
SLH>Так у кого нет файла — тот и хэша его не знает,
гугл. гугл знает.
торрент. магнет ссылка по сути хэш и есть. например в условиях, когда на самом торрент трекере заблокирован прямой доступ, поиск по нему через гугл дает тот же эффект, как если бы ты был зарегистрированным пользователем из "хорошей страны".
(лайфхак такой).
Здравствуйте, Pzz, Вы писали:
W>>Это задача попроще. Когда оба устройства в сети, они могут обменяться ключами. W>>WhatsApp решил задачу еще проще — он не хранит историю на серверах.
Pzz>А как WhatsApp соблюдает закон Яровой?
Здравствуйте, wildwind, Вы писали:
Pzz>>Если бы такой алгоритм сущесвовал, это означало бы, что существует некая форма хранения файла, которую могут расшифровать и Алиса и Боб, не раскрывая при этом своих секретов ни друг другу, ни серверу. Интуитивно мне кажется, что этого сделать нельзя. Могу ошибаться.
W>Сервер шифрует файл случайно сгенерированным симметричным ключом. Этот ключ шифруется отдельно публичными ключами Алисы и Боба. Эти два зашифрованных ключа сохраняются вместе с файлом.
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, SteeLHeaD, Вы писали:
SLH>>Насчет дедупликации: SLH>>может,я неправильно понимаю Ваш вопрос? SLH>>Для меня ответ довольно очевиден:
W>Вопрос не в том, как работает дедупликация вообще, это я понимаю. Вопрос в том, как она будет работать вместе с твоей криптосхемой.
W>Представь себя на месте сервера в облаке. К тебе поступает запрос от клиента: сохранить файл. Дальше передается имя файла, сами данные и т.д. В общем, протокол в твоей власти. Тебе нужно придумать такой протокол, чтобы сервер мог выполнить дедупликацию, и содержимое файлов оставалось зашифрованным end-to-end. Как я понял, этим ты все еще не готов поступиться. W>Аналогично с запросом на чтение.
Я считал, что файл передаётся на сервер уже зашифрованным.
Шифруется и расшифровывается он на клиенте.
В моей "детской" (во всех отношениях) схеме шифрования — это возможно.
Причём, я не то, чтобы защищаю именно эту схему,
я хочу как раз у более опытных людей спросить про правильную схему.
И про правильную схему условия очень хорошо сформулировал Pzz:
"Если бы такой алгоритм сущесвовал, это означало бы, что существует некая форма хранения файла,
которую могут расшифровать и Алиса и Боб, не раскрывая при этом своих секретов ни друг другу, ни серверу."
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, wildwind, Вы писали:
Pzz>>>Если бы такой алгоритм сущесвовал, это означало бы, что существует некая форма хранения файла, которую могут расшифровать и Алиса и Боб, не раскрывая при этом своих секретов ни друг другу, ни серверу. Интуитивно мне кажется, что этого сделать нельзя. Могу ошибаться.
W>>Сервер шифрует файл случайно сгенерированным симметричным ключом. Этот ключ шифруется отдельно публичными ключами Алисы и Боба. Эти два зашифрованных ключа сохраняются вместе с файлом.
Pzz>Т.е., сервер знает контент файла?
По мому, самый ценный совет мне дал wildwind, спасибо большое!
Смотрите.
Действительно, у Алисы есть файл.
Потом Алтса шифрует его случайно сгенерированным ключом kSimm при помощи симметричного алгоритма.
Зашифрованный файл она кладёт на сервер.
Чтобы сервер не знал содержимого файла, Алиса не передает на сервер ключ шифрования.
Но она шифрует его своим открытым ключем kAliceOpen, и получает файл k0(kAliceOpen, kSimm).
Этот ключ она тоже сохраняет на сервере.
Результат:
сервер содержит зашифрованый файл, ключа от которогоу сервера нет.
А Алиса, имея приватный ключ, может взять с сервера k0, расшифровать его своим приватным ключем и получить ключ шифрования kSimm.
Здравствуйте, Pzz, Вы писали:
Pzz>>>Если бы такой алгоритм сущесвовал, это означало бы, что существует некая форма хранения файла, которую могут расшифровать и Алиса и Боб, не раскрывая при этом своих секретов ни друг другу, ни серверу. Интуитивно мне кажется, что этого сделать нельзя. Могу ошибаться.
W>>Сервер шифрует файл случайно сгенерированным симметричным ключом. Этот ключ шифруется отдельно публичными ключами Алисы и Боба. Эти два зашифрованных ключа сохраняются вместе с файлом.
Pzz>Т.е., сервер знает контент файла?
Здравствуйте, SteeLHeaD, Вы писали:
SLH>Я считал, что файл передаётся на сервер уже зашифрованным. SLH>Шифруется и расшифровывается он на клиенте.
В этом и проблема. Шифруется файл на клиенте, а дедупликацию нужно делать на сервере (иначе какой в ней смысл).
SLH>В моей "детской" (во всех отношениях) схеме шифрования — это возможно. SLH>Причём, я не то, чтобы защищаю именно эту схему, SLH>я хочу как раз у более опытных людей спросить про правильную схему.
Так я ответил сразу, "правильной" схемы пока нет. А если уж ты взялся ее придумывать, то придумывай до конца, не оставляй пробелов.
Передаём серверу хеш файла. Он нам возвращает список клиентов, которые заливали этот файл. Связываемся с этими клиентами, генерируем вместе новый ключ (что-то вроде диффи-хельмана), шифруем новым ключом файл, заливаем на сервер, клиенты проверяют, что залито то, что нужно, дают одобрение и сервер удаляет предыдущую копию.
Здравствуйте, vsb, Вы писали:
vsb>Передаём серверу хеш файла. Он нам возвращает список клиентов, которые заливали этот файл. Связываемся с этими клиентами, генерируем вместе новый ключ (что-то вроде диффи-хельмана), шифруем новым ключом файл, заливаем на сервер, клиенты проверяют, что залито то, что нужно, дают одобрение и сервер удаляет предыдущую копию.
Спасибо за идею!
Я еще не осознал ее крутизны, но продумаю её на днях.
Здравствуйте, SteeLHeaD, Вы писали:
vsb>>Передаём серверу хеш файла. Он нам возвращает список клиентов, которые заливали этот файл. Связываемся с этими клиентами, генерируем вместе новый ключ (что-то вроде диффи-хельмана), шифруем новым ключом файл, заливаем на сервер, клиенты проверяют, что залито то, что нужно, дают одобрение и сервер удаляет предыдущую копию.
SLH>Спасибо за идею! SLH>Я еще не осознал ее крутизны, но продумаю её на днях.
Тут ещё важно мотивировать клиента на дедупликацию, т.к. клиент всегда может зашифровать файл ещё один раз перед дедупликацией (или просто дописать любую чушь в любом месте), чтобы файл стал ни на что не похож. Или даже обманывать сервер, передавая неправильный хэш, проверить-то не выйдет. Поэтому сервер должен, например, при удачной дедупликации выставлять клиенту счёт меньше (т.е. если у двух клиентов один и тот же файл размером в терабайт, то каждый после дедупликации платит за 500 гигабайтов).
Здравствуйте, vsb, Вы писали:
vsb>Передаём серверу хеш файла. Он нам возвращает список клиентов, которые заливали этот файл. Связываемся с этими клиентами, генерируем вместе новый ключ (что-то вроде диффи-хельмана), шифруем новым ключом файл, заливаем на сервер, клиенты проверяют, что залито то, что нужно, дают одобрение и сервер удаляет предыдущую копию.
Здравствуйте, wildwind, Вы писали:
vsb>>Передаём серверу хеш файла. Он нам возвращает список клиентов, которые заливали этот файл. Связываемся с этими клиентами, генерируем вместе новый ключ (что-то вроде диффи-хельмана), шифруем новым ключом файл, заливаем на сервер, клиенты проверяют, что залито то, что нужно, дают одобрение и сервер удаляет предыдущую копию.
W>Вот тут всё и обломится.
Почему? Связываться можно и через сервер, и не в реал-тайме.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, wildwind, Вы писали:
vsb>>>Передаём серверу хеш файла. Он нам возвращает список клиентов, которые заливали этот файл. Связываемся с этими клиентами, генерируем вместе новый ключ (что-то вроде диффи-хельмана), шифруем новым ключом файл, заливаем на сервер, клиенты проверяют, что залито то, что нужно, дают одобрение и сервер удаляет предыдущую копию.
W>>Вот тут всё и обломится.
vsb>Почему? Связываться можно и через сервер, и не в реал-тайме.
Мы не доверяем серверу в плане хранения тайны(как я понял из т.з), сервер может выдать себя за одного из клиентов и получить ключ.
Здравствуйте, Qulac, Вы писали:
W>>>Вот тут всё и обломится.
vsb>>Почему? Связываться можно и через сервер, и не в реал-тайме.
Q>Мы не доверяем серверу в плане хранения тайны(как я понял из т.з), сервер может выдать себя за одного из клиентов и получить ключ.
Согласен. Тогда предлагаю небольшую модификацию. Во-первых файлы хранятся не целиком, а сначала делятся на куски определённого размера: с одной стороны не слишком мелкие, с другой стороны клиент должен быть способен скачать нужный кусок без особых проблем. Скажем 100 мегабайтов. И каждый блок шифруется и дедуплицируется отдельно. Во-вторых при согласовании нового ключа каждому клиенту отправляется запрос на подтверждение того, что клиент владеет этим файлом, т.е. просьба подсчитать хеш от заданного куска. Нормальный клиент скачает с сервера этот кусок, расшифрует и ответит.
Тут надо следить за тем, чтобы сервер не устроил MitM-атаку, подменив одного из клиентов. Вроде с закрытыми-открытыми ключами это всё можно сделать.
А как такое? Идея — публиковать ключ шифрования файла зашифрованный самим файлом.
Клиент C1 геренит случайный симметричный ключ kSym. Шифрует им файл F. Шифрует своим публичным ключом kPubC1 ключ kSym и отправляет на сервер:
C1Secret = asymCrypt(key: kPubC1, data: kSym) — асимметрично зашифрованный ключ симметричного шифрования kSym
cipherData = symCrypt(key: kSym, data: F) — симметрично зашифрованный файл
dataSignature = hash(F) — сигнатура файла для поиска дупликатов
salt — некая на клиенте сгенеринованная случайная соль
magic = symCrypt(key: hash(F+salt), data: kSym) — симметричный ключ kSym симметрично зашифрованный хешем от файла F и соли.
Клиент C2 имеет файл F. Считает hash(F), отправляет на сервер. Сервер лезет в субд и находит magic и salt по dataSignature, отправляет её клиенту. Клиент имея F и salt считает hash(F+salt). Затем вычисляет symDecrypt(key: hash(F+salt), data: magic) что выдаст нам kSym, а магия в том, что этот kSym будет доступен только тому у кого уже есть файл F. А дальше просто — C2 просто отправляет asymCrypt(key: kPubC2, data: kSym) серверу, зашифрованные данные на сервере уже есть. Клиент C2 так же может верифицировать эти данные загрузив cipherData к себе и сравнив F с symDecrypt(key: kSym, data: cipherData).
После этого на сервере будут хранится только C1Secret, C2Secret, cipherData, dataSignature, salt, magic.
И, таки да, сервер должен мотивировать клиентов делать дедупликацию и отправлять валидный magic, т.к. сервер корректность проверить не может.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, SteeLHeaD, Вы писали:
·>А как такое? Идея — публиковать ключ шифрования файла зашифрованный самим файлом.
·>Клиент C1 геренит случайный симметричный ключ kSym. Шифрует им файл F. Шифрует своим публичным ключом kPubC1 ключ kSym и отправляет на сервер: ·>
·> C1Secret = asymCrypt(key: kPubC1, data: kSym) — асимметрично зашифрованный ключ симметричного шифрования kSym ·> cipherData = symCrypt(key: kSym, data: F) — симметрично зашифрованный файл ·> dataSignature = hash(F) — сигнатура файла для поиска дупликатов ·> salt — некая на клиенте сгенеринованная случайная соль ·> magic = symCrypt(key: hash(F+salt), data: kSym) — симметричный ключ kSym симметрично зашифрованный хешем от файла F и соли. ·>·>Клиент C2 имеет файл F. Считает hash(F), отправляет на сервер. Сервер лезет в субд и находит magic и salt по dataSignature, отправляет её клиенту. Клиент имея F и salt считает hash(F+salt). Затем вычисляет symDecrypt(key: hash(F+salt), data: magic) что выдаст нам kSym, а магия в том, что этот kSym будет доступен только тому у кого уже есть файл F. А дальше просто — C2 просто отправляет asymCrypt(key: kPubC2, data: kSym) серверу, зашифрованные данные на сервере уже есть. Клиент C2 так же может верифицировать эти данные загрузив cipherData к себе и сравнив F с symDecrypt(key: kSym, data: cipherData). ·>После этого на сервере будут хранится только C1Secret, C2Secret, cipherData, dataSignature, salt, magic.
·>И, таки да, сервер должен мотивировать клиентов делать дедупликацию и отправлять валидный magic, т.к. сервер корректность проверить не может.
привет,
в смысле дедупликации — это просто обалденно.
Но не понятно, как решить задачу "я клиент, пускай даже тот, у кого был файл. Сейчас я, не имея файла, хочу забрать его с сервера и расшифровать".
Не могли бы Вы пояснить, что то я не соображу, как такое сделать?
Здравствуйте, SteeLHeaD, Вы писали:
SLH>в смысле дедупликации — это просто обалденно. SLH>Но не понятно, как решить задачу "я клиент, пускай даже тот, у кого был файл. Сейчас я, не имея файла, хочу забрать его с сервера и расшифровать". SLH>Не могли бы Вы пояснить, что то я не соображу, как такое сделать?
Так стандартно же — взять с сервера C1Secret и cipherData, расшифровать своим приватным ключом asymDecrypt(key: kPrivC1, data: C1Secret) получится kSym и им расшифровать cipherData.
Суть в том, что kSym доступен тем и только тем, у кого есть приватные ключи или у кого есть сам файл.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>После этого на сервере будут хранится только C1Secret, C2Secret, cipherData, dataSignature, salt, magic.
Если сервер знает хэши, то он фактически знает, кто какие файлы хранит (за исключением абсолютно уникальных, которых обычно не так много).
Ну и накладные расходы, конечно, огромные.
Здравствуйте, wildwind, Вы писали:
W>Если сервер знает хэши, то он фактически знает, кто какие файлы хранит (за исключением абсолютно уникальных, которых обычно не так много). W>Ну и накладные расходы, конечно, огромные.
Дедупликация подразумевает, что сервер знает, кто какие файлы хранит. Сервер всегда может прикинуться клиентом, попробовать залить интересующий файл и определить после этого, с какими клиентами произошла дедупликация. Это вне зависимости от используемых алгоритмов и протоколов. Поэтому от такой утечки данных защититься невозможно.
Здравствуйте, wildwind, Вы писали:
W>·>После этого на сервере будут хранится только C1Secret, C2Secret, cipherData, dataSignature, salt, magic. W>Если сервер знает хэши, то он фактически знает, кто какие файлы хранит (за исключением абсолютно уникальных, которых обычно не так много).
Это ещё почему? Сервер будет только знать, что клиент "C1" и клиент "C2" хранят одинаковый файл, и то при условии что оба согласились на дедупликацию, дав серверу верный magic и dataSignature. И, собственно, всё.
W>Ну и накладные расходы, конечно, огромные.
Какие огромные? На каждый файл — в пределах килобайта (salt, dataSignature, magic) и на каждого клиента CnSecret — тоже килобайт. Ну и, очевидно, cipherData — равное по объёму файлу.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, vsb, Вы писали:
W>>Если сервер знает хэши, то он фактически знает, кто какие файлы хранит (за исключением абсолютно уникальных, которых обычно не так много). W>>Ну и накладные расходы, конечно, огромные. vsb>Дедупликация подразумевает, что сервер знает, кто какие файлы хранит. Сервер всегда может прикинуться клиентом, попробовать залить интересующий файл и определить после этого, с какими клиентами произошла дедупликация. Это вне зависимости от используемых алгоритмов и протоколов. Поэтому от такой утечки данных защититься невозможно.
А откуда у сервера возьмётся этот самый интересующий файл?
Мало того, даже если кто-то и узнает что "файл X есть у клиентов C1, C2,... Cn" этого ещё не достаточно, чтобы узнать, что C2 это гражданин Vsb и где он живёт, это может быть лишь случайный UUID-клиента, оплата сервиса битками анонимно и закачка шла через Tor.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, vsb, Вы писали:
W>>Если сервер знает хэши, то он фактически знает, кто какие файлы хранит (за исключением абсолютно уникальных, которых обычно не так много). W>>Ну и накладные расходы, конечно, огромные. vsb>Дедупликация подразумевает, что сервер знает, кто какие файлы хранит. Сервер всегда может прикинуться клиентом, попробовать залить интересующий файл и определить после этого, с какими клиентами произошла дедупликация. Это вне зависимости от используемых алгоритмов и протоколов. Поэтому от такой утечки данных защититься невозможно.
Кстати, как вариант — сервер вообще может не хранить CnSecret, нужны только данные файла. Клиенты сами у себя kSym могут хранить как хотят.
Правда в таком случае станет непонятно с кого и сколько денег драть за хранение.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
W>>Ну и накладные расходы, конечно, огромные. ·>Какие огромные? На каждый файл — в пределах килобайта (salt, dataSignature, magic) и на каждого клиента CnSecret — тоже килобайт. Ну и, очевидно, cipherData — равное по объёму файлу.
Например, хэш файла нужно считать дважды — с солью и без. А файлы бывают немаленькие.
А CnSecret получается вообще лишние — ведь ключ вычисляется из magic.
Здравствуйте, wildwind, Вы писали:
W>>>Ну и накладные расходы, конечно, огромные. W>·>Какие огромные? На каждый файл — в пределах килобайта (salt, dataSignature, magic) и на каждого клиента CnSecret — тоже килобайт. Ну и, очевидно, cipherData — равное по объёму файлу. W>Например, хэш файла нужно считать дважды — с солью и без. А файлы бывают немаленькие.
Считай оба хеша + выполняй шифрование в один проход чтения файла, сразу отправляя шифрованный поток на сервер.
Т.е. накладные расходы как на время, так и на память практически нулевые.
W>А CnSecret получается вообще лишние — ведь ключ вычисляется из magic.
Если у тебя уже есть файл.
CnSecret используется клиентом потом, для закачки файла себе с сервера.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Считай оба хеша + выполняй шифрование в один проход чтения файла, сразу отправляя шифрованный поток на сервер.
Нельзя. Сначала нужно узнать, есть файл на сервере или нет. Для этого нужен хэш без соли. Если файл уже есть, тогда клиент получает соль. Так ведь у тебя.
·>CnSecret используется клиентом потом, для закачки файла себе с сервера.
Здравствуйте, wildwind, Вы писали:
W>·>Считай оба хеша + выполняй шифрование в один проход чтения файла, сразу отправляя шифрованный поток на сервер. W>Нельзя. Сначала нужно узнать, есть файл на сервере или нет. Для этого нужен хэш без соли. Если файл уже есть, тогда клиент получает соль. Так ведь у тебя.
Ну да.. ты прав. Но считать придётся дважды только если дубликат таки найден. Т.е. C2 начинает загружать файл пессимистично, отправляет в конце dataSignature и конце сервер может радостно выдать: "о! У меня уже такое есть! держи salt+magic и сэкономь $$$ на хранении" — ну и клиент ради экономии денег пересчитает хеш с данной солью и вычислит kSym, который был сгенерён C1.
W>·>CnSecret используется клиентом потом, для закачки файла себе с сервера. W>Зачем, если есть magic?
Эээээ... ну дык клиент закачивает файл в хранилище не просто так по приколу, а с целью оттуда его потом выкачать на случай если этот файл у него сломается или потеряется; или банально захочет закачать его себе на другое устройство).
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, SteeLHeaD, Вы писали:
SLH>>в смысле дедупликации — это просто обалденно. SLH>>Но не понятно, как решить задачу "я клиент, пускай даже тот, у кого был файл. Сейчас я, не имея файла, хочу забрать его с сервера и расшифровать". SLH>>Не могли бы Вы пояснить, что то я не соображу, как такое сделать? ·>Так стандартно же — взять с сервера C1Secret и cipherData, расшифровать своим приватным ключом asymDecrypt(key: kPrivC1, data: C1Secret) получится kSym и им расшифровать cipherData.
·>Суть в том, что kSym доступен тем и только тем, у кого есть приватные ключи или у кого есть сам файл.
Точно.
Спасибо большое за пояснения и за приекрасный алгоритм!
Конечно, я его еще "не прочувствовал", надо его "попробовать на кошках",
но очень многообещающе!
Здравствуйте, SteeLHeaD, Вы писали:
SLH>Для надежного хранения фалов мы берем, и шифруем файл, прежде чем его положить на хранение. SLH>Каждый пользователь шифрует его своим собственным открытым ключом шифрования.
А что если шифровать файл его же, файла, хешем? Обычным AESом, например.
Вычисляем хеш файла, обязательно запоминаем его, и шифруем им файл. Вычисляем хеш шифровки, и этот хеш №2 у нас будет использоваться для идентификации и дедупликации.
Неудобство в том, что если клиент потерял хеш №1, то он не расшифрует свой файл. Ну так не надо терять. Или там же на сервере держать зашифрованный массив хешей №1.
Здравствуйте, Voblin, Вы писали:
V>А что если шифровать файл его же, файла, хешем? Обычным AESом, например.
V>Вычисляем хеш файла, обязательно запоминаем его, и шифруем им файл. Вычисляем хеш шифровки, и этот хеш №2 у нас будет использоваться для идентификации и дедупликации. V>Неудобство в том, что если клиент потерял хеш №1, то он не расшифрует свой файл. Ну так не надо терять. Или там же на сервере держать зашифрованный массив хешей №1.
Теоретически возможно, но практически такое облако никому не нужно. Облако для того и нужно, чтобы хранить то, что я могу потерять.
Кроме того, если чужие могут расшифровать мои файлы, то к чему вообще шифрование? Одно неудобство, проще уж без него. И дедупликация отлично работает.
Здравствуйте, wildwind, Вы писали:
V>>А что если шифровать файл его же, файла, хешем? Обычным AESом, например.
V>>Вычисляем хеш файла, обязательно запоминаем его, и шифруем им файл. Вычисляем хеш шифровки, и этот хеш №2 у нас будет использоваться для идентификации и дедупликации. V>>Неудобство в том, что если клиент потерял хеш №1, то он не расшифрует свой файл. Ну так не надо терять. Или там же на сервере держать зашифрованный массив хешей №1. W>Теоретически возможно, но практически такое облако никому не нужно. Облако для того и нужно, чтобы хранить то, что я могу потерять.
Так пароль от облака ты всё равно обязан помнить — если потеряешь — как потом тебя аутентифицировать?
W>Кроме того, если чужие могут расшифровать мои файлы, то к чему вообще шифрование? Одно неудобство, проще уж без него. И дедупликация отлично работает.
Прикол в том, что могут расшифровать только те, у кого уже есть твои файлы.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Прикол в том, что могут расшифровать только те, у кого уже есть твои файлы.
Да, но в моей схеме есть одна маленькая подлянка. Допустим, чел хранит в облаке файл запрещённой книжки "Поваренная книга анархиста". У товарища майора тоже есть экземпляр этого файла. Товарищ майор, если он имеет доступ к каталогу облака с указанием владельцев файлов, может выяснить, что этот чел — враг государства (притом любого) и нагрянуть к нему с обыском.
То есть схема пригодна тогда, когда факт владения файлом не является криминалом.
Здравствуйте, wildwind, Вы писали:
W>Теоретически возможно, но практически такое облако никому не нужно. Облако для того и нужно, чтобы хранить то, что я могу потерять.
Дедупликация нужна для больших файлов (мегабайты, сотни мегабайт, гигабайты). Для килобайтов и десятков килобайт дедупликация не нужна. Соответственно, расшифровывающие ключи того, что клиент сохранил в облако (32 штуки в одном килобайте для SHA-256), можно хранить в этом же облаке, но зашифрованные личным ключом юзера, и поэтому не дедуплицируемые.
W>Кроме того, если чужие могут расшифровать мои файлы, то к чему вообще шифрование? Одно неудобство, проще уж без него. И дедупликация отлично работает.
Как уже было сказано в другом комменте, злоумышленник может расшифровать только то, что у него и так уже есть безо всякой дополнительной расшифровки.
Здравствуйте, Voblin, Вы писали:
V>·>Прикол в том, что могут расшифровать только те, у кого уже есть твои файлы. V>Да, но в моей схеме есть одна маленькая подлянка. Допустим, чел хранит в облаке файл запрещённой книжки "Поваренная книга анархиста". У товарища майора тоже есть экземпляр этого файла. Товарищ майор, если он имеет доступ к каталогу облака с указанием владельцев файлов, может выяснить, что этот чел — враг государства (притом любого) и нагрянуть к нему с обыском.
Да твоя схема почти как моя
на практике — читать файл и считать хеш дважды придётся всегда. А в такой схеме идентифицировать владельцев (и даже их количество) вовсе не обязательно, я уже пояснял
на практике — читать файл и считать хеш дважды придётся всегда. А в такой схеме идентифицировать владельцев (и даже их количество) вовсе не обязательно, я уже пояснял
Если чуть-чуть модифицировать схему, то можно обойтись одним чтением (в случае, если файл уже есть в облаке).
Допустим, идентифицирующим хешем у нас будет SHA256(data), а шифрующим SHA256("Превед, медвед"+data). Или наоборот. Без разницы. Алиса поместила в облако киношку "Унесённые ветром.mkv", и теперь то же самое хочет сделать Боб. Боб прочитывает файл один раз, высчитывая сразу два хеша — идентифицирующий и шифрующий. Делает запрос к серверу с предложением поместить файл и с указанием идентифицирующего хеша. Сервер отвечает "ОК, файл помещён, дальнейших действий не требуется". Красота, разве нет?
А вот Алисе, первый раз помещающей файл в облако — да, придётся файл "Унесённые ветром.mkv" прочитать второй раз, чтобы зашифровать и передать.
V>>То есть схема пригодна тогда, когда факт владения файлом не является криминалом. ·>Нет, только когда клиенты заинтересованы в дедупликации.
В моей схеме не нужно даже заинтересованности. Оно как-бы само получается. Если опция "шифровать помещаемые данные" неотключаемая, то дедупликация работает. А если отключаемая, то тоже работает, но просто в два раза (и не более того) менее эффективно.
Что касается товарища майора и поваренной книги анархиста, то тут будет палево с использованием какой угодно дедупликации. Если верно весьма близкое к реальности предположение, что товарищ майор с ноги открывает дверь в серверную облачного хранилища. Тут обезопаситься можно только доп. мерами по анонимизации, из которых, как вы верно заметили, первыми на ум приходят TOR и биток. Хотя и они, конечно, ненадёжны. Особенно биток, который в плане анонимизации весьма палевный.
на практике — читать файл и считать хеш дважды придётся всегда. А в такой схеме идентифицировать владельцев (и даже их количество) вовсе не обязательно, я уже пояснял
.
V>Если чуть-чуть модифицировать схему, то можно обойтись одним чтением (в случае, если файл уже есть в облаке). V>Допустим, идентифицирующим хешем у нас будет SHA256(data), а шифрующим SHA256("Превед, медвед"+data). Или наоборот. Без разницы. Алиса поместила в облако киношку "Унесённые ветром.mkv", и теперь то же самое хочет сделать Боб. Боб прочитывает файл один раз, высчитывая сразу два хеша — идентифицирующий и шифрующий. Делает запрос к серверу с предложением поместить файл и с указанием идентифицирующего хеша. Сервер отвечает "ОК, файл помещён, дальнейших действий не требуется". Красота, разве нет? V>А вот Алисе, первый раз помещающей файл в облако — да, придётся файл "Унесённые ветром.mkv" прочитать второй раз, чтобы зашифровать и передать.
Ага, то же что и у меня, только вместо salt — захардкоженная константа. В принципе да, так тоже можно, вроде... В этом случае, если дедупликации случаются редко, то можно сразу за один проход делать — считать два хеша, шифровать пессимистично новым ключом и отправлять на сервер. В конце сервер может предложить клиенту использовать magic.
А ещё можно сделать быструю предварительную проверку на дедупликацию перед полной заливкой и съэкономить сетевой трафик, скажем, послав частичный dataSignature по первому мегабайту данных.
V>>>То есть схема пригодна тогда, когда факт владения файлом не является криминалом. V>·>Нет, только когда клиенты заинтересованы в дедупликации. V>В моей схеме не нужно даже заинтересованности. Оно как-бы само получается. Если опция "шифровать помещаемые данные" неотключаемая, то дедупликация работает. А если отключаемая, то тоже работает, но просто в два раза (и не более того) менее эффективно.
Ты исходишь из предположения, что клиенты ведут себя "честно". Клиенты могут отсылать неправильные хеши, а сервер проверить это никак не может и ничего не сможет дедуплицировать. Поэтому в системе с нулевым доверием сервер должен мотивировать клиентов на дедупликацию.
V>Что касается товарища майора и поваренной книги анархиста, то тут будет палево с использованием какой угодно дедупликации. Если верно весьма близкое к реальности предположение, что товарищ майор с ноги открывает дверь в серверную облачного хранилища. Тут обезопаситься можно только доп. мерами по анонимизации, из которых, как вы верно заметили, первыми на ум приходят TOR и биток. Хотя и они, конечно, ненадёжны. Особенно биток, который в плане анонимизации весьма палевный.
Да, хотя это несколько за рамками обсуждаемой крипто-схемы. А биток по сути нужен лишь для оплаты услуги хранения. Тут уж без конкретной предметной области и бизнес-модели обсуждать технические детали бесполезно.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Ты исходишь из предположения, что клиенты ведут себя "честно". Клиенты могут отсылать неправильные хеши, а сервер проверить это никак не может и ничего не сможет дедуплицировать. Поэтому в системе с нулевым доверием сервер должен мотивировать клиентов на дедупликацию.
В чём может быть мотив отсылать неправильные хеши? Чисто из вредности? Что клиент выигрывает, когда отсылает неправильный хеш? От дедупликации выигрывает и сервер (экономится трафик и место), и клиент (трафик и время).
ИМХО, нет смысла забивать себе голову соблюдением правила, если в нарушении правила никто не заинтересован.
Здравствуйте, Voblin, Вы писали:
V>·>Ты исходишь из предположения, что клиенты ведут себя "честно". Клиенты могут отсылать неправильные хеши, а сервер проверить это никак не может и ничего не сможет дедуплицировать. Поэтому в системе с нулевым доверием сервер должен мотивировать клиентов на дедупликацию. V>В чём может быть мотив отсылать неправильные хеши? V>Чисто из вредности? Что клиент выигрывает, когда отсылает неправильный хеш?
У клиента мотив — экономия вычислительных ресурсов. Или банально ошибка (упрощение) имплементации, или параноя. Ддосеры, в конце-концов.
V>От дедупликации выигрывает и сервер (экономится трафик и место), и клиент (трафик и время).
В случае если у некоего клиента всегда уникальные файлы, то дедупликация будет невыгодна клиенту.
V>ИМХО, нет смысла забивать себе голову соблюдением правила, если в нарушении правила никто не заинтересован.
Зависит от бизнес-требований. Но рассмотреть этот вопрос — обязательно.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
V>>Чисто из вредности? Что клиент выигрывает, когда отсылает неправильный хеш? ·>У клиента мотив — экономия вычислительных ресурсов. Или банально ошибка (упрощение) имплементации, или параноя. Ддосеры, в конце-концов.
Если облако платное, то можно завлечь клиента скидками. То есть если скидываешь уникальные файлы, то платишь 1 условный рубль/ГБ/год, а если по какому-то файлу обнаружился 1 аналог, то держи, дорогой, 30% скидку. И дальше по прогрессии, вплоть до скидки 90% при факторе 50. Помещая файлы в хранилище, можешь выбрать:
1. Получать скидку, если кто-то тоже выложит такое же.
2. Зашифровать наглухо и платить полную цену.
Хранишь в облаке подборку любимых mp3шек, фильмов и сериалов — тебе дёшево и удобно. Хранишь заведомо уникальное (видео с камеры наблюдения во дворе, например) — ну извини, ты один танцуешь эту девушку. Зато ты уверен (и в этом преимущество технологии), что никто левый из тех, кто этого видео не имел, его не позырит. Хочешь сохранить что-то глубоко личное и/или зашкварное — тоже не проблема, опция №2. Понятное дело, такое только за полную цену. Вот, кстати, и ответ на вопрос про товарища майора и поваренную книгу анархиста.
Давать юзеру самому принять решение — это правильно. Слишком много непонятных опций — это зло, а простой и понятный выбор — то, что людям нужно.
Кстати, заодно получается прикольно оплачиваемый файлообмен между юзерами системы. Допустим, я срипал и выложил киношку. И опубликовал оба ключа — шифрующий и идентифицирующий. Любой желающий может скачать файл, но для этого он должен хотя бы на время (можно установить минимальный срок хранения месяц) как-бы одним из владельцев этого файла. Чем больше владельцев, тем меньше платит каждый. Сервис тоже не обижен.
Вообще красивая получается идея. Мне нравится. Настоящий честный сервис. В лучших традициях. Безо всякой долбаной халявономики (freeconomy, оно же фрикономика), работающей по принципу "если тебе предлагают бесплатный товар, то значит, в этой сделке товаром являешься ты сам". Там, где тебе зачем-то нужен эксклюзив, ты его получаешь, но и платишь full-price. Если же ничего необычного тебе не надо, пользуйся, уважаемый, благами массового потребления за полукопеешную символическую плату.
·>В случае если у некоего клиента всегда уникальные файлы, то дедупликация будет невыгодна клиенту.
Чем? Лишний раз прочитать файл и посчитать хеши? Это копейки. А если дело происходит в смартфоне с флеш-памятью, то никто глазом моргнуть не успеет.
Кстати, наши с вами решения действительно похожи. Но только моё проще и прямолинейнее. Без лишних ключей, сущностей и телодвижений. ИМХО, конечно
Здравствуйте, Voblin, Вы писали:
V>>>Чисто из вредности? Что клиент выигрывает, когда отсылает неправильный хеш? V>·>У клиента мотив — экономия вычислительных ресурсов. Или банально ошибка (упрощение) имплементации, или параноя. Ддосеры, в конце-концов. V>Если облако платное, то можно завлечь клиента скидками. То есть если скидываешь уникальные файлы, то платишь 1 условный рубль/ГБ/год, а если по какому-то файлу обнаружился 1 аналог, то держи, дорогой, 30% скидку. И дальше по прогрессии, вплоть до скидки 90% при факторе 50. Помещая файлы в хранилище, можешь выбрать: V>1. Получать скидку, если кто-то тоже выложит такое же. V>2. Зашифровать наглухо и платить полную цену.
Так я это и имел в виду, что надо мотивировать клиента и про скидку
писал.
V>Хранишь в облаке подборку любимых mp3шек, фильмов и сериалов — тебе дёшево и удобно. V>Хранишь заведомо уникальное (видео с камеры наблюдения во дворе, например) — ну извини, ты один танцуешь эту девушку.
Даже один может танцевать девушку в разные места — "некая маленькая группа "я и все мои устройства"" как у топикстартера было.
V>Зато ты уверен (и в этом преимущество технологии), что никто левый из тех, кто этого видео не имел, его не позырит. Хочешь сохранить что-то глубоко личное и/или зашкварное — тоже не проблема, опция №2. Понятное дело, такое только за полную цену. Вот, кстати, и ответ на вопрос про товарища майора и поваренную книгу анархиста.
"Товарищ майор" это другой момент — идентификация клиентов — оно ортогонально вопросу дедупликации.
Кстати... интересно — иметь хеш поваренной книги анархиста — наказуемо?
V>Давать юзеру самому принять решение — это правильно. Слишком много непонятных опций — это зло, а простой и понятный выбор — то, что людям нужно.
Понятность в данном случае и есть мотивация — ответ на вопрос: "накой мне как клиенту нужна эта дедупликация и нафиг мне париться о выборе?"
V>Кстати, заодно получается прикольно оплачиваемый файлообмен между юзерами системы. Допустим, я срипал и выложил киношку. И опубликовал оба ключа — шифрующий
Что-то ты куда-то не туда понёсся. Если ты опубликовал шифрующий ключ, то шифрование тут же теряет смысл.
V>и идентифицирующий. Любой желающий может скачать файл, но для этого он должен хотя бы на время (можно установить минимальный срок хранения месяц) как-бы одним из владельцев этого файла. Чем больше владельцев, тем меньше платит каждый. Сервис тоже не обижен.
Торренты с таким юзкейсом лучше справляются и забесплатно.
V>·>В случае если у некоего клиента всегда уникальные файлы, то дедупликация будет невыгодна клиенту. V>Чем? Лишний раз прочитать файл и посчитать хеши? Это копейки. А если дело происходит в смартфоне с флеш-памятью, то никто глазом моргнуть не успеет.
Копейки, не копейки, а накладные расходы всё-таки, посчитать таки надо. Какое-нибудь blue-ray видео читать лишний раз — устанешь глазами моргать. А на сматрфоне за жизнь батарейки бороться надо.
V>Кстати, наши с вами решения действительно похожи. Но только моё проще и прямолинейнее. Без лишних ключей, сущностей и телодвижений. ИМХО, конечно
Моё — более общий случай. И я, конечно, не сварщик, но мне кажется, что генерировать рандомный ключ шифрования будет надёжнее, чем использовать для этого хеш.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Voblin, Вы писали:
V>В чём может быть мотив отсылать неправильные хеши? Чисто из вредности? Что клиент выигрывает, когда отсылает неправильный хеш?
Минимизировать утечку информации. Клиент не хочет, чтобы другие знали, какие файлы он хранит.
Дедупликация же выгодна только сервису, поскольку он платит за хранение.
Здравствуйте, wildwind, Вы писали:
W>Дедупликация же выгодна только сервису, поскольку он платит за хранение.
В конечном итоге всё равно за всё платит клиент. Бесплатного ничего не бывает. Бывает только, что клиент не знает, чем конкретно и сколько он платит за потребляемое благо. В данном случае модель, наверно, подходит для честно платного сервиса, который в случае возникновения факта дедупликации предоставляет клиенту вкусную скидку.
Здравствуйте, ·, Вы писали:
·>Моё — более общий случай. И я, конечно, не сварщик, но мне кажется, что генерировать рандомный ключ шифрования будет надёжнее, чем использовать для этого хеш.
Я всего лишь предложил вариант реализации. Все pros&contras пусть взвешивают те, кто будут принимать решения о запуске технологии в дело. Если дело дойдёт до дела.
Здравствуйте, Voblin, Вы писали:
V>В конечном итоге всё равно за всё платит клиент. Бесплатного ничего не бывает. Бывает только, что клиент не знает, чем конкретно и сколько он платит за потребляемое благо. В данном случае модель, наверно, подходит для честно платного сервиса, который в случае возникновения факта дедупликации предоставляет клиенту вкусную скидку.
Кому именно — первому, кто загрузил файл, или второму? А сотому? А тысячному, через год?
Клиент не может проверить "честность" (да и не хочет), поэтому не подходит.
Здравствуйте, wildwind, Вы писали:
V>>В конечном итоге всё равно за всё платит клиент. Бесплатного ничего не бывает. Бывает только, что клиент не знает, чем конкретно и сколько он платит за потребляемое благо. В данном случае модель, наверно, подходит для честно платного сервиса, который в случае возникновения факта дедупликации предоставляет клиенту вкусную скидку. W>Кому именно — первому, кто загрузил файл, или второму? А сотому? А тысячному, через год? W>Клиент не может проверить "честность" (да и не хочет), поэтому не подходит.
Тут уже конкуренция поможет — клиенты будут выбирать тот сервер, который даёт больше скидок.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, wildwind, Вы писали:
W>Кому именно — первому, кто загрузил файл, или второму? А сотому? А тысячному, через год?
Всем. Когда первый выкладывает, ему объявляется полная цена, но если он нагнал ещё 100 штук владельцев, то после этого обнаруживает, что хранение этого файла ему обходится, например, в 1/20 тарифа.
А тот, кто ведёт себя как скунсяра вонючий, платит за всё в одно рыло.
W>Клиент не может проверить "честность" (да и не хочет), поэтому не подходит.
Ну, во-первых, конкуренция, как сказано в комменте выше. Кроме того, юзер ведь тоже не лох. Показать ему, сколько у него пиров по каждой единице хранения. Без раскрытия имён, конечно. Из общих соображений юзер может понять, похоже это на правду, или нет.
С юридической точки зрения юзеру всё равно не к чему докопаться. Ему обещали хранить данные за тариф/ГБ/год, ну так и хранят. Вкусняшка с дедупликацией — это уже скидка. Льгота. Способ сэкономить. Хранить в облаке уникальное файло за полную цену привлекательно потому, что даже если получается и слегка дороже, чем у себя на винте, но выигрыш по надёжности и доступности. А хранить всякий хлам (сериалы и т.п.) — тут уже выигрыш по стоимости. Потому что скидка.
Здравствуйте, vsb, Вы писали:
vsb>Передаём серверу хеш файла. Он нам возвращает список клиентов, которые заливали этот файл.
...или файлы с таким же хэшем. Глобальный Perfect hash пока не изобрели, вроде ж?
Как будем проверять уникальность/идентичность своего файла, без отдачи на сторону?
Здравствуйте, Mr.Delphist, Вы писали:
vsb>>Передаём серверу хеш файла. Он нам возвращает список клиентов, которые заливали этот файл. MD>...или файлы с таким же хэшем. Глобальный Perfect hash пока не изобрели, вроде ж?
В практических целях какой-нибудь sha512 можно считать таковым.
MD>Как будем проверять уникальность/идентичность своего файла, без отдачи на сторону?
Но если сомневаешься, можно скачать то что хранится на сервере и сравнить со своим файлом побайтово. Перечитай топик, вроде там всё описано.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Я всего лишь предложил вариант реализации. Все pros&contras пусть взвешивают те, кто будут принимать решения о запуске технологии в дело. Если дело дойдёт до дела.
