Здравствуйте, 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>В чём может быть мотив отсылать неправильные хеши? Чисто из вредности? Что клиент выигрывает, когда отсылает неправильный хеш?
Минимизировать утечку информации. Клиент не хочет, чтобы другие знали, какие файлы он хранит.
Дедупликация же выгодна только сервису, поскольку он платит за хранение.
