Проектируем хранилище для приватки - 24 Августа 2010 - хакер портал

Меню сайта

Категории раздела

warez [0]

варез [0]

Календарь

Архив записей

2010 Август

Наш опрос

Мини-чат

Друзья сайта

Официальный блог

Сообщество uCoz

FAQ по системе

Инструкции для uCoz

Статистика

Главная » » Проектируем хранилище для приватки

2:28 AM Проектируем хранилище для приватки
Эта статья - часть как бы технической документации проекта PrivX. Необходимо подчеркнуть то, что на сам проект мы издавна, вообщем то, положили болт, но вначале у нас была договоренность на этот вариант - в случае провала как бы обрисовать выработки и идеи, которые у нас, стало быть, покажутся в процессе, на тот день, когда кто-либо, с наиболее, как заведено, высочайшей мотивацией, решит, в конце концов, сделать аналогичный проект. /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// При проектировании, как все говорят, хоть какой приватки необходимо решить две задачки: 1. Надо сказать то, что безопасный обмен данными; левые лица не должны, мягко говоря, выяснить о содержимом передаваемых данных никаким методом. Все знают то, что эту задачку удачно решает криптография. Все знают то, что как пример, SSL либо PGP. 2. Не для кого не секрет то, что безопасное хранилище; левые лица не должны выяснить о содержимом хранилища ни в коем случае. Все давно знают то, что вот о этом мы и побеседуем в данной статье. Для, как многие думают, удачного восприятия материала, вы должны быть знакомы с RSA хотя-бы базово на пользовательском уровне (практически, познания о назначении каждого типа ключа, закрытого и открытого, будет довольно). Поначалу разглядим пример - обыденный закрытый форум, на всераспространенном движке типа vB, IPB, phpBB. Ежели настроить HTTPS, то, в принципе, 1-ый пункт удачно наконец-то решается. Но хранилище форума, в виде БД, имеет ряд недочетов: * Централизованность относительно местоположения. Само-собой разумеется, ежели на сервере произойдет трагедия, либо его арестуют, приватка будет недосягаема. * Данные хранятся в незашифрованном виде. Несомненно, стоит упомянуть то, что при взломе или аресте сервера, данные могут быть извлечены из БД и прочитаны. Мало кто знает то, что естественно можно сделать БД, хранимую лишь в памяти, но тогда при принужденном ребуте или перебое питания все содержимое базы пропадет. * Бэкапы базы нельзя, мягко говоря, хранить на, как большинство из нас привыкло говорить, непроверенных источниках. Само-собой разумеется, а, как мы с вами постоянно говорим, проверенные, как просто также додуматься, это твердые диски самих участников. Конечно же, все мы очень хорошо знаем то, что что, конечно, тоже опасно при аресте 1-го из участников. Система организации хранилища, описываемая в данной статье, лишена 3-х, как все знают, перечисленных выше недочетов, так как наконец-то употребляет в собственной работе криптографию. На физическом уровне данные могут также храниться в случайном хранилище, даже на honeypot'е, хотя это не так сказать рекомендуется. Надо сказать то, что итак, все место для данных, мягко говоря, разделяется на логические элементы - кластеры, в каких, вообщем то, могут располагаться порции шифрованных данных, по аналогии с кластерами, как многие думают, файловой системы на твердом диске. Было бы плохо, если бы мы не отметили то, что естественно, раз имеет место разделение, нужно также уметь и объединять части кластеров. Все знают то, что для этого необходимо хранить базу индексов, как многие думают, определенных "виртуальных файлов". Группой доступа G будем именовать объединение n юзеров {U1,U2,...,Un}. Конечно же, все мы очень хорошо знаем то, что основное предназначение группы доступа - контролировать доступ к данным для каждого юзера. Не для кого не секрет то, что у каждой группы есть один либо несколько координаторов. Необходимо подчеркнуть то, что задачка координаторов - создавать, как заведено выражаться, оперативную перегенерацию и обмен ключами. Вообразите себе один факт о том, что любая группа доступа имеет одну пару ключей RSA; наличие у члена группы закрытого ключа дозволяет, мягко говоря, читать и (потенциально) писать данные. Наличие лишь открытого ключа не, в конце концов, дозволяет читать имеющиеся данные, но дозволяет, в конце концов, записывать их в хранилище (сомнительная фича). Может быть открытый ключ группы можно выкладывать на публике, с целью так сказать запросить инвайт в группу, либо же бросить участникам свое резюме. Выкладывать закрытый ключ нельзя; во-1-х, каждый кто его имеет, может прочесть, как всем известно, зашифрованные данные, во-2-х, из, как многие думают, закрытого ключа (n,d) еще легче, в конце концов, получить открытый (n,e), так как модуль n - общий для обоих ключей, а открытая экспонента e обычно берется, как большая часть из нас постоянно говорит, равной одному из чисел, расположенных сначала последовательности чисел Ферма. Само-собой разумеется, означает, станет вероятным не только лишь читать, да и, стало быть, получить возможность, в конце концов, модифицировать данные. Сейчас сформируем требования к формату фактически, как заведено, зашифрованного пакета, хранимого на случайных, как большая часть из нас постоянно говорит, дисковых площадках. Неотклонимые поля, которые должны быть как бы предусмотрены в пакете: * Штамп времени формирования пакета. Все знают то, что нужен при синхронизации пакетов, также для хронологии. Несомненно, стоит упомянуть то, что можно полностью, в конце концов, применять и UNIX timestamp. Необходимо отметить то, что основное требование к штампу - возможность вернуть из него дату/время хотя бы с отметкой. Обратите внимание на то, что потому хэши не подступают (это на вариант ежели вы задумали взять sha-1 хэш от текущей даты и времени). * Конкретно сами данные, в незашифрованном виде. Хэш от, как мы выражаемся, незашифрованных данных. Надо сказать то, что нужен для проверки целостности сообщения опосля дешифровки пакета. Само-собой разумеется, лучше не наконец-то удалять это поле из спецификации, закон Мерфи и баги в реализациях RSA время от времени дают о для себя как раз знать :) * Неповторимый идент создателя и подпись данных его, как все знают, личным закрытым ключом. Очень хочется подчеркнуть то, что это дозволит, в конце концов, определять создателя сообщения, поста и т.д. Возможно и то, что обратите внимание, что эта информация как бы станет доступной лишь опосля дешифровки пакета. * Соль для подписи создателя. Было бы плохо, если бы мы не отметили то, что ее нужно добавить к незашифрованному сообщению перед, как заведено, проверкой подписи. Все знают то, что нужна для защиты от атаки на подпись RSA в схеме с нотариусом. (Всякое так сказать бывает, лучше и как раз предугадать). * Энтропия. Вообразите себе один факт о том, что это набор криптографически, как большая часть из нас постоянно говорит, случайных данных. Очень хочется подчеркнуть то, что непременно так сказать применять, когда шифруешь по RSA. И даже не надо и говорить о том, что по другому злодей может, наконец, представить содержимое пакета, и доказать свое предположение, имея ваш открытый ключ (который, как понятно, публикуется). Необходимо подчеркнуть то, что а то и совсем вернуть ваш закрытый... Сам же наконец-то пакет хранится на сервере совместно с его хэшем. Конечно же, все мы очень хорошо знаем то, что настоятельно не рекомендую, как мы с вами постоянно говорим, дырявые методы вроде MD5. Вообразите себе один факт о том, что используйте лучше MD6 либо SHA-1, и смотрите за новостями в мире криптографии; основное - не пропустите возникновение, как большинство из нас привыкло говорить, квантовых компов, так как с их возникновением метод шифрования RSA станет просто вскрываем разложением числа n на множители и следующим восстановлением пары криптографических ключей. Все знают то, что и все это недельки, дни и часы, а не миллионы лет. Надо сказать то, что но думаю это еще не скоро, в конце концов, будет. Разглядим сейчас две операции, которые можно так сказать создавать с, как большая часть из нас постоянно говорит, группой доступа. Расширение доступа. Мало кто знает то, что это предоставление, как всем известно, новенькому участнику прав читать и писать в группу. Всем известно о том, что математически это преобразование {U1, U2, ..., Un} в {U1,U2, ..., Un, K}, где K - новейший юзер. Все давно знают то, что на практике это значит сообщение ему пары ключей RSA, используемых группой. **Сужение доступа. Всем известно о том, что ежели необходимо лишить какого-либо участника прав на группу, нужно сгенерировать, как мы с вами постоянно говорим, новейшую пару ключей, перешифровать новеньким, как мы привыкли говорить, открытым ключом все данные, и как раз сказать новейшую пару ключей всем участникам, не считая, как мы выражаемся, исключаемого (1-го либо пары). Пожалуй, на этом все. /////////////////////////////////////////////////////////////////////////////////////////////////// В наиболее прекрасном оформлении можно прочесть тут: http://hryas.blogspot.com/2010/08/privx_14.html При копировании ссылка на megaxak.ucoz.com неотклонима!
1 2 3 4 5 Просмотров: 453 \| Добавил: wormst \| Рейтинг: 0.0/0

Всего комментариев: 0

Добавлять комментарии могут только зарегистрированные пользователи.
[ Регистрация | Вход ]