LINUX.ORG.RU
решено Форум — Development  

Целостность данных

 ,


0

1

Задачка Есть три человека Я посредник Оппонент

Я через посредника передаю сообщение оппоненту. Оппонент должен определить не подменил ли посредник это сообщение. Связь односторонняя. Оппонент не может мне ничего сообщить о принятом сообщении.

Высокая криптостойкость не требуется. Посредник не будет взламывать шифр он просто может рандомно испортить передаваемые данные. Ему можно даже говорить открытое сообщение.

В конечном итоге нужна защита от порчи данных посредником без обратной связи с оппонентом.

Все условия

1. Я и оппонент не имеем обратной связи. Все сообщения передаются от меня через посредника в один конец

2. Мы оппонентом знаем все алгоритмы шифрования, ключи, пароли, явки.

3. Оппоненту не обязательно получать правдивые данные. Достаточно того, что он будет знать об их повреждении. Но было бы не плохо если бы он мог их восстанавливать.



Последнее исправление: Maksimko (всего исправлений: 2)

Для этого придумали ЭЦП, а как реализация механизма хорошо подойдёт jwt.

vvn_black ★★★★★
()
Последнее исправление: vvn_black (всего исправлений: 2)

Вот, возьмите ,,,, запятые, пригодятся, посредник-оппонент Вы наш.

anonymous
()

Зависит от того, может ли посредник их злонамеренно изменять или нет.

Если может то варианты ЭЦП, если нет то хватит любого хеша (типа md5).

Deleted
()
Ответ на: комментарий от Harald

что мешает посреднику пересчитать твоего Рида-Соломона для поддельных данных

Посредник .... просто может рандомно испортить передаваемые данные.

anonymous
()
Ответ на: комментарий от Deleted

Вспомнил, ещё стоит почитать про такую штуку как «имитовставка».

Deleted
()

Для этого придумали аутентифицированное шифрование. Из популярных, например, AES-GCM.

gag ★★★★★
()

Цифровая подпись.

Создаётся хэш сообщения, шифруется приватным ключём и прикрепляется к сообщению. Получатель вычисляет хэш сообщения, расшифровывает публичным ключём прикрепленный хэш и сравнивает. Хэши не совпадают - была манипуляция.

invy ★★★★★
()
Ответ на: комментарий от invy

Можно упростить до одного ключа - приватного, как минимум, равного по длине хешу. Приватный ключ известен двум сторонам. И оба шифруют хеш блочными aes или потоковыми шифрами на одном ключе, есессно...

menangen ★★★★★
()

Блин. Заработался и мозги совсем потекли. Я это уже реализовывал неоднократно. А тут как будто по голове стукнули. Админ, можно удалять.

Maksimko
() автор топика
Ответ на: комментарий от Maksimko

похоже коварный посредник подменил и это сообщение

anonymous
()
Ответ на: комментарий от anonymous

передавай просто хэш

а еще лучше подписанный хэш

anonymous
()
Ответ на: комментарий от menangen

Передать ключ другой стороне тоже нужно. Без ошибок (и модификаций со стороны mitm), в итоге сложность только растет. Если ключ получателя скомпромитирован- все накрывается медным тазом. Mitm может все перещифровывать сколько ему угодно.

invy ★★★★★
()
Последнее исправление: invy (всего исправлений: 1)

Если вы с получателем заранее договорились об общем секрете, который неизвестен человеку посередине, то правильный ответ - MAC. Практически, это почти всегда будет HMAC.

Другие варианты - AEAD шифрование, типа GCM и, разумеется, цифровые подписи.

Но если вам нужно реально передавать сообщения, я бы рекомендовал не самостоятельно программировать криптографические примитивы, а взять готовую библиотеку типа NaCl.

ivlad ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Development