криптование как ответ долбоёбам

[109]

я тут попытался придумать, как бы хотя бы firends-only записи сделать _на_самом_деле_ защищёнными (то есть чтобы _на_самом_деле_ только френды могли читать), но так ничего и не придумал. зато есть куча рассмотренных сценариев (как с симметричным криптованием, так и асимметричным), которые работать не будут (с объяснением, почему).

да, рассуждения я производил исходя из предположения, что джаваскрипт в браузере может читать ключи из секурного места и декриптовать там прямо у себя, показывая юзеру декодированный результат.

Comments

[109.livejournal.com]

хм... хранить много копий мне в голову не пришло.

а как с группами быть? юзер А - член моей группы Б, но не моей группы С. когда я пощу в Б, я хочу, чтобы юзер А имел доступ, а когда пощу в Б - нет.

всё-таки как-то должно быть можно и без множественных копий... например, симметричный ключ, которым зашифрован пост, в свою очередь, шифруется shared secret-ом, и кладётся на сервер вместе с указанием, какому френду этот ключ выдавать. таким образом, сервер прочитать не может, поскольку не знает shared key, и в то же время хранит только один экземпляр зашифрованного поста.

только придётся при изменении списка френдов группы перекриптовывать все посты этой группы, но это (имхо) более приемлемо, чем много копий хранить...

[fenikso.livejournal.com]

>а как с группами быть? юзер А - член моей группы Б, но не моей группы С.
>когда я пощу в Б, я хочу, чтобы юзер А имел доступ, а когда пощу в Б - нет.
per-group key. с revocation конечно заморочки пойдёт, плюс если ты хочешь постить в С неявно для юзера А, то вариант негуманно сработает - юзер А вынет шифрованный пост, обломается прочитать и загрустит в печаль (ЖЖ как я понимаю, просто не светит такие посты)

>например, симметричный ключ, которым зашифрован пост, в свою очередь, шифруется
>shared secret-ом, и кладётся на сервер вместе с указанием, какому френду этот
>ключ выдавать.
Нет, тут ты уже условия задачи сдвинул - если ты серверу указываешь кому давать, кому не давать - то тебе не нужен никакой второй ключ. Заведи себе один на всех людей ключ, неизвестный только серверу, шифруй им, а доступ регулируй сервером.

Давай откатим назад наверное: у тебя сервер "тупой вседоступный анонимный фтп" или "умный (различающий френдов) но возможно вражеский"? :) Хотя это не сработает - "вражеский" сервер можно научить различать не так как ты предполагаешь, строя модель раздачи прав доступа.

p.a. ничего что я на "ты"? (возможно, склероз)

[109.livejournal.com]

на "ты", конечно, о чём речь.

условия задачи, на самом деле, такие - как с наименьшим геморроем модифицировать жж, чтобы его администрация (включая потенциальных партнеров ака долбоёб) не могла прочесть подзамочные посты при всём желании.

то есть, сервер "дружественный" в том смысле, что он готов имплементировать предлагаемый протокол, чтобы иметь возможность сказать "мы не можем читать шифрованные посты при всём желании". например, чтобы привлечь privacy-challenged userbase.

но "недружественный" в том единственном смысле, что он не должен быть способен расшифровать шифрованные посты.

с одним ключом на всех я вообще не понял идею.

[fenikso.livejournal.com]

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

впрочем, и в этом варианте дыр куча. как и во всяком другом, имхо.

[109.livejournal.com]

не, это не годится. в протоколах с shared key для каждого френда мы не рассматриваем вариант, как именно мы обменялись shared key и установили его подлинность. это годится [только] потому, что протокол не подразумевает изменения этого ключа. в этом же твоём варианте (один ключ на всех), ключ надо менять каждый раз, когда удаляешь френда, поэтому игнорировать механизм дистрибуции ключа нельзя.

[fenikso.livejournal.com]

Смотри, у тебя все равно получается избыточность - не копиями сообщений, так копиями ключей. фактически при хорошей динамике изменений структуры группы, ты получаешь свой новый симметричный ключ на каждое сообщение, прокриптованный shared ключом для каждого френда. Причём формировать шифрованный шаредом симметричный ключ ты должен у себя, иначе сервер получит информацию об этом ключе.

[109.livejournal.com]

ну, избыточность - дело относительное. по сравнению с чем? есть ли более компактная имплементация, отвечающая условиям? по крайней мере, хранить копии ключей - более компактно, чем копии сообщений...

[fenikso.livejournal.com]

Тут уже руками смотреть надо :) Человеческие сообщения жмутся очень хорошо - ещё неизвестно кто меньше окажется (хранить то можно и зипованный вариант :) Но это уже гонка за битами. А так - что одно, что другое.

Хотя персонально мне нравится больше схема с копиями сообщения, зашифрованными открытыми ключами только тех людей, кому дозволено читать это сообщение :) Не доверяю я серверу.

[109.livejournal.com]

ну да, на постах короче 128 бит мой вариант начинает проигрывать :-Р

при чём тут доверие серверу? при шифровке симметричного ключа поста теми же самыми открытыми ключами френдов доверие к серверу ровно такое же.

[fenikso.livejournal.com]

>ну да, на постах короче 128 бит мой вариант начинает проигрывать :-Р
От длины ключа зависит :-P :)

>при чём тут доверие серверу? при шифровке симметричного ключа поста
>теми же самыми открытыми ключами френдов доверие к серверу ровно такое же.
да, я некорректно сказал: схема с шаред ключами мне не нравится из-за недоверия серверу, схема с открытыми ключами надежна вне зависимости от того, шифруем мы ею сообщение или симметричный ключ