?

Log in

No account? Create an account
Previous Entry Share Next Entry
2016-01

Думал тут про convergent encryption снова

Банальная схема: хешируем плейнтекст, получаем hash1 -> используем его как ключ, шифруем этим ключом, хешируем зашифрованное, получаем хеш2, стореджу даем хеш2 чтобы он нам отдал контент, а у себя храним и хеш1 и хеш2.

Но ссылок на контент обычно много, и хранить 2 хеша напрягает (контент мелкий, 1-100kb). И вот думаю, может сделать id контента не хеш от шифртекста, а хеш (keyed, pbkdf, не важно) от ключа? что мы от этого теряем? вроде ж ничего? а ссылки тогда занимают вдвое меньше...

This entry was originally posted at https://wizzard.dreamwidth.org/488548.html. It has comment count unavailable comments. Please comment there using OpenID.

  • 1
mbr February 9th, 17:24
емнип, TLS так ключи и генерит для очередного фрейма. Но там какая-то наркоманская соль добавляется в каждом раунде.

blackyblack February 9th, 18:00
Каких-то серьёзных угроз не вижу. Разве что ключ короткий относительно шифротекста. Как бы на коллизию не напороться. Ещё, сторадж должен поддерживать индивидуальные ID для контента. И у стораджа будут как раз храниться и ID и хэши контента, то есть нагрузка на него переносится.

wizzard0 February 10th, 21:07
По идее, от N хешей logN битов коллизий, и теряется logN/2 effective битов ключа. То есть для двух хешей - полбита, не смертельно.

Hash1

bik_top February 9th, 19:39
> Банальная схема: хешируем плейнтекст, получаем hash1 -> используем его как ключ, шифруем этим ключом

А почему в качестве ключа шифрования используется не случайно сгенерированный, а порождённый из хэша плейнтекста?

Re: Hash1

cat_mucius February 10th, 13:33
Да, вот то же хотел спросить.
К тому же, почему бы не производить хэш-2 не от всего шифротекста, а от хэша-1, возможно, с добавлением какой-нибудь и так хранящейся меты, типа имени или даты файла? Тогда достаточно хранить хэш-1.

Re: Hash1

wizzard0 February 10th, 21:08
Вся остальная мета шифрованная. Да, во второй схеме достаточно хранить хэш1, в этом и соль.

Хеш плейнтекста используется чтобы одинаковые плейнтексты давали одинаковый ключ (дедупликация)

redreptiloid February 9th, 22:26
если солить то надо хранить соль и выйгрыш уже не в 2 раза. а если не солить, по идее ключ достаточно рандомный и так, то хз, но интуитивно мне это не нравится, получаем наличие шифртекст+хэш1+хеш от хеш1 и стойкость по идее должна упасть, вопрос насколько

wizzard0 February 10th, 21:09
Не, "интуитивно" тут не катит :) Сторадж не видит хэш1

redreptiloid February 11th, 1:23
ну вот это мне и не нравится, в первом случае он хэш1 не видит вообще, во втором он видит хэш от хэш1, если он без соли. а он без соли, потому чт дедупликация. по идее это как то должно влиять на стойкость... в первом случае у нас возможна атака только на шифртекст, во втором на шифртекст+хэш от ключа.

Edited at 2018-02-11 01:25 am (UTC)

wizzard0 February 11th, 10:09
ну вот по моим прикидкам должно теряться от 0.5 до 1 бит ключа, что в целом терпимо

blackyblack February 11th, 17:47
Можно и с солью сделать. Дедупликация всё равно на сторадже делается на базе контента, а идентификаторы можно привязывать отдельно. Получится шифротекст + хэш для дедупликации + набор пользовательских идентификаторов для поиска.

wizzard0 February 12th, 19:22
а соль на всех общая?

blackyblack February 12th, 19:45
Да не, разная наверное. От неё просто толку нет, так как её хранить вместе с хэшами придётся.

  • 1