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

[109]

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

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

Comments

[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 :)

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