Здравствуйте, 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 — равное по объёму файлу.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
