Независимо от упомянутой проблемы, как правило, рекомендуется включать проверку целостности всякий раз, когда вы шифруете / дешифруете данные.Однако контрольные суммы не очень подходят для этого.Взгляните на алгоритмы Secure Hash, такие как SHA-256 (есть реализации, встроенные в стандартную инфраструктуру криптографии Java).
Теперь вернемся к исходному вопросу ... Для каждого узла лука выВы собираетесь передать зашифрованный «пакет», но этот пакет будет не только включать фактические данные для передачи - он будет включать в себя детали следующего узла, ваш хэш-код и все остальное ... включая любой флаг/ индикация, указывающая, является ли следующий «узел» луковым маршрутизатором или фактическим конечным хостом.Действительно, данные для последнего узла должны будут иметь некоторую специальную информацию, а именно детали фактического конечного хоста для связи.Другими словами, последний узел знает, что лук очищен, потому что вы кодируете этот факт в данных, которые он получает в итоге.
Или, по крайней мере, я думаю, что именно так я и сделаю ...; -)
NB. Шифрование само по себе не так уж сложно, я не думаю, но здесь может быть одна или две тонкости, которые нужно соблюдать.Например, в обычном диалоге между клиентом и сервером одна тонкость, о которой вы должны быть осторожны, - никогда не шифровать один и тот же блок данных дважды одним и тем же ключом (или, по крайней мере, это то, что сводится к блоку исследования)режимы "и" векторы инициализации ", если вы не знакомы с этой концепцией).В одном диалоге клиент-сервер клиент и сервер могут диктовать части вектора инициализации.В луковом маршрутизаторе нужно будет найти какое-то другое решение (в худшем случае, я полагаю, с использованием сильно сгенерированных случайных чисел, сгенерированных одним клиентом).