Перейти к содержанию

BlackDog

Пользователь
  • Публикаций

    31
  • Зарегистрирован

  • Посещение

Репутация

91 Excellent

Информация о BlackDog

  • Звание
    Rank №2
  1. SantaSOCKS

    Новый апдейт: Использование софта стало ещё более приятным. Интегрирован механизм удаление соксов из полученного листа при необходимости или по факту копирование соксов в буффер обмена (что бы не использовать заюзанные соксы повторно)
  2. SantaSOCKS

    В связи с техническими проблемами выпуск апдейтов временно приостановлен. Старая версия на текущий момент работает не стабильно, а новая не закончена в полном объеме. По факту решения технических проблем и завершения разработки апдейта всем владельцам лицензий любого типа будет продлен срок лицензионного использования.
  3. SantaSOCKS

    Напомню сообществу о данном программном обеспечение. Нужна пачка носков на 5 минут, но нет желания много платить или собирать носки руками? Значит SantaSOCKS должен стать вашим выбором.
  4. SantaSOCKS

    Новый апдейт: Добавлены новые источники соксов Внесены небольшие косметические изменения
  5. SantaSOCKS

    Качество соксов для Вас не сильно критично? Цены на соксы слишком высоки? Собирать руками паблик соксы надоедает? Нет знаний разработать собственный парсер паблик соксов? А соксы нужны здесь и сейчас? Тогда SantaSOCKS создан именно для Вас! SantaSOCKS - это бюджетное решение по добыче соксов для Ваших нужд в режиме реального времени из разных источников. Гибкая система настроек позволяет отсеивать соксы не подходящие по вашим критериям. Страны, тип сокса, уровень анонимности, задержка ответа - эти критерии Вы можете выбрать и SantaSOCKS выдаст вам именно тот результат, который Вам нужен. А главное преимущество SantaSOCKS по сравнению с другими подобными продуктами в том, что продукт будет развиваться. Будет добавляться новый функционал, интегрироваться новые источники добычи соксов. Зачем собирать паблик соксы руками? SantaSOCKS всё сделает за Вас. Зачем платить от 50$ за личный парсер если со временем он потребует обновления и придется платить снова? С SantaSOCKS Вам просто потребуется скачать апдейт ПО. Зачем платить по 10$ в день? Купите лицензию SantaSOCKS на месяц или сразу на целый год. Уже желаете купить Santa SOCKS? Тогда пишите в жабу blackdog_temp@exploit.im Цены: бесплатный тестовый период - 0$ (Для мемберов форума. Предоставляется по решению саппорта) лицензия 1 месяц - 4$ лицензия 1 год - 40$ Контакты: JID: blackdog_temp@exploit.im
  6. фоновый поиск

    Write English please. Don't worry. We understand your language.
  7. Комплекты фото девушек

    Вопрос прост. Данный вид товара ещё востребован на просторах даркнета? И какие актуальные цены?
  8. Делфи AccessViolation

    Вопрос глуповат, но все-же. Инициализация критической секции где-то производится?
  9. Ну если обход блокировок через соксы будет нужен, то фраза "Ищу чистые носки что бы выйти на улицу" принимает новый смысл :D
  10. Onion Messanger

    Сложно, не спорю. До релиза ещё далеко. Как всегда сказывается нехватка финансирования. А вот на счет масштабирования по вертикали не соглашусь. Она есть. Может заметна не так явно, так как сейчас вся информация в куче которую ещё предстоит разгрести. На примере: сообщение-->подпись сообщения-->шифрование сообщения открытым ключом получателя-->формирование технических данных для нод-->формирование луковичного пакета. Каждая часть процесса отправки сообщения в сеть сама по себе проста.
  11. Onion Messanger

    Дополнение 14 к спецификации Onion Messanger: Делегирование обязанности хранения и обработки ANL листов DUNS нодам В одном из предыдущих дополнений мы ввели DANS ноды задачей которых является хранение информации о TSN нодах пользователей. Внутрисетевой аналог DNS. Но, хорошо поразмыслив, было решено, что на DANS ноды можно делегировать и некоторые другие обязанности. Почему я пришел к такому мнению? DANS нод будет не много. 20-30 DANS нод будет достаточно для полноценной работы сети. Небольшое количество DANS нод обеспечит возможность быстрой синхронизации и незначительный объем трафика (объем которого будет расти в геометрической прогрессии с добавлением каждой ноды). Также задачи DANS нод не требуют больших вычислительных мощностей. Их задача - найти информацию в базе данных и отправить её запросившему пользователю. Поэтому время выполнения запросов DANS нодами будет минимально. Теперь следует подумать, а какие задачи можно ещё делегировать DANS нодам? Мне кажется, что хранение и синхронизация ANL листов - одна из таких задач. Когда в сети есть 1000 нод и синхронизация ANL листов происходит между ними, новой ноде в сети нужно познакомиться с каждой и скачать её ANL лист. Когда задача хранения ANL листов будет передана DANS нодам и их будет всего 20-30, то новой ноде нужно познакомиться только с ними. Как видите, объем трафика и нагрузка на сеть очень сильно уменьшается. И это позволит сети работать более надежно и стабильно. Также данное изменение даст возможность клиентам скачивать ANL листы со всех DANS нод, что тем самым не позволит какой-либо DANS ноде захватить сеть путем подмены ANL листа на свой в котором будут присутствовать только ноды подконтрольные владельцу данной DANS ноды. Размер зашифрованных данных Маленькая оплошность которую я допустил. Размер блока данных отправляемых на шифровку симметричным алгоритмом AES256 будет отличаться от размера блока данных после шифрования. Из этого следует, что блоки данных зашифрованных данным алгоритмом не будут иметь фиксированный размер. В связи с этим для всех зашифрованных симметричным алгоритмом блоков будет должна указываться длина блока, что бы его можно было считать. Новый вид луковичного пакета данных смотрите в дополнение 14 пункте "Новый вид пакета луковичной маршрутизации". Сопоставление идентификатора запроса с симметричным ключом клиента В ранних дополнениях было несколько изменений связанных с ключом клиента которым он сможет дешифровать ответ от исполняющей ноды и которым исполняющая нода может дешифровать данные запроса. Если для исполняющей ноды ключ клиента указан явно в технической информации для этой ноды, то каким ключом зашифрован ответ нигде не указывается и клиенту приходится гадать. Дешифровывать пакет всеми возможными ключами и сравнивать контрольные хэши слишком долго и ресурсозатратно. Поэтому от этого метода я отказался в первую очередь. Следующим вариантом было указание в хэадере запроса MD5 хэша от AES.c ключа. Сравнивать хэши ключей и находить подходящий более надежно, менее ресурсозатратно и по занимает меньше времени. Я уже хотел остановиться на этом варианте, как мне в голову пришла мысль. Зачем усложнять и так сложную систему? В дополнение 13 мы ввели идентификатор запроса QID. С его помощью клиент может распознать на какой запрос был предоставлен ответ из сети. А значит можно и определить каким AES.c ключом следует дешифровывать ответ. Сопоставление ключа клиента AES.c с идентификатором запроса QID позволит лучше оптимизировать мессенджер, а также позволит генерировать для каждого запроса отдельный AES.c ключ, что даст дополнительную надежность. Новый вид луковичного пакета данных смотрите в дополнение 14 пункте "Новый вид пакета луковичной маршрутизации". Проверка целостности луковичных пакетов Раньше я об этом не задумался, но дальнейшая разработка мессенджера без проверки целостности пакетов может привести к непредсказуемым последствиям. Пакет при передаче может быть поврежден, что негативно отразиться на работу мессенджера. С целью обеспечения проверки целостности пакетов из них будет высчитываться SHA-256 хэш. На основе проверочного хэша будет проверяться целостность пакетов и правильность дешифровки данных. Также проверка целостности пакетов обеспечит возможность нод сети преднамеренно повредить пакет данных. Проверка целостности пакетов должна основываться на шести принципах: а) Целостность полезной нагрузки не должна быть нарушена б) Целостность технической информации в хвосте пакета не должна быть нарушена г) Должна отсутствовать возможность подменить проверочные хэши так, что бы проверка хэша после подмены прошла успешно. д) Желательно избавиться от избыточности передаваемых данных для экономии трафика е) Проверочные хэши не должны передаваться явно для того, что б отследить пакет данных по проверочным хэшам не было возможности. Должен менятся как размер, так и содержимое блока хранящего проверочные хэши. ж) Исполняющая нода должна иметь возможность интегрировать в пакет хэши ответа на запрос так, что бы выполнялись первые 5 принципов проверки целостности пакета. Новый вид луковичного пакета данных смотрите в дополнение 14 пункте "Новый вид пакета луковичной маршрутизации". Отказ от использования Trash to max С целью усиление защиты от возможности отслеживания пакета по его содержимому или длине ранее было решено добавлять к технической информации мусорные данные Trash to max задачей которых была приравнять длину технической информации к 512 байтам. Но, хорошо обдумав весь механизм обработки луковичного пакета, было решено отказаться от данной затеи. Чем это обусловлено? Техническая информация для каждой ноды сети вшитая в блок полезной нагрузки скрыта от других нод при помощи симметричного алгоритма шифрования AES256. После шифрования блока технической информации его длина не будет равна длине до шифрования. Таким образом истинную длину и истинное содержимое блока можно узнать только проведя дешифровку. Не зная все AES256 ключи узнать истинное содержимое блока данных и истинную длину этого блока не представляется возможным. Таким образом блоки технической информации уже защищены от отслеживания, а значит интегрировать дополнительный уровень защиты в виде Trash to max является не целесообразным. С другой стороны, убрав из блоков технических данных Trash to max мы уменьшим пакет данных и, тем самым, уменьшим нагрузку на сеть. Новый вид луковичного пакета данных смотрите в дополнение 14 пункте "Новый вид пакета луковичной маршрутизации". Новый вид пакета луковичной маршрутизации После внедрения новых изменений луковичный пакет данных будет иметь следующий вид: 0x190 EL Trash AES1(0х190 DL QID AES.c(DCH Data) NID1 ETDL1 AES6(RSA1(2 SID AES.ch2 AES7 TL7 NID2 CH.td1)) NID2 ETDL2 AES1(RSA2(0 IP3 AES.ch3 AES2 AES3 TL2 TL3 NID3 CH.td2)) NID3 ETDL3 AES2(RSA3(0 IP4 AES.ch4 AES3 AES4 TL3 TL4 NID4 CH.td3)) NID4 ETDL4 AES3(RSA4(1 IP5 AES.c NID1 AES.ch1 NID2 AES.ch2 NID3 AES.ch3 NID4 AES.ch4 NID5 AES.ch5 NID6 AES.ch6 AES4 AES5 TL4 TL5 NID5 CH.td4)) NID5 ETDL5 AES4(RSA5(0 IP1 AES.ch6 AES5 AES6 TL5 TL6 NID6 CH.td5)) NID6 ETDL6 AES5(RSA6(0 IP4 AES.ch1 AES6 AES7 TL6 TL7 NID1 CH.td6)) NID1 EHL1 AES.ch1(CH.pl) NID2 EHL2 AES.ch2(CH.pl) NID3 EHL3 AES.ch3(CH.pl) NID4 EHL4 AES.ch4(CH.pl) NID5 EHL5 AES.ch5(CH.pl) NID6 EHL6 AES.ch6(CH.pl)) RSA1(0 IP2 AES.ch2 AES1 AES2 TL1 TL2 NID2 CH.td1) Рассмотрим новый вид пакета подробней. Как и раньше мы можем видеть трехбайтовую метку 0x190 в начале пакета. Она уведомляет ноду о том, что пакет является луковичным и его надо обрабатывать соответствующим образом. После этого присутствует трехбайтовая длина зашифрованной полезной нагрузки и добавляемого к пакету мусора EL. Затем следует сам мусор длина которого не фиксирована и вычислить размер которого можно отняв из EL длину мусора которую можно получить дешифровав технические данные добавленные в конце пакета. Затем идет полезная нагрузка содержащая в себе зашифрованные данные, зашифрованную техническую информацию для всех нод и зашифрованные хэши полезной нагрузки. Полезная нагрузка зашифрована AES256 симметричным алгоритмом ключ которого можно получить дешифровав технические данные добавленные в конце пакета. Рассмотрим содержимое полезной нагрузки. Здесь также присутствует метка 0x190 информирующая ноду о том, что дешифровка данных прошла успешно и что этот пакет действительно является луковичным. Затем 3 байта длины зашифрованных данных, 4 байта идентификатора запроса и сами зашифрованные ключом AES.c данные. Данные содержат в себе контрольный от данных и сами передаваемые в пакете данные. После этого в полезную нагрузку вшивается вся техническая информация всех нод в зашифрованном виде, идентификаторы нод к которым относятся части технической информации и длина каждой части. NID1 - идентификатор клиентской ноды. ETDL1 - длина технической информации адресованной клиентской ноде. И сама техническая информация зашифрованная ключом AES6 и открытым ключом RSA1. Внутри этой части технической информации содержится: Однобайтовая метка 2 уведомляющая ноду о том, что данная нода является клиентской и пакет нужно отдать клиенту. AES.ch2 - AES ключ для дешифровки хэша. SID - 4 байта идентификатора сессии клиента. AES7 - ключ которым зашифрована полезная нагрузка. TL7 - объем мусора добавленного к луковичному пакету. NID2 - идентификатор второй ноды в кольце. CH.td1 - проверочный хжш от технических данных необходимый для проверки их целостности. Затем следуют технические данные адресованные первой входящей ноде. NID2 - идентификатор первой входящей ноды. ETDL2 - длина технической информации адресованной первой входящей ноде. Сама техническая информация зашифрованная ключом AES1 и открытым ключом RSA2. Внутри этой части технических данных указана метка 0 указывающая ноде, что пакет нужно просто обработать и переслать следующей ноде, 4 байта IP адреса следующей ноды, AES.ch2 - AES ключ для дешифровки хэша, ключ AES2 которым зашифрована полезная нагрузка, ключ AES3 которым следует зашифровать полезную нагрузку перед тем как отправить её следующей ноде, TL2 - объем мусора добавленного к пакету, TL3 - объем мусора который следует добавить к пакету перед тем как отсылать его следующей ноде, NID3 - идентификатор первой выходящей ноды, CH.td2 - проверочный хэш данной части технических данных необходимых для контроля их целостности. Аналогичное содержимое имеют части NID3, NID5 и NID6. Их подробного рассмотрения не требуется. Последний блок технических данных адресован исполняющей ноде. NID4 её идентификатор, ETDL4 - длина зашифрованных технических данных и сами технические данные зашифрованные ключом AES3 и открытым ключом RSA4. Содержимое технических данных для исполняющей ноды имеет следующий вид: Однобайтовая метка 1 указывает на то, что ноде следует выполнить запрос указанный в пакете и отправить ответ клиенту. Затем следуют 4 байта IP адреса второй входящей ноды кольца. AES.c - AES ключ клиента которым зашифрованы данные и которыми следует зашифровать ответ. Группа AES ключей по 32 байта каждый и идентификатор ноды с которой связан ключ длиной 1 байт общей длиной 198 байта - ключи всех нод для дешифровки/шифрования хэшей (благодаря этим ключам исполняющая нода сможет зашифровать хэш ответа на запрос), AES4 - ключ которым на текущий момент зашифрована полезная нагрузка. AES5 - ключ которым нужно зашифровать полезную нагрузку перед отправкой следующей ноде. TL4 - объем мусора добавленного к пакету на текущий момент. TL5 - объем мусора который следует добавить к пакету перед отправкой на следующую ноду. NID5 - идентификатор второй входящей ноды кольца. CH.td4 - проверочный хэш технической информации. Следующий блок в полезной нагрузке - блок хэшей. Он имеет одинаковую структуру для каждой ноды. Один байт идентификатора ноды в кольце, 2 байта длины зашифрованного хэша и сам хэш зашифрованный соответствующим ключом. На этом содержимое полезной нагрузки заканчивается и мы переходим к описанию технической информации. В хвосте луковичного пакета записывается техническая информация для следующей ноды кольца. Она зашифрована только открытым ключом следующей ноды. Пример содержимого технического блока можно посмотреть выше. Обработка луковичных пакетов на каждом уровне кольца В дополнениях 13 и 14 я подробно расписал как будет выглядеть пакет луковичной маршрутизации. Как он будет обрабатываться нодами в принципе можно понять и самостоятельно, но всё-же я подробно распишу как будут обрабатываться пакеты на каждом уровне кольца, так как в последствие это все-равно нужно будет сделать. Итак, клиент сгенерировал изначальный пакет луковичной маршрутизации и отправил его в сеть. Допусти, что пакет имеет следующий вид. 0x190 EL Trash AES1(0х190 DL QID AES.c(DCH Data) NID1 ETDL1 AES6(RSA1(2 SID AES.ch2 AES7 TL7 NID2 CH.td1)) NID4 ETDL4 AES3(RSA4(1 IP5 AES.c NID6 AES.ch6 NID2 AES.ch2 NID4 AES.ch4 NID3 AES.ch3 NID1 AES.ch1 NID5 AES.ch5 AES4 AES5 TL4 TL5 NID5 CH.td4)) NID3 ETDL3 AES2(RSA3(0 IP4 AES.ch4 AES3 AES4 TL3 TL4 NID4 CH.td3)) NID2 ETDL2 AES1(RSA2(0 IP3 AES.ch3 AES2 AES3 TL2 TL3 NID3 CH.td2)) NID6 ETDL6 AES5(RSA6(0 IP4 AES.ch1 AES6 AES7 TL6 TL7 NID1 CH.td6)) NID5 ETDL5 AES4(RSA5(0 IP1 AES.ch6 AES5 AES6 TL5 TL6 NID6 CH.td5)) NID5 EHL5 AES.ch5(CH.pl) NID2 EHL2 AES.ch2(CH.pl) NID4 EHL4 AES.ch4(CH.pl) NID1 EHL1 AES.ch1(CH.pl) NID6 EHL6 AES.ch6(CH.pl) NID3 EHL3 AES.ch3(CH.pl)) RSA1(0 IP2 AES.ch2 AES1 AES2 TL1 TL2 NID2 CH.td1) Как видите я рандомизировал позиции технической информации внутри полезной нагрузки, что и должно происходить в реальных условиях. а) Формирование пакета клиентом Как выглядит пакет Вы, уважаемый мембер, видите выше. А вот как он был сформирован? По каким алгоритмам? До текущего момента это оставалось тайной. Но когда-либо всё тайное становится явным. Настало время подробно поговорить о формирование луковичного пакета. У клиента есть тело запроса Data которое он хочет отправить в сеть. Клиент выберет уникальный (отсутствующий в памяти клиента) QID. Это случайное число длиной 4 байта будет идентификатором запроса. Также будет сгенерирован случайный AES.c длиной 32 байта. Сопоставление QID с AES.c будет сохранено в памяти клиента. Кроме того клиентом будут сгенерированы случайным образом ключи AES.ch1, AES.ch2, AES.ch3, AES.ch4, AES.ch5 и AES.ch6 нужные для шифрования/дешифровки хэшей и ключи AES1, AES2, AES3, AES4, AES5, AES6 и AES7 нужные для шифрования/дешифрования пакета. Все ключи будут иметь длину 32 байта. Теперь нужно выбрать кольцо через которое будет проходить запрос. Клиентская нода уже выбрана клиентом и он подключен к ней. Ключ RSA1 и IP адрес клиентской ноды IP1 известны. Также известен идентификатор сессии SID с которым сопоставляется клиент при подключение к ноде. Остальные ноды выбираются случайным образом из ANL листа клиента. При необходимости ANL лист может быть обновлен при помощи DANS нод. Клиенту нужно выбрать первую входящую и первую выходящую ноды, исполняющую ноду, а также вторую входящую и вторую выходящую ноды. Выбрав их клиент получает их IP адреса и их открытые RSA ключи. IP2, IP3, IP4, IP5, IP6, а также RSA2, RSA3, RSA4, RSA5 и RSA6 становятся известны. Каждой ноде присваивается свой случайный NID длиной один байт. Он должен быть уникален в пределах текущего пакета. Не забываем выбрать случайные TL1, TL2, TL3, TL4, TL5, TL6 и TL7 - размер мусора добавляемого к пакету длиной 2 байта каждый. С этого момента все данные для генерации пакета клиентом известны и можно приступать к его сборке. В первую очередь клиент вычислит SHA256 хэш из Data. Полученный DCH будет добавлен к началу запроса. Полученный блок данных будет зашифрован ранее сгенерированным ключом AES.c. К началу пакета будут добавлены 4 байта QID. длина зашифрованного блока данных будет добавлена к началу пакета в виде трех байт DL. Также в начало пакета будет добавлены три байта метки луковичного пакета 0x190. Формирование блока данных завершено. 0х190 DL QID AES.c(DCH Data) Клиент переходит к этапу формирования общей технической информации. Для начала формируем техническую информацию для клиентской ноды используемую по факту возврата ответа. Начинаем техническую информацию для данной ноды с метки 2. К ней добавляем 4 байта идентификатора сессии SID, ключи AES.ch2 и AES7 длиной 32 байта каждый, 2 байта длины мусора TL7 и 1 байт идентификатора ноды NID2. Из полученного массива технической информации вычисляем SHA256 хэш CH.td1 и дозаписываем его в конец массива. Полученный массив технической информации шифруем открытым ключом клиентской ноды RSA1, поверх шифруем AES алгоритмом используя ключ AES6. Вычисляем его длину и дозаписываем её в виде трех байт ETDL1 в начало массива. И добавляем ещё один байт идентификатора ноды NID1. Получена техническая информация клиентской ноды для возвращаемого пакета. NID1 ETDL1 AES6(RSA1(2 SID AES.ch2 AES7 TL7 NID2 CH.td1)) Хочу обратить внимание на одну интересную особенность. Как видно из структуры технической информации, в ней указан ключ для дешифровки хэша первой входящей ноды и её же идентификатор NID2. Это обсуловлено тем, что указать идентификатор NID1 и ключ AES.ch1 мы возможности не имеем, так как ими оперирует вторая выходящая нода. С целью защиты от подмены пакета пришлось пойти на хитрость и указывать ключ и идентификатор другой ноды которая известна клиентской ноде. А ей как раз и является первая входящая нода. Теперь формируем техническую информацию для первой входящей ноды. Начинаем техническую информацию с метки 0. Добавляем 4 байта IP адреса первой выходящей ноды IP3, ключи AES.ch3, AES2 и AES3 по 32 байта каждый, длину мусора TL2 и TL3 по 32 байта каждый и один байт идентификатора ноды NID3. Вычисляем хэш из полученных данных и записываем его 32 байта CH.td2 в конец массива. Шифруем все при помощи ключей RSA2 и AES1. Добавляем в начало 3 байта длины зашифрованных данных ETDL2 и идентификатор ноды NID2. По анологичному принципу формируем техническую информацию для первой выходящей, второй входящей и второй выходящей нод. NID2 ETDL2 AES1(RSA2(0 IP3 AES.ch3 AES2 AES3 TL2 TL3 NID3 CH.td2)) NID3 ETDL3 AES2(RSA3(0 IP4 AES.ch4 AES3 AES4 TL3 TL4 NID4 CH.td3)) NID5 ETDL5 AES4(RSA5(0 IP1 AES.ch6 AES5 AES6 TL5 TL6 NID6 CH.td5)) NID6 ETDL6 AES5(RSA6(0 IP4 AES.ch1 AES6 AES7 TL6 TL7 NID1 CH.td6)) Осталось сформировать техническую информацию для исполняющей ноды. Но для начала клиент формирует массив сопоставлений идентификатора ноды к ключу дешифровки хэша. Массив сопоставлений будет иметь следующий вид: NID1 AES.ch1 NID2 AES.ch2 NID3 AES.ch3 NID4 AES.ch4 NID5 AES.ch5 NID6 AES.ch6 После формирования массива позиции его элементов следует разместить в случайном порядке и объединить в единое целое. По факту окончания этой операции будет получен блок сопоставлений общей длиной 198 байт: NID6 AES.ch6 NID2 AES.ch2 NID4 AES.ch4 NID3 AES.ch3 NID1 AES.ch1 NID5 AES.ch5 Теперь можно перейти к формированию технической информации. Она начинается с метки 1. Затем к ней добавляются 4 байта IP адреса второй входящей ноды IP5, 32 байта ключа клиента AES.c, ранее сгенерированный и рандомизированный блок сопоставлений длиной 198 байт, ключи AES4 и AES5 общей длиной 64 байта, по два байта длины мусора TL4 и TL5 и один байт идентификатора ноды NID5. 32 байта хэша CH.td4 из сгенерированного массива будут добавлены в его конец. Окончательно сформированный массив данных следует зашифровать ключами RSA4 и AES3, добавить в начало три байта длины зашифрованных данных ETDL4 и один байт идентификатора ноды NID4. NID4 ETDL4 AES3(RSA4(1 IP5 AES.c NID6 AES.ch6 NID2 AES.ch2 NID4 AES.ch4 NID3 AES.ch3 NID1 AES.ch1 NID5 AES.ch5 AES4 AES5 TL4 TL5 NID5 CH.td4)) Теперь все части технической информации следует распределить случайным образом и объединить в единое целое. Блок общей технической информации после рандомизации примет следующий вид: NID1 ETDL1 AES6(RSA1(2 SID AES.ch2 AES7 TL7 NID2 CH.td1)) NID4 ETDL4 AES3(RSA4(1 IP5 AES.c NID6 AES.ch6 NID2 AES.ch2 NID4 AES.ch4 NID3 AES.ch3 NID1 AES.ch1 NID5 AES.ch5 AES4 AES5 TL4 TL5 NID5 CH.td4)) NID3 ETDL3 AES2(RSA3(0 IP4 AES.ch4 AES3 AES4 TL3 TL4 NID4 CH.td3)) NID2 ETDL2 AES1(RSA2(0 IP3 AES.ch3 AES2 AES3 TL2 TL3 NID3 CH.td2)) NID6 ETDL6 AES5(RSA6(0 IP4 AES.ch1 AES6 AES7 TL6 TL7 NID1 CH.td6)) NID5 ETDL5 AES4(RSA5(0 IP1 AES.ch6 AES5 AES6 TL5 TL6 NID6 CH.td5)) Осталось ещё всего несколько этапов генерации пакета. Следующий из них - формирование блока хэшей. Блок данных и блок общей технической информации объединяются и из них вычисляется SHA256 хэш. В результате будет получен контрольный хэш полезной нагрузки CH.pl. Теперь его нужно зашифровать и разместить в блоке хэшей. Но зашифровать его следует так, что б каждая нода могла оперировать только с своей частью блока хэшей. Поэтому для каждой ноды контрольный хэш будет зашифрован отдельно и каждая часть будет зашифрована своим ключом. Рассмотрим этот процесс на примере первой ноды. Контрольный хэш шифруется ключом AES.ch1. В начало зашифрованного массива данных добавляется 3 байта длины зашифрованной части EHL1. После этого в начало добавляется один байт идентификатора ноды NID1. Для всех остальных нод шифрование хэшей производится по похожему принципу. В результате будет получен блок хэшей: NID1 EHL1 AES.ch1(CH.pl) NID2 EHL2 AES.ch1(CH.pl) NID3 EHL3 AES.ch1(CH.pl) NID4 EHL4 AES.ch1(CH.pl) NID5 EHL5 AES.ch1(CH.pl) NID6 EHL6 AES.ch1(CH.pl) В последствие позиции частей в блоке хэшей рандомизируются и все части объединяются в одно целое. Конечный вид блока хэшей: NID5 EHL5 AES.ch5(CH.pl) NID2 EHL2 AES.ch2(CH.pl) NID4 EHL4 AES.ch4(CH.pl) NID1 EHL1 AES.ch1(CH.pl) NID6 EHL6 AES.ch6(CH.pl) NID3 EHL3 AES.ch3(CH.pl)) Блок данных, блок общей технической информации и блок хэшей объединяются и шифруются ключом AES1. В начало пакета добавляется мусор Trash длиной TL1. Затем вычисляется общая длина полезной нагрузки с мусором и добавляется в начало пакета в виде трех байт EL. И, также в начало пакета, добавляется идентификатор луковичного пакета длиной три байта - 0x190. Осталось сформировать техническую информацию для клиентской ноды. Её начало будет равно байту 0. Затем следуют 4 байта IP адреса первой входящей ноды IP2, ключи AES.ch2, AES1 и AES2 по 32 байта каждый, длина мусора TL1 и TL2 по 2 байта каждый и идентификатор ноды NID2 длиной один байт. Из полученных данных вычисляется хэш CH.td1 и добавляется в конец технической информации в виде 32 байт. Полученная техническая информация шифруется ключом RSA1 и добавляется в конец пакета. На этом этапе пакет полностью сформирован и отправляется в сеть через клиентскую ноду. б) Обработка пакета клиентской нодой на входе пакета в сеть, а также всеми входящими и выходящими нодами Клиентская нода получает пакет луковичной маршрутизации и начинает его обработку. Первым делом проверяются первые 3 байта полученного пакета. Они должны быть равны 0х190, что указывает на то, что данный пакет является луковичным пакетом и его нужно обрабатывать соответствующим образом. Если данное условие не выполнено, то пакет не является луковичным и его нужно обрабатывать по другим правилам. Затем из пакета удаляются первые три байта. Остается следующая информация: EL Trash AES1(0х190 DL QID AES.c(DCH Data) NID1 ETDL1 AES6(RSA1(2 SID AES.ch2 AES7 TL7 NID2 CH.td1)) NID4 ETDL4 AES3(RSA4(1 IP5 AES.c NID6 AES.ch6 NID2 AES.ch2 NID4 AES.ch4 NID3 AES.ch3 NID1 AES.ch1 NID5 AES.ch5 AES4 AES5 TL4 TL5 NID5 CH.td4)) NID3 ETDL3 AES2(RSA3(0 IP4 AES.ch4 AES3 AES4 TL3 TL4 NID4 CH.td3)) NID2 ETDL2 AES1(RSA2(0 IP3 AES.ch3 AES2 AES3 TL2 TL3 NID3 CH.td2)) NID6 ETDL6 AES5(RSA6(0 IP4 AES.ch1 AES6 AES7 TL6 TL7 NID1 CH.td6)) NID5 ETDL5 AES4(RSA5(0 IP1 AES.ch6 AES5 AES6 TL5 TL6 NID6 CH.td5)) NID5 EHL5 AES.ch5(CH.pl) NID2 EHL2 AES.ch2(CH.pl) NID4 EHL4 AES.ch4(CH.pl) NID1 EHL1 AES.ch1(CH.pl) NID6 EHL6 AES.ch6(CH.pl) NID3 EHL3 AES.ch3(CH.pl)) RSA1(0 IP2 AES.ch2 AES1 AES2 TL1 TL2 NID2 CH.td1) Следующие 3 байта EL соответстуют размеру полезной нагрузки и мусорных данных добавленных к пакету. Зная этот размер мы можем его удалить из пакета и разделить пакет на два блока. Блок полезной нагрузки: Trash AES1(0х190 DL QID AES.c(DCH Data) NID1 ETDL1 AES6(RSA1(2 SID AES.ch2 AES7 TL7 NID2 CH.td1)) NID4 ETDL4 AES3(RSA4(1 IP5 AES.c NID6 AES.ch6 NID2 AES.ch2 NID4 AES.ch4 NID3 AES.ch3 NID1 AES.ch1 NID5 AES.ch5 AES4 AES5 TL4 TL5 NID5 CH.td4)) NID3 ETDL3 AES2(RSA3(0 IP4 AES.ch4 AES3 AES4 TL3 TL4 NID4 CH.td3)) NID2 ETDL2 AES1(RSA2(0 IP3 AES.ch3 AES2 AES3 TL2 TL3 NID3 CH.td2)) NID6 ETDL6 AES5(RSA6(0 IP4 AES.ch1 AES6 AES7 TL6 TL7 NID1 CH.td6)) NID5 ETDL5 AES4(RSA5(0 IP1 AES.ch6 AES5 AES6 TL5 TL6 NID6 CH.td5)) NID5 EHL5 AES.ch5(CH.pl) NID2 EHL2 AES.ch2(CH.pl) NID4 EHL4 AES.ch4(CH.pl) NID1 EHL1 AES.ch1(CH.pl) NID6 EHL6 AES.ch6(CH.pl) NID3 EHL3 AES.ch3(CH.pl) Блок технической информации: RSA1(0 IP2 AES.ch2 AES1 AES2 TL1 TL2 NID2 CH.td1) На текущий момент клиентская нода работает с технической информацией. Она дешифруется при помощи закрытого RSA ключа клиентской ноды RSA1. После дешифровки клиентская нода получает следующие данные: 0 - метка означающая, что данный пакет следует просто переслать другой ноде. 1 байт. IP2 - IP адрес следующей ноды в кольце. 4 байта. AES.ch2 - ключ для дешифровки контрольного хэша полезной нагрузки AES1 - AES ключ которым следует дешифровать полезную нагрузку и блок хэшей. 32 байта. AES2 - AES ключ которым следует зашифровать полезную нагрузку и блок хэшей перед отправкой пакета следующей ноде. 32 байта. TL1 - размер мусора добавленного к пакету. 2 байта TL2 - сколько мусора нужно добавить к пакету перед его отправкой следующей ноде. 2 байта. NID2 - идентификатор следующей ноды в кольце. 1 байт. CH.td1 - проверочный хэш технической информации. Нода вычиляет SHA256 хэш из 0 IP2 AES.ch2 AES1 AES2 TL1 TL2 NID2 и сравнивает его c CH.td1. Если они совпадают, то данные дешифрованы верно и целостность пакета не нарушена. А значит можно продолжать обработку пакета. Теперь клиентской нодой получена вся информация необходимая для преобразования пакета. Пора приступать к обработке полезной нагрузки. Зная длину мусора добавленного к полезной нагрузки TL1 и ключ AES1 необходимый для её дешифрации клиентская нода откидывает мусора и дешифрует оставшуюся полезную нагрузку. По факту выполнения данных операций, как и ожидается, остается дешифрованная полезная нагрузка, техническая информация для других нод и контрольные хэши полезной нагрузки. 0х190 DL QID AES.c(DCH Data) NID1 ETDL1 AES6(RSA1(2 SID AES.ch2 AES7 TL7 NID2 CH.td1)) NID4 ETDL4 AES3(RSA4(1 IP5 AES.c NID6 AES.ch6 NID2 AES.ch2 NID4 AES.ch4 NID3 AES.ch3 NID1 AES.ch1 NID5 AES.ch5 AES4 AES5 TL4 TL5 NID5 CH.td4)) NID3 ETDL3 AES2(RSA3(0 IP4 AES.ch4 AES3 AES4 TL3 TL4 NID4 CH.td3)) NID2 ETDL2 AES1(RSA2(0 IP3 AES.ch3 AES2 AES3 TL2 TL3 NID3 CH.td2)) NID6 ETDL6 AES5(RSA6(0 IP4 AES.ch1 AES6 AES7 TL6 TL7 NID1 CH.td6)) NID5 ETDL5 AES4(RSA5(0 IP1 AES.ch6 AES5 AES6 TL5 TL6 NID6 CH.td5)) NID5 EHL5 AES.ch5(CH.pl) NID2 EHL2 AES.ch2(CH.pl) NID4 EHL4 AES.ch4(CH.pl) NID1 EHL1 AES.ch1(CH.pl) NID6 EHL6 AES.ch6(CH.pl) NID3 EHL3 AES.ch3(CH.pl) Первые 3 байта дешифрованных данных также должны равняться 0х190. Это свидетельствует о том, что дешифровка прошла успешно и данный пакет действительно является луковичным. Следующие три байта - длина самой полезной нагрузки зашифрованной AES.c ключом клиента. Ещё 4 байта - идентификатор запроса. Затем идут DL байт зашифрованный полезной нагрузки. С этими тремя параметрами нода пока ничего сделать не может. Поэтому эти данные извлекаются из основного массива и отдельно сохраняются в памяти. Блок данных: 0х190 DL QID AES.c(DCH Data) Оставшуюся информацию в массиве полезной нагрузки следует разделить на блок общей технической информации и блок хешей. Блок общей технической информации делиться на 6 частей. Все они имеют одинаковый вид. Один байт идентификатора ноды, 3 байта длины зашифрованной технической информации (ETDLx) и ETDLx байт самой зашифрованной технической информации. Зная это мы можем выделить блок общей технической информации: NID1 ETDL1 AES6(RSA1(2 SID AES.ch2 AES7 TL7 NID2 CH.td1)) NID4 ETDL4 AES3(RSA4(1 IP5 AES.c NID6 AES.ch6 NID2 AES.ch2 NID4 AES.ch4 NID3 AES.ch3 NID1 AES.ch1 NID5 AES.ch5 AES4 AES5 TL4 TL5 NID5 CH.td4)) NID3 ETDL3 AES2(RSA3(0 IP4 AES.ch4 AES3 AES4 TL3 TL4 NID4 CH.td3)) NID2 ETDL2 AES1(RSA2(0 IP3 AES.ch3 AES2 AES3 TL2 TL3 NID3 CH.td2)) NID6 ETDL6 AES5(RSA6(0 IP4 AES.ch1 AES6 AES7 TL6 TL7 NID1 CH.td6)) NID5 ETDL5 AES4(RSA5(0 IP1 AES.ch6 AES5 AES6 TL5 TL6 NID6 CH.td5)) Оставшиеся данные - это блок хэшей: NID5 EHL5 AES.ch5(CH.pl) NID2 EHL2 AES.ch2(CH.pl) NID4 EHL4 AES.ch4(CH.pl) NID1 EHL1 AES.ch1(CH.pl) NID6 EHL6 AES.ch6(CH.pl) NID3 EHL3 AES.ch3(CH.pl) В первую очередь нода должна сравнить хэш полезной нагрузки с контрольным хэшем CH.pl. Но не стоит забывать, что CH.pl сейчас находится в зашифрованном виде. Что бы его получить, ноде в начале нужно найти часть блока хэшей которую она сможет дешифровать. Собственный идентификатор ноде неизвестен, но ей известен идентификатор следующей ноды в кольце NID2. Также ноде известен ключ дешифровки хэша AES.ch2. Следует воспользоваться этой информацией и распарсить блок хэшей найдя в нем часть принадлежащую ноде с идентификатором NID2. Рассмотрим весь процесс подробно. Первый байт блока хэшей соответствует идентификатору ноды NID5. Он не совпадает с идентификатором NID2. Значит нода не может оперировать с текущей частью блока. Поэтому следующие 3 байта EHL5 указывают на то, сколько байт нужно пропустить в блоке хэшей. Пропускаем их и переходим к следующей части блока. Здесь, как видно, первый байт совпадает с искомым идентификатором ноды NID2. Следующие 3 байта EHL2 указывают на то сколько байт следует считать из блока. Считываем и дешифруем их при помощи ключа AES.ch2. На выходе получаем контрольный хэш полезной нагрузки CH.pl. Вычисляем SHA256 хэш из полезной нагрузки: SHA256(0х190 DL QID AES.c(DCH Data) NID1 ETDL1 AES6(RSA1(2 SID AES.ch2 AES7 TL7 NID2 CH.td1)) NID4 ETDL4 AES3(RSA4(1 IP5 AES.c NID6 AES.ch6 NID2 AES.ch2 NID4 AES.ch4 NID3 AES.ch3 NID1 AES.ch1 NID5 AES.ch5 AES4 AES5 TL4 TL5 NID5 CH.td4)) NID3 ETDL3 AES2(RSA3(0 IP4 AES.ch4 AES3 AES4 TL3 TL4 NID4 CH.td3)) NID2 ETDL2 AES1(RSA2(0 IP3 AES.ch3 AES2 AES3 TL2 TL3 NID3 CH.td2)) NID6 ETDL6 AES5(RSA6(0 IP4 AES.ch1 AES6 AES7 TL6 TL7 NID1 CH.td6)) NID5 ETDL5 AES4(RSA5(0 IP1 AES.ch6 AES5 AES6 TL5 TL6 NID6 CH.td5))) Полученный хэш сравниваем с контрольным. Если они совпадают, то целостность полезной нагрузки не нарушена и пакет можно обрабатывать дальше. Теперь клиентская нода должна распарсить блок общей технической информации и найти в нем технические данные адресованные следующей ноде кольца. Поиск производится по идентификатору ноды NID2. Рассмотрим процедуру поиска немного подробней. Первый байт данных (NID1) сравнивается с искомым идентификатором ноды (NID2). Они не совпадают. Значит нужно пропустить столько байт в блоке, сколько указанно в следующих трех байтах ETDL1. ETDL1 - это длина зашифрованной технической информации в этой части блока. Пропустив нужное количество байт нода повторяет процедуру поиска. Процедура поиска будет повторена ещё 2 раза, поскольку идентификаторы NID4 и NID3 не совпадают с искомым идентификатором NID2. На следующем цикле поиска NID2 уже будет найден. В этот раз нода считает столько байт из блока, сколько указано в 3 байтах длины ETDL2 и дешифрует полученный массив известным ключом AES1. Проведя эти манипуляции клиентская нода получит технические данные для следующей ноды кольца RSA2(0 IP3 AES.ch3 AES2 AES3 TL2 TL3 NID3 CH.td2) Теперь пакет должен быть собран заново и отправлен следующей ноде. Опишу процесс сбора пакета кратко, так как в этом нет ничего особо сложного. К блоку данных добавляется блок общей технической информации и блок хэшей. Они шифруются при помощи ключа AES2. В их начало дописывается мусор длиной TL2. Затем вычисляет длина зашифрованной полезной нагрузки с мусором и добавляется в начало этого массива в виде 3 байт. Ещё три байта добаляются к началу полученного массива. Они равны 0x190. К полученному массиву добавляется блок технической информации для следующей ноды кольца. По завершению этого процесса пакет будет иметь вид: 0x190 EL Trash AES2(0х190 DL QID AES.c(DCH Data) NID1 ETDL1 AES6(RSA1(2 SID AES.ch2 AES7 TL7 NID2 CH.td1)) NID4 ETDL4 AES3(RSA4(1 IP5 AES.c NID6 AES.ch6 NID2 AES.ch2 NID4 AES.ch4 NID3 AES.ch3 NID1 AES.ch1 NID5 AES.ch5 AES4 AES5 TL4 TL5 NID5 CH.td4)) NID3 ETDL3 AES2(RSA3(0 IP4 AES.ch4 AES3 AES4 TL3 TL4 NID4 CH.td3)) NID2 ETDL2 AES1(RSA2(0 IP3 AES.ch3 AES2 AES3 TL2 TL3 NID3 CH.td2)) NID6 ETDL6 AES5(RSA6(0 IP4 AES.ch1 AES6 AES7 TL6 TL7 NID1 CH.td6)) NID5 ETDL5 AES4(RSA5(0 IP1 AES.ch6 AES5 AES6 TL5 TL6 NID6 CH.td5)) NID5 EHL5 AES.ch5(CH.pl) NID2 EHL2 AES.ch2(CH.pl) NID4 EHL4 AES.ch4(CH.pl) NID1 EHL1 AES.ch1(CH.pl) NID6 EHL6 AES.ch6(CH.pl) NID3 EHL3 AES.ch3(CH.pl)) RSA2(0 IP3 AES.ch3 AES2 AES3 TL2 TL3 NID3 CH.td2) Этот пакет будет отправлен следующей ноде кольца по адресу IP2. Входящие ноды NID2, NID5 и выходящие ноды NID3, NID6 обработают пакет по схожему принципу. Описывать процесс обработки повторно не требуется. в) Обработка пакета исполняющей нодой. Основной процесс обработки пакета исполняющей нодой будет похож на обработку пакета в прошлом пункте, но есть некоторые отличия. На них мы и обратим внимание в большей степени. Уже указанная выше информация будет или опущена, или предоставлена в сжатом виде. Пакет, поступающий на исполняющую ноду будет иметь следующий вид: 0x190 EL Trash AES4(0х190 DL QID AES.c(DCH Data) NID1 ETDL1 AES6(RSA1(2 SID AES.ch2 AES7 TL7 NID2 CH.td1)) NID4 ETDL4 AES3(RSA4(1 IP5 AES.c NID6 AES.ch6 NID2 AES.ch2 NID4 AES.ch4 NID3 AES.ch3 NID1 AES.ch1 NID5 AES.ch5 AES4 AES5 TL4 TL5 NID5 CH.td4)) NID3 ETDL3 AES2(RSA3(0 IP4 AES.ch4 AES3 AES4 TL3 TL4 NID4 CH.td3)) NID2 ETDL2 AES1(RSA2(0 IP3 AES.ch3 AES2 AES3 TL2 TL3 NID3 CH.td2)) NID6 ETDL6 AES5(RSA6(0 IP4 AES.ch1 AES6 AES7 TL6 TL7 NID1 CH.td6)) NID5 ETDL5 AES4(RSA5(0 IP1 AES.ch6 AES5 AES6 TL5 TL6 NID6 CH.td5)) NID5 EHL5 AES.ch5(CH.pl) NID2 EHL2 AES.ch2(CH.pl) NID4 EHL4 AES.ch4(CH.pl) NID1 EHL1 AES.ch1(CH.pl) NID6 EHL6 AES.ch6(CH.pl) NID3 EHL3 AES.ch3(CH.pl)) RSA4(1 IP5 AES.c NID6 AES.ch6 NID2 AES.ch2 NID4 AES.ch4 NID3 AES.ch3 NID1 AES.ch1 NID5 AES.ch5 AES4 AES5 TL4 TL5 NID5 CH.td4) На начальном этапе пакет, также как и раньше, делиться на два блока. Блок полезной нагрузки: Trash AES4(0х190 DL QID AES.c(DCH Data) NID1 ETDL1 AES6(RSA1(2 SID AES.ch2 AES7 TL7 NID2 CH.td1)) NID4 ETDL4 AES3(RSA4(1 IP5 AES.c NID6 AES.ch6 NID2 AES.ch2 NID4 AES.ch4 NID3 AES.ch3 NID1 AES.ch1 NID5 AES.ch5 AES4 AES5 TL4 TL5 NID5 CH.td4)) NID3 ETDL3 AES2(RSA3(0 IP4 AES.ch4 AES3 AES4 TL3 TL4 NID4 CH.td3)) NID2 ETDL2 AES1(RSA2(0 IP3 AES.ch3 AES2 AES3 TL2 TL3 NID3 CH.td2)) NID6 ETDL6 AES5(RSA6(0 IP4 AES.ch1 AES6 AES7 TL6 TL7 NID1 CH.td6)) NID5 ETDL5 AES4(RSA5(0 IP1 AES.ch6 AES5 AES6 TL5 TL6 NID6 CH.td5)) NID5 EHL5 AES.ch5(CH.pl) NID2 EHL2 AES.ch2(CH.pl) NID4 EHL4 AES.ch4(CH.pl) NID1 EHL1 AES.ch1(CH.pl) NID6 EHL6 AES.ch6(CH.pl) NID3 EHL3 AES.ch3(CH.pl) Блок технической информации: RSA4(1 IP5 AES.c NID6 AES.ch6 NID2 AES.ch2 NID4 AES.ch4 NID3 AES.ch3 NID1 AES.ch1 NID5 AES.ch5 AES4 AES5 TL4 TL5 NID5 CH.td4) Блок технической информации дешифровывается при помощи закрытого RSA ключа исполняющей ноды RSA4. После дешифровки от технической информации остаются следующие данные: 1 IP5 AES.c NID6 AES.ch6 NID2 AES.ch2 NID4 AES.ch4 NID3 AES.ch3 NID1 AES.ch1 NID 5 AES.ch5 AES4 AES5 TL4 TL5 NID5 CH.td4 С этого момента начинаются первые отличаи пакета адресованного исполняющей ноде, от пакетов адресованных пересылающим нодам. 1 - метка длиной 1 байт указывающая на то, что данная нода является исполняющей и она должна обработать запрос размещенный в полезной нагрузке. IP5 - IP адрес следующей ноды в кольце. Имеет длину 4 байта. AES.c - AES ключ клиента необходимый для окончательной дешифровки запроса и шифрования ответа. длина 32 байта. NID6 AES.ch6 NID2 AES.ch2 NID4 AES.ch4 NID3 AES.ch3 NID1 AES.ch1 NID5 AES.ch5 - 198 байт. AES ключи всех нод для дешифровки контрольного хэша и идентификаторы нод с которыми связанны эти ключи. Также с их помощью будут зашифрован хэш полезной нагрузки после замены запроса от клиента на ответ от ноды. длина каждого из 6 ключей - 32 байта. длина каждого идентификатора ноды - 1 байт. AES4 - ключ с помощью которого должна быть дешифрована полезная нагрузка. 32 байта. AES5 - ключ с помощью которого должна быть зашифрована полезная нагрузка перед отправкой пакета на следующую ноду. 32 байта. TL4 - сколько мусора добавлено к пакету. 2 байта. TL5 - сколько мусора следует добавить к пакету перед отправкой пакета на следующую ноду. 2 байта. NID5 - идентификатор следующей ноды в кольце. 1 байт. CH.td4 - контрольный хэш технической информации. 32 байта. Следующие несколько этапов являются аналогичными стандартной обработки пакета. Вычисляется хэш из 1 IP5 AES.c NID6 AES.ch6 NID2 AES.ch2 NID4 AES.ch4 NID3 AES.ch3 NID1 AES.ch1 NID 5 AES.ch5 AES4 AES5 TL4 TL5 NID5 Далее он сравнивается с контрольным хэшем CH.td4. Если они совпадают, то целостность технической информации не нарушена и пакет можно обрабатывать дальше. Из блока полезной нагрузки удаляется мусор длиной TL4 и оставшаяся полезная нагрузка дешифруется при помощи ключа AES4. Дешифрованная полезная нагрузка делиться на три части. Блок данных: 0х190 DL QID AES.c(DCH Data) Блок общей технической информации: NID1 ETDL1 AES6(RSA1(2 SID AES.ch2 AES7 TL7 NID2 CH.td1)) NID4 ETDL4 AES3(RSA4(1 IP5 AES.c NID6 AES.ch6 NID2 AES.ch2 NID4 AES.ch4 NID3 AES.ch3 NID1 AES.ch1 NID5 AES.ch5 AES4 AES5 TL4 TL5 NID5 CH.td4)) NID3 ETDL3 AES2(RSA3(0 IP4 AES.ch4 AES3 AES4 TL3 TL4 NID4 CH.td3)) NID2 ETDL2 AES1(RSA2(0 IP3 AES.ch3 AES2 AES3 TL2 TL3 NID3 CH.td2)) NID6 ETDL6 AES5(RSA6(0 IP4 AES.ch1 AES6 AES7 TL6 TL7 NID1 CH.td6)) NID5 ETDL5 AES4(RSA5(0 IP1 AES.ch6 AES5 AES6 TL5 TL6 NID6 CH.td5)) Блок хэшей: NID5 EHL5 AES.ch5(CH.pl) NID2 EHL2 AES.ch2(CH.pl) NID4 EHL4 AES.ch4(CH.pl) NID1 EHL1 AES.ch1(CH.pl) NID6 EHL6 AES.ch6(CH.pl) NID3 EHL3 AES.ch3(CH.pl) Из технической информации беруться 198 байт данных начиная с 38. NID6 AES.ch6 NID2 AES.ch2 NID4 AES.ch4 NID3 AES.ch3 NID1 AES.ch1 NID5 AES.ch5 Эти данные деляться на 6 частей 33 байта каждая. NID6 AES.ch6 NID2 AES.ch2 NID4 AES.ch4 NID3 AES.ch3 NID1 AES.ch1 NID5 AES.ch5 В этом блоке ищется та часть первый байт которой соответствует идентификатору NID5. В нашем случае это последняя запись. Из неё удаляется первый байт и оставшийся ключ AES.ch5 будет использоваться для дешифровки контрольного хэша. В блоке хэшей ищется часть соответствующая идентификатору ноды NID5. Она дешифруется при помощи ключа AES.ch5 полученного в прошлой операции и в результате будет получен контрольный хэш полезной нагрузки CH.pl. Вычисляется SHA256 хэш из полезной нагрузки: SHA256(0х190 DL QID AES.c(DCH Data) NID1 ETDL1 AES6(RSA1(2 SID AES.ch2 AES7 TL7 NID2 CH.td1)) NID4 ETDL4 AES3(RSA4(1 IP5 AES.c NID6 AES.ch6 NID2 AES.ch2 NID4 AES.ch4 NID3 AES.ch3 NID1 AES.ch1 NID5 AES.ch5 AES4 AES5 TL4 TL5 NID5 CH.td4)) NID3 ETDL3 AES2(RSA3(0 IP4 AES.ch4 AES3 AES4 TL3 TL4 NID4 CH.td3)) NID2 ETDL2 AES1(RSA2(0 IP3 AES.ch3 AES2 AES3 TL2 TL3 NID3 CH.td2)) NID6 ETDL6 AES5(RSA6(0 IP4 AES.ch1 AES6 AES7 TL6 TL7 NID1 CH.td6)) NID5 ETDL5 AES4(RSA5(0 IP1 AES.ch6 AES5 AES6 TL5 TL6 NID6 CH.td5))) Он сравнивается с контрольным. Если они совпадают - целостность полезной нагрузки не нарушена и пакет можно обрабатывать дальше. В блоке общей технической информации производится поиск части соответствующий идентификатору ноды NID5 и массив длиной ETDL5 дешифруется при помощи ключа AES4. Полученная техническая информация RSA5(0 IP4 AES.ch6 AES5 AES6 TL5 TL6 NID6 CH.td5) адресована следующей ноде в кольце и должна быть дозаписана в конец пакета по факту окончания его обработки и сборки. После всех выше перечисленных операций нода будет производить новые, ранее не описанные, действия. А именно обработку запроса. С этого момента времени ноде придется оперировать с блоком данных работа с которым ранее не производилась. Из блока данных убираются первые 10 байт (метка луковичного пакета, длина зашифрованных данных и идентификатор запроса). Оставшиеся зашифрованные данные AES.c(DCH Data) дешифруются при помощи ключа клиента AES.c. Этот ключ известен только клиенту и исполняющей ноде. Именно этим и обеспечивается сохранение содержимого запроса в тайне. После дешифровки исполняющая нода получит 32 байта контрольного хэш DCH от Data. Вычислив хэш из Data и сравнив его с DCH исполняющая нода может проверить целостность данных и убедиться в том, что данные дешифрованы верно. Оставшаяся информация Data - тело запроса который следует обработать. Что будет находится здесь и как следует обрабатывать эти данные зависит от ситуации. Если это запрос на отправку сообщения, то исполняющими нода свяжется с TSN нодами получателя, отправит им пересылаемое сообщение и должна будет отправить клиенту ответ об успешном выполнение. Если это запрос на получение новых сообщений, то исполняющая нода свяжется с TSN нодами пользователями, получит с них новые сообщения и вышлет их обратно клиенту (или же отправит ответ указывающий на то, что новых сообщений нет). И так далее. В мессенджере есть много вариантов запросов и моделировать обработку их всех в данном случае не имеет смысла. Главное то, что запрос будет обработан и ответ будет сформирован. Теперь ответ нужно будет записать в тело пакета и вычислить новые хэши. В начале следует вычислить новый контрольный хэш из ответа и идентификатора запроса. DCHnew=SHA256(Answer) Полученные данные следует объединить в формате контрольный хэш, ответ. Затем полученные данные нужно зашифровать при помощи клиентского ключа AES.c. К полученному массиву в начале добавить 3 байта 0x190, 3 байта длины зашифрованных новых данных DLnew и 4 байта идентификатора запроса QID Получен новый блок данных: 0x190 DLnew QID (DCHnew Answer) Вычисляем новый контрольный хэш полезной нагрузки: CH.plnew=SHA256(0x190 DLnew QID (DCHnew Answer) NID1 ETDL1 AES6(RSA1(2 SID AES.ch2 AES7 TL7 NID2 CH.td1)) NID4 ETDL4 AES3(RSA4(1 IP5 AES.c NID6 AES.ch6 NID2 AES.ch2 NID4 AES.ch4 NID3 AES.ch3 NID1 AES.ch1 NID5 AES.ch5 AES4 AES5 TL4 TL5 NID5 CH.td4)) NID3 ETDL3 AES2(RSA3(0 IP4 AES.ch4 AES3 AES4 TL3 TL4 NID4 CH.td3)) NID2 ETDL2 AES1(RSA2(0 IP3 AES.ch3 AES2 AES3 TL2 TL3 NID3 CH.td2)) NID6 ETDL6 AES5(RSA6(0 IP4 AES.ch1 AES6 AES7 TL6 TL7 NID1 CH.td6)) NID5 ETDL5 AES4(RSA5(0 IP1 AES.ch6 AES5 AES6 TL5 TL6 NID6 CH.td5))) Теперь новый хэш нужно зашифровать и добавить к полезной нагрузке. Для этого у нас есть все нужные ключи и известны все идентификаторы нод. Основываясь на блоке хэшей NID5 EHL5 AES.ch5(CH.pl) NID2 EHL2 AES.ch2(CH.pl) NID4 EHL4 AES.ch4(CH.pl) NID1 EHL1 AES.ch1(CH.pl) NID6 EHL6 AES.ch6(CH.pl) NID3 EHL3 AES.ch3(CH.pl) и сопоставлениях идентификатора ноды с ключом NID6 AES.ch6 NID2 AES.ch2 NID4 AES.ch4 NID3 AES.ch3 NID1 AES.ch1 NID5 AES.ch5 мы можем получить новый блок хэшей. Для примера приведу описание формирования первой записи блока хэшей. Первый байт блока хэшей соответствует идентификатору ноды NID5. Следующие три байта равны длине зашифрованного хэша. Удаляем первые 4 байта и EHL5 байт из блока хэшей. Ищем в списке сопоставлений идентификатор NID5 и получаем ключ AES.ch5 с которым он связан. Шифруем новый контрольный хэш полезной нагрузки при помощи ключа AES.ch5. В новый блок хэшей добавляем идентификатор ноды NID5, новую длину зашифрованного хэша и сам зашифрованный хэш. Повторяем операцию для всех остальных нод ещё 5 раз. Новый блок хэшей будет иметь вид: NID5 EHL5new AES.ch5(CH.plnew) NID2 EHL2new AES.ch2(CH.plnew) NID4 EHL4new AES.ch4(CH.plnew) NID1 EHL1new AES.ch1(CH.plnew) NID6 EHL6new AES.ch6(CH.plnew) NID3 EHL3new AES.ch3(CH.plnew)) Объединяем новый блок данных, блок общей технической информации и новый блок хэшей. Шифруем их при помощи ключа AES5, добавляем в начало пакета мусор Trash длиной TL5, вычисляем длину пакета с мусором EL и добавляем эти 3 байта также в начало пакета. И ещё три байта 0x190 снова добавляются в начало пакета. В конец пакета добавляется техническая информация для следующей ноды RSA5(0 IP4 AES.ch6 AES5 AES6 TL5 TL6 NID6 CH.td5) Новый пакет с ответом исполняющей ноды сформирован: 0x190 EL Trash AES5(0х190 DLnew QID AES.c(DCHnew Answer) NID1 ETDL1 AES6(RSA1(2 SID AES.ch2 AES7 TL7 NID2 CH.td1)) NID4 ETDL4 AES3(RSA4(1 IP5 AES.c NID6 AES.ch6 NID2 AES.ch2 NID4 AES.ch4 NID3 AES.ch3 NID1 AES.ch1 NID5 AES.ch5 AES4 AES5 TL4 TL5 NID5 CH.td4)) NID3 ETDL3 AES2(RSA3(0 IP4 AES.ch4 AES3 AES4 TL3 TL4 NID4 CH.td3)) NID2 ETDL2 AES1(RSA2(0 IP3 AES.ch3 AES2 AES3 TL2 TL3 NID3 CH.td2)) NID6 ETDL6 AES5(RSA6(0 IP4 AES.ch1 AES6 AES7 TL6 TL7 NID1 CH.td6)) NID5 ETDL5 AES4(RSA5(0 IP1 AES.ch6 AES5 AES6 TL5 TL6 NID6 CH.td5)) NID5 EHL5new AES.ch5(CH.plnew) NID2 EHL2new AES.ch2(CH.plnew) NID4 EHL4new AES.ch4(CH.plnew) NID1 EHL1new AES.ch1(CH.plnew) NID6 EHL6new AES.ch6(CH.plnew) NID3 EHL3new AES.ch3(CH.plnew)) RSA5(0 IP4 AES.ch6 AES5 AES6 TL5 TL6 NID6 CH.td5) Этот пакет отправляется на следующую ноду по адресу IP5, оперативная память очищается, исполняющая нода закончила свою работу. г) Возвращение пакета клиентской ноде Пройдя (все круги ада) все ноды кольца, пакет с ответом возвращается клиентской ноде. Теперь ответ должен быть возвращен клиенту. Но какому? Их может быть много. И как вообще следует обрабатывать этот пакет? Все принципы схожи, но и здесь есть отличия. Пакет принимаемый клиентской нодой имеет следующий вид: 0x190 EL Trash AES7(0х190 DL QID AES.c(DCH Data) NID1 ETDL1 AES6(RSA1(2 SID AES.ch2 AES7 TL7 NID2 CH.td1)) NID4 ETDL4 AES3(RSA4(1 IP5 AES.c NID6 AES.ch6 NID2 AES.ch2 NID4 AES.ch4 NID3 AES.ch3 NID1 AES.ch1 NID5 AES.ch5 AES4 AES5 TL4 TL5 NID5 CH.td4)) NID3 ETDL3 AES2(RSA3(0 IP4 AES.ch4 AES3 AES4 TL3 TL4 NID4 CH.td3)) NID2 ETDL2 AES1(RSA2(0 IP3 AES.ch3 AES2 AES3 TL2 TL3 NID3 CH.td2)) NID6 ETDL6 AES5(RSA6(0 IP4 AES.ch1 AES6 AES7 TL6 TL7 NID1 CH.td6)) NID5 ETDL5 AES4(RSA5(0 IP1 AES.ch6 AES5 AES6 TL5 TL6 NID6 CH.td5)) NID5 EHL5 AES.ch5(CH.pl) NID2 EHL2 AES.ch2(CH.pl) NID4 EHL4 AES.ch4(CH.pl) NID1 EHL1 AES.ch1(CH.pl) NID6 EHL6 AES.ch6(CH.pl) NID3 EHL3 AES.ch3(CH.pl)) RSA1(2 SID AES.ch2 AES7 TL7 NID2 CH.td1) Пакет вновь делится на два блока. Блок полезной нагрузки: Trash AES7(0х190 DL QID AES.c(DCH Data) NID1 ETDL1 AES6(RSA1(2 SID AES.ch2 AES7 TL7 NID2 CH.td1)) NID4 ETDL4 AES3(RSA4(1 IP5 AES.c NID6 AES.ch6 NID2 AES.ch2 NID4 AES.ch4 NID3 AES.ch3 NID1 AES.ch1 NID5 AES.ch5 AES4 AES5 TL4 TL5 NID5 CH.td4)) NID3 ETDL3 AES2(RSA3(0 IP4 AES.ch4 AES3 AES4 TL3 TL4 NID4 CH.td3)) NID2 ETDL2 AES1(RSA2(0 IP3 AES.ch3 AES2 AES3 TL2 TL3 NID3 CH.td2)) NID6 ETDL6 AES5(RSA6(0 IP4 AES.ch1 AES6 AES7 TL6 TL7 NID1 CH.td6)) NID5 ETDL5 AES4(RSA5(0 IP1 AES.ch6 AES5 AES6 TL5 TL6 NID6 CH.td5)) NID5 EHL5 AES.ch5(CH.pl) NID2 EHL2 AES.ch2(CH.pl) NID4 EHL4 AES.ch4(CH.pl) NID1 EHL1 AES.ch1(CH.pl) NID6 EHL6 AES.ch6(CH.pl) NID3 EHL3 AES.ch3(CH.pl) Блок технической информации: RSA1(2 SID AES.ch2 AES7 TL7 NID2 CH.td1) Техническая информация дешифруется закрытым ключом клиентской ноды RSA1. После дешифровки вновь можно заметить отличия. 2 - 1 байт. Метка указывающая на то, что данная нода является клиентской и блок данных нужно вернуть клиенту отправившему запрос. SID - 4 байта. Идентификатор сессии по которому клиентская нода сможет найти клиента. AES.ch2 - 32 байта. Ключ для дешифровки контрольного хэша полезной нагрузки. AES7 - 32 байта. Ключ для дешифровки полезной нагрузки. TL7 - 2 байта. Указывает сколько мусора добавлено к пакету. NID2 - 1 байт. Идентификатор первой входящей ноды. Нужен для поиска зашифрованного контрольного хэша полезной нагрузки. CH.td1 - 32 байта. Контрольный хэш технической информации. Вычислив SHA256 хэш из 2 SID AES.ch2 AES7 TL7 NID2 и сравнив его с контрольным хэшем CH.td1 нода убеждается, что техническая информация не повреждена. Удалив из блока полезной нагрузки Trash длиной TL7 и дешифровав её ключом AES7 клиентская нода вновь делит полезную нагрузку на 3 блока. Блок данных: 0х190 DL QID AES.c(DCH Data) Блок общей технической информации: NID1 ETDL1 AES6(RSA1(2 SID AES.ch2 AES7 TL7 NID2 CH.td1)) NID4 ETDL4 AES3(RSA4(1 IP5 AES.c NID6 AES.ch6 NID2 AES.ch2 NID4 AES.ch4 NID3 AES.ch3 NID1 AES.ch1 NID5 AES.ch5 AES4 AES5 TL4 TL5 NID5 CH.td4)) NID3 ETDL3 AES2(RSA3(0 IP4 AES.ch4 AES3 AES4 TL3 TL4 NID4 CH.td3)) NID2 ETDL2 AES1(RSA2(0 IP3 AES.ch3 AES2 AES3 TL2 TL3 NID3 CH.td2)) NID6 ETDL6 AES5(RSA6(0 IP4 AES.ch1 AES6 AES7 TL6 TL7 NID1 CH.td6)) NID5 ETDL5 AES4(RSA5(0 IP1 AES.ch6 AES5 AES6 TL5 TL6 NID6 CH.td5)) Блок хэшей: NID5 EHL5 AES.ch5(CH.pl) NID2 EHL2 AES.ch2(CH.pl) NID4 EHL4 AES.ch4(CH.pl) NID1 EHL1 AES.ch1(CH.pl) NID6 EHL6 AES.ch6(CH.pl) NID3 EHL3 AES.ch3(CH.pl) Производим поиск зашифрованного контрольного хэша по идентификатору ноды NID2 и дешифруется при помощи ключа AES.ch2. Вычисляется хэш полезной нагрузки: SHA256(0х190 DL QID AES.c(DCH Data) NID1 ETDL1 AES6(RSA1(2 SID AES.ch2 AES7 TL7 NID2 CH.td1)) NID4 ETDL4 AES3(RSA4(1 IP5 AES.c NID6 AES.ch6 NID2 AES.ch2 NID4 AES.ch4 NID3 AES.ch3 NID1 AES.ch1 NID5 AES.ch5 AES4 AES5 TL4 TL5 NID5 CH.td4)) NID3 ETDL3 AES2(RSA3(0 IP4 AES.ch4 AES3 AES4 TL3 TL4 NID4 CH.td3)) NID2 ETDL2 AES1(RSA2(0 IP3 AES.ch3 AES2 AES3 TL2 TL3 NID3 CH.td2)) NID6 ETDL6 AES5(RSA6(0 IP4 AES.ch1 AES6 AES7 TL6 TL7 NID1 CH.td6)) NID5 ETDL5 AES4(RSA5(0 IP1 AES.ch6 AES5 AES6 TL5 TL6 NID6 CH.td5))) Полученный хэш сравнивается с контрольным хэшем CH.pl. При их совпадение целостность полезной нагрузки не нарушена и пакет обрабатывается дальше. Блок общей технической информации и блок хэшей более не нужны и могут быть удалены из памяти. Далее работы с ними производится не будут. Из блока данных удаляем первые 6 байт. Затем ищем подключенного клиента с идентификатором сессии SID и отправляем ответ от исполняющей ноды вместе с идентификатором запроса ему. То есть клиенту уходит следующий пакет: QID AES.c(DCH Data) д) Обработка ответа из сети клиентом Получив ответ из сети имеющий вид QID AES.c(DCH Data) клиент считывает первые 4 байта QID. Это идентификатор запроса на который пришел ответ. С его помощью клиент находит связанный с этим запросом ключ AES.c в своей памяти и дешифрует пакет. Первые 32 байта - контрольный хэш от данных. Оставшаяся Data - ответ из сети. Вычислив SHA256 хэш из Data и сравнив его с DCH клиент может убедиться, что данные не повреждены и дешифрованы верно. Дальнейшая работа клиента с ответом зависит от ситуации и содержимого ответа. После обработки запроса идентификатор запроса QID и ключ клиента AES.c будут удалены из памяти клиента и QID станет доступен для повторного использования.
  12. Onion Messanger

    75008, так никто и не заставляет мигроровать. Когда-то и аська была верхом совершенства, но потом люди перешли на жабу. И многие, точно также как и Вы, спрашивали, а где преимущества то? Для них аська была всем. Но времена меняются. Относительно преимуществ и недостатков - уже не раз обсуждалось в этой теме выше. Повторяться не вижу смысла. Их много. В этот раз назову полное отсутствие контроля. Хватит?
  13. Onion Messanger

    Приблизительно полтора месяца прошло с последнего обновления концепта. Приблизительно полтора месяца прошло с последнего доната. Многие наверное подумали, что я взял деньги у спонсоров и исчез. Многие давно уже забыли об этой теме. Да и заинтересованность мемберов проектом скатилась к нулю. Я соглашусь с тем, что времени прошло много, но и работы за это время проделано не мало. Новое дополнение под номером 14 уже содержит 41Кб данных и ещё есть что дописать. Не один раз я начинал переписывать дополнение с нуля. Не один раз я пересматривал прошлые варианты концепта в поисках дыр и возможности оптимизации. Но, тем не менее, новое дополнение почти готово. В нем будут затронуты вопросы проверки целостности пакетов, оптимизации луковичной передачи данных, внесены некоторые изменение в работу DANS нод. Также будет очень подробно рассмотрен процесс формирования, передачи и обработки луковичного пакета. Именно последний пункт и займет большую часть дополнения. По факту выхода этого дополнения буду собирать весь концепт в единое целое и переходить к активной фазе разработки (да-да, к разработке кода). Все, кто заинтересован данной темой, ждите новое дополнение ближе к вечеру. И напомню, тему о спонсорской поддержке проекта можно найти здесь тыц
  14. Onion Messanger

    Немного заработался над проработкой алгоритмов обмена луковичными пакетами и забыл посматривать в мою родную тему. А тут уже начали развиваться баталии и дискуссии. Ребят, всем спасибо как за поддержку, так и за критику. Постараюсь вкратце ответить на возникшие вопросы. kerberos, andru1, я соглашусь, что ТОР для обмена сообщениями тоже достаточно хорош. Он замечательно справляется с маршрутизацией пакетов и сокрытием IP пользователей от других участников сети. Но где-то выше уже обсуждалось, что, без наличия центрального сервера, на основе ТОР можно создать только приватный чат между двумя пользователями. ma ponetre, спасибо об информации о RetroShare. Впервые услышал об этом проекте, поэтому раньше сказать о нем ничего не мог. Почитал и надеюсь, что всё правильно понял. RS в своей основе предлагает нам организацию тех же самых приватных чатов между двумя пользователями. А чат сам по себе уже подразумевает наличие двух пользователей онлайн для передачи сообщения между ними. Для передачи писем оффлайн пользователям осуществляется ожидание появления этого пользователя в сети. Но тогда, опять же, оба пользователя должны быть в сети. Как отправитель, так и получатель. Вот в этом и есть принципиальное отличие OnionMessanger от RS. В Onion Messanger оффлайн пользователь получит адресованное ему сообщение даже в случае, если отправитель сообщения уйдет в вечный оффлайн сразу после отправки этого сообщения. Правда есть ограничение на TTL сообщения - 24 часа. Кроме того я немного не понял о видимости IP адресов в сети RS. Ближний круг. Вроде так это называется в RS. Можете рассказать об этом подробнее?
  15. Onion Messanger

    Дополнение 12 к спецификации Onion Messanger: Внедрение гибридного шифрования Это стоило сделать в самом начале разработки концепта, но тогда я как-то упустил этот момент. Поэтому сделаем это сейчас. С этого момента все данные передаваемые по сети буду передаваться зашифрованными симметричным алгоритмом шифрования AES-256. Сгенерированный случайным образом ключ от AES-256 и некоторая техническая информация будет зашифрована открытым ключом RSA и может быть дешифрована только получателем пакета данных. Это изменение касается всех передаваемых данных, включая пакеты луковичной маршрутизации. Идентификатор сессии В принципе никто не запрещает нескольким клиентам соединяться с одной входящей нодой сети с одного IP адреса. И это вынуждает дополнительно оптимизировать процесс общения входящей нодой с клиентами для уменьшения нагрузки как на ноду, так и на клиент. С этого момента при соединение клиента с нодой будет генерироваться случайный идентификатор сессии передаваемый вместе с запросом. Для обеспечение конфиденциальности идентификатор сессии будет вставляться в зашифрованную для входящей ноды часть луковичного пакета так что бы только входящая нода могла знать какому клиенту эти данные передавать, а остальные ноды не могли получить эти данные. При нахождение клиента с указанным в возвращаемом пакете данных IP и идентификатором сессии входящая нода отправит данные ему. Идентификатор сессии SID генерируется входящей нодой к которой подключается клиент и имеет длину 4 байта. У двух разных клиентов подключенных с одного IP адреса не может быть одинаковых SID. При отключение клиента от входящей ноды пара IP-SID будет сохранена на 1 час и не будет выдаваться для других клиентов подключаемых с этого же IP. AES ключ клиента. Шифрование возвращаемых данных Нашелся ещё один момент который следует проработать. Так как входящая нода будет отдавать пакет данных вернувшийся из сети напрямую клиенту отправившему запрос, то эти данные должны будут быть также зашифрованы. Для этих целей клиент будет генерировать и время от времени менять ключ симметричного шифрования AES.c. Данный ключ будет известен ноде находящейся последней в цепи луковичной маршрутизации. С его помощью выходящая нода зашифрует возвращаемые данные добавив к ним MD5 хэш от полученного ключа. Получив ответ клиент будет знать по хэшу ключа каким ключом из доступных следует дешифровать пакет данных. Смена ключа AES.c будет производится автоматически раз в 5 минут. TTL старых AES.c ключей - 15 минут. По истечению 20 минут после генерации AES.c более не будет приниматься клиентом.
×