криптование как ответ долбоёбам
Oct. 23rd, 2006 03:35 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
109я тут попытался придумать, как бы хотя бы firends-only записи сделать _на_самом_деле_ защищёнными (то есть чтобы _на_самом_деле_ только френды могли читать), но так ничего и не придумал. зато есть куча рассмотренных сценариев (как с симметричным криптованием, так и асимметричным), которые работать не будут (с объяснением, почему).
да, рассуждения я производил исходя из предположения, что джаваскрипт в браузере может читать ключи из секурного места и декриптовать там прямо у себя, показывая юзеру декодированный результат.
да, рассуждения я производил исходя из предположения, что джаваскрипт в браузере может читать ключи из секурного места и декриптовать там прямо у себя, показывая юзеру декодированный результат.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
Date: 2006-10-23 11:02 pm (UTC)(no subject)
Date: 2006-10-23 11:07 pm (UTC)(no subject)
Date: 2006-10-24 12:09 am (UTC)(no subject)
Date: 2006-10-24 12:47 am (UTC)а как с группами быть? юзер А - член моей группы Б, но не моей группы С. когда я пощу в Б, я хочу, чтобы юзер А имел доступ, а когда пощу в Б - нет.
всё-таки как-то должно быть можно и без множественных копий... например, симметричный ключ, которым зашифрован пост, в свою очередь, шифруется shared secret-ом, и кладётся на сервер вместе с указанием, какому френду этот ключ выдавать. таким образом, сервер прочитать не может, поскольку не знает shared key, и в то же время хранит только один экземпляр зашифрованного поста.
только придётся при изменении списка френдов группы перекриптовывать все посты этой группы, но это (имхо) более приемлемо, чем много копий хранить...
(no subject)
Date: 2006-10-24 01:02 am (UTC)>когда я пощу в Б, я хочу, чтобы юзер А имел доступ, а когда пощу в Б - нет.
per-group key. с revocation конечно заморочки пойдёт, плюс если ты хочешь постить в С неявно для юзера А, то вариант негуманно сработает - юзер А вынет шифрованный пост, обломается прочитать и загрустит в печаль (ЖЖ как я понимаю, просто не светит такие посты)
>например, симметричный ключ, которым зашифрован пост, в свою очередь, шифруется
>shared secret-ом, и кладётся на сервер вместе с указанием, какому френду этот
>ключ выдавать.
Нет, тут ты уже условия задачи сдвинул - если ты серверу указываешь кому давать, кому не давать - то тебе не нужен никакой второй ключ. Заведи себе один на всех людей ключ, неизвестный только серверу, шифруй им, а доступ регулируй сервером.
Давай откатим назад наверное: у тебя сервер "тупой вседоступный анонимный фтп" или "умный (различающий френдов) но возможно вражеский"? :) Хотя это не сработает - "вражеский" сервер можно научить различать не так как ты предполагаешь, строя модель раздачи прав доступа.
p.a. ничего что я на "ты"? (возможно, склероз)
(no subject)
Date: 2006-10-24 01:19 am (UTC)условия задачи, на самом деле, такие - как с наименьшим геморроем модифицировать жж, чтобы его администрация (включая потенциальных партнеров ака долбоёб) не могла прочесть подзамочные посты при всём желании.
то есть, сервер "дружественный" в том смысле, что он готов имплементировать предлагаемый протокол, чтобы иметь возможность сказать "мы не можем читать шифрованные посты при всём желании". например, чтобы привлечь privacy-challenged userbase.
но "недружественный" в том единственном смысле, что он не должен быть способен расшифровать шифрованные посты.
с одним ключом на всех я вообще не понял идею.
(no subject)
Date: 2006-10-24 01:29 am (UTC)это один из вариантов - выдавай ключ для чтения своих постов всем один и тот же, а выдачу самих постов регулируй сервером. друзьям давать - недрузьям не давать. тогда даже при наличии ключа, будет просто нечего декодировать тем кому ты не хочешь давать читать свои записи.
впрочем, и в этом варианте дыр куча. как и во всяком другом, имхо.
(no subject)
Date: 2006-10-24 01:40 am (UTC)(no subject)
Date: 2006-10-24 01:46 am (UTC)(no subject)
Date: 2006-10-24 01:52 am (UTC)(no subject)
Date: 2006-10-24 02:01 am (UTC)Хотя персонально мне нравится больше схема с копиями сообщения, зашифрованными открытыми ключами только тех людей, кому дозволено читать это сообщение :) Не доверяю я серверу.
(no subject)
Date: 2006-10-24 06:39 am (UTC)при чём тут доверие серверу? при шифровке симметричного ключа поста теми же самыми открытыми ключами френдов доверие к серверу ровно такое же.
(no subject)
Date: 2006-10-24 10:26 am (UTC)От длины ключа зависит :-P :)
>при чём тут доверие серверу? при шифровке симметричного ключа поста
>теми же самыми открытыми ключами френдов доверие к серверу ровно такое же.
да, я некорректно сказал: схема с шаред ключами мне не нравится из-за недоверия серверу, схема с открытыми ключами надежна вне зависимости от того, шифруем мы ею сообщение или симметричный ключ
Browser-specific crap
Date: 2006-10-24 12:22 am (UTC)(no subject)
Date: 2006-10-24 12:29 am (UTC)ни про фокс, ни про monkey я ничего не знаю, но предполагаю, что оно всё на джаваскрипте построено anyway?
собственно, пусть не джава скрипт... я бы даже согласился на BHO... проблема не в этом, а в том, как ключи раскидать, чтобы декриптовать мог только тот, кому положено, и как обрабатывать ситуацию "исключил из френдов".
(no subject)
Date: 2006-10-24 01:07 am (UTC)кстати, действительно, можно групповому ключу придать атрибут "ревизия" и при каждом изменении состава группы, перешифровывать записи и propagate ключ всем текущим юзерам группы (а тут уже надо напрямую как-то раздавать)
в итоге мы приходим к внешней системе (хотя бы раздачи ключей)
(no subject)
Date: 2006-10-24 01:27 am (UTC)а мой протокол вроде должен работать. ещё бы придумать протокол обмена shared key для новых френдов, и можно запускать IPO :-)
(no subject)
Date: 2006-10-24 01:41 am (UTC)Кстати, перекодировать старое сообщение (пост) другим ключом (новым) это leak, потому что "вынесенный из френдов" человек получает ненулевую возможность попытаться вскрыть ключ - если он знает уже дешифрованное сообщение.
Не думаю, что без "множественных копий" обойдётся.
(no subject)
Date: 2006-10-24 01:59 am (UTC)(no subject)
Date: 2006-10-24 01:37 am (UTC)(no subject)
Date: 2006-10-24 06:43 am (UTC)(no subject)
Date: 2006-10-24 03:00 am (UTC)(no subject)
Date: 2006-10-24 12:22 pm (UTC)С другой стороны фигня всё это, кому мы нужны кроме нас самих пока бабла не платим ;-)
не получится
Date: 2006-10-24 03:20 pm (UTC)А если серьезно, то можно было бы у поставщиков криптосистем денег поднять на такой мегатест.
(no subject)
Date: 2006-10-24 06:49 pm (UTC)давай реквизиты ваши мне на почту
Date: 2006-10-25 07:32 am (UTC)(no subject)
Date: 2006-10-25 07:38 am (UTC)так тебе и карты в руки :)
Date: 2006-10-25 08:17 am (UTC)