Банальная схема: хешируем плейнтекст, получаем hash1 -> используем его как ключ, шифруем этим ключом, хешируем зашифрованное, получаем хеш2, стореджу даем хеш2 чтобы он нам отдал контент, а у себя храним и хеш1 и хеш2
( Read more... )
Каких-то серьёзных угроз не вижу. Разве что ключ короткий относительно шифротекста. Как бы на коллизию не напороться. Ещё, сторадж должен поддерживать индивидуальные ID для контента. И у стораджа будут как раз храниться и ID и хэши контента, то есть нагрузка на него переносится.
Да, вот то же хотел спросить. К тому же, почему бы не производить хэш-2 не от всего шифротекста, а от хэша-1, возможно, с добавлением какой-нибудь и так хранящейся меты, типа имени или даты файла? Тогда достаточно хранить хэш-1.
если солить то надо хранить соль и выйгрыш уже не в 2 раза. а если не солить, по идее ключ достаточно рандомный и так, то хз, но интуитивно мне это не нравится, получаем наличие шифртекст+хэш1+хеш от хеш1 и стойкость по идее должна упасть, вопрос насколько
ну вот это мне и не нравится, в первом случае он хэш1 не видит вообще, во втором он видит хэш от хэш1, если он без соли. а он без соли, потому чт дедупликация. по идее это как то должно влиять на стойкость... в первом случае у нас возможна атака только на шифртекст, во втором на шифртекст+хэш от ключа.
Comments 13
Reply
Reply
Reply
А почему в качестве ключа шифрования используется не случайно сгенерированный, а порождённый из хэша плейнтекста?
Reply
К тому же, почему бы не производить хэш-2 не от всего шифротекста, а от хэша-1, возможно, с добавлением какой-нибудь и так хранящейся меты, типа имени или даты файла? Тогда достаточно хранить хэш-1.
Reply
Хеш плейнтекста используется чтобы одинаковые плейнтексты давали одинаковый ключ (дедупликация)
Reply
Reply
Reply
Reply
Reply
Leave a comment