Для каждого контакта на диске создается файл

Для каждого контакта на диске создается файл, содержащий:
-
их_последний_присланный_паблик_ключ
наш_последний сгенерированный_приват_ключ
мастер_ключ_для_зашифровки
мастер_ключ_для_расшифровки
старые_неиспользованные_ключи_расшифровки [16 ключей]
Первичный обмен DH-ключами в PGP-контейнерах:
1. Алиса для начала переписки заводит файл для Боба, генерирует ключевую
пару Xx и сохраняет в файле приватный ключ как наш_последний
сгенерированный_приват_ключ.
Затем Алиса отсылает Бобу свой запрос IDA , X, шифруя сообщение с
помощью PGP.
2. Боб, расшифровав PGP сообщение IDA , X, заводит файл для Алисы и
добавляет полученный от нее ключ (как
их_последний_присланный_паблик).
Затем Боб генерирует свою пару Yy, выводит общий секрет s=X^y и
подсчитевает хеш H=h(IDB | s).
Сгенерированный приватный ключ добавляется в файл (как
наш_последний_сгенерированный_приват).
Затем Боб отсылает Алисе свой ответ IDB , Y , H, шифруя сообщение с
помощью PGP.
3. Алиса получает ответ, расшифровывает PGP сообщение IDB, Y , H, и ищет
нужный файл на диске (имя файла не связано с ID !):
по очереди открывает каждый (по адресной книге),
подсчитывает s=Y^наш_последний_сгенрированный_приват, а затем
H'=h(IDB | s). Таким образом, по совпадению H находит отправителя и
убеждается в его идентичности.
Затем Алиса генерирует новую пару Xx и подсчитывает
мастер_ключ_для_зашифровки:
w=h (Y^приват_из_файла | Y^только_что_сгенерированный приват),
после чего затирает старый приват-ключ в файле, заменяя его новым.
Теперь Алиса должна первой отослать информационное сообщение Бобу.
Зашифровка:
Отправитель открывает файл абонента, которому отсылается сообщение.
Из мастер_ключа_для_зашифровки выводится зашифровочный ключ:
k=h(w | w), мастер-ключ включается под хеш дважды. Этим ключом
шифруется, затем атентифицируется текст сообщения.
Тот час мастер_ключ_для_зашифровки заменяется в файле своим хешем:
w=h(w).
Кроме того, из наш_последний_сгенерированный_приват, хранящегося в
файле, выводится соответствующий публичный ключ X и включается в
отправляемое сообщение.
Таким образом, сообщение содержит: шифротекст, МАС и вводимый
публичный ключ: C, M, X
Детали:
1. Шифрование выполняется с помощью Keccak в потоковом режиме:
абсорбируется ключ k, затем выжимается необходимое количество
гаммы, соответсвующее длине текста. Шифротекст получается с
помощью операции “исключающее или” гаммы и исходного текста.
2. Аутентификация выполняется отдельным проходом с помощью Keccak:
абсорбируется ключ k (тот же, который использовался для шифрования),
затем абсорбируется шифротекст и выжимается MAC.
3. После использования рабочий ключ k тот час удаляется. Один и тот же
рабочий ключ никогда не используется повторно для разных сообщений.
4. После использования и удаления рабочего ключа мастер-ключ w, из
которого был выведен рабочий ключ, также безвозвратно заменяется
собственным хешем. Таким образом, нет никакой возможности позже
вывести рабочий ключ k повторно.
5. При отправке нескольких сообщений подряд публичный ключ,
включаемый в отправляемые сообщения, будет одинаков (т.к.
соответствующий приватный ключ не меняется).
6. При получении валидного (по МАС) сообщения, содержащенго новый
публичный ключ, также будет сгенерирован и наш новый приватный
ключ. Новые их публичный и наш приватный ключи будут записаны в
файл контакта, старые – безвозвратно удалены.
7. Расшифровка:
Получатель пытается определить отправителя сообщения. Для этого он по
очереди открывает имеющиеся файлы контактов и сверяет MAC, для
каждого файла пробуя различные ключи k:
Процедура 1: проверка ключа k.
MAC ?= h(k | шифротекст). Если MAC совпадает, то сообщение
расшифровывается, использованный ключ удаляется и обновленный файл
сохраняется на диске, работа алгоритма завершается.
Сначала проверяются 16 старых неиспользованных ключей. Если
безуспешно, то пытаемся получить подходящий ключ из имеющегомся
мастер_ключа_расшифровки:
Процедура 2:: работа с мастер_ключом_расшифровки:
- из мастер_ключа выводм рабочий ключ k=h(r | r) и дописываем его к
старым ключам, затем тот час заменяем мастер_ключ свом хешем: r=h(r).
-пробуем выведенный ключ k, выполняя Процедуру 1.
- если безуспешно, то выводим еще ключ, и так 4 раза
Если не удалось получить подходящий расшифровочный ключ из имеющегося
мастер-ключа, проверям: возможно, нам прислан новый публичный ключ и его
надо обработать:
-
убеждаемся, что присланный_в_сообщении_публичный_ключ
отличается от имеющегося в файле последнего_полученного
_их_публичного_ключа.
- выводим новый мастер_ключ_расшифровки:
r = h( имеющийся_их_публичный ключ ^ имеющийся_наш_приватный_ключ ||
новый_их_публичный_ключ ^ имеющийся_наш_приватный_ключ)
- генерируем новую пару X x
- выводим новый мастер_ключ_зашифровки:
w=h(новый_их_публичный_ключ ^ имеющийся_наш_приватный_ключ ||
новый_их_публичный_ключ ^ новый_наш_приватный_ключ)
-
сохраняем полученный новый публичный ключ и сгенерированный новый
приватный ключ в файле, затирая старые (помните, что обновленный файл
записывается на диск только в случае успеха МАС в Процедуре 1, иначе все
внесенные в файл изменения не сохраняются!)
-
пытаемся получить подходящий ключ из имеющегомся
мастер_ключа_расшифровки, выполняя Процедуру 2.
Детали:
1. Мастер-ключ r служит для выведения рабочих ключей расшифровки и
после выведения очередного рабочего ключа k тот час заменяются своим
хешем. Удачно использованный рабочий ключ тот час удаляется. Т.о. нет
возможности вывести и использовать рабочий ключ k повторно.
2. Для выведения симметричных мастер-ключей r и w используется уже
имеющийся приватный ключ, который после этого тот час заменяется
сгенерированным новым. Это происходит при расшифровке валидного
по МАС сообщения, содержащего новый публичный ключ. Т.о. позже
невозможно повторно вывести корневые мастер-ключи.
3. Неиспользованные рабочие ключи получаются при пропуске сообщений
и хранятся в файле контакта. Позже при получении опоздавших
сообщений эти ключи могут быть использованы для их расшифровки
(т.о. поддерживается ключевое окно регулируемого размера в
зависимости от количества хранимых ключей: компромисс между
надежностью и безопасностью).
4. Неиспользованные рабочие ключи сохраняются вместе с таймстемпом.
Слишком старые ключи периодически удаляются, уменьшая тем самым
окно компромата.
Основные отличия от протокола Axolotl:
1. Axolotl спроектирован для чата и использует собственные долговременные
DH-ключи для первичной отрицаемой+PFS аутентификации по протоколу
TripleDH (модифицированнный KEA+). Предлагаемый протокол с той же
целью использует протокол Abadi+DH на базе PGP, что естественно для
электронной почты.
2. В протоколе Axolotl доверие к вновь вводимому ключу от сообщения к
сообщению передается через часть хеша предыдущего общего секрета,
хранимую на диске и подмешиваемую к новому DH-секрету. В
предлагаемом протоколе мастер-ключи выводятся из двух DH-секретов,
полученных с участием как имеющихся, так и вновь сгенерированных
/вновь полученных DH-ключей, что по сути то же, но облегчает восприятие
логики протокола и его анализ.