Вопрос про криптуху и AES / RSA.

считается ли такой способ ответа на вопрос «Алиса ли прислала строку» мало-мальски вменяемым? В чём уязвимости?

Зависит от схемы шифрования «Алиса передаёт зашифрованную строку Бобу. Боб расшифровывает её ключом К, вычисляет хеш от строки (кроме поля ) и сверяет вычисленный хеш с полем» – ты ее не описал.

На второй вопрос ответ аналогичный – ты алгоритм шифрования не описал.

Теоретически анализировать можно только конкретный алгоритм, который включает в себя и алгоритм формирования ключа. Практически – нужно еще анализировать программную реализацию.

PS: если ты хочешь DSA, то используй соответствующие алгоритмы, например, из семейства ECDSA, считается, что они дают большую надежность чем, RSA DSA с той же длинной ключа.

Начнем с того, что AES бывает разный. Если это ECB, тут есть большие сомнения в надежности этой схемы. И не понятно зачем все это изобретать, если есть GCM режим который достаточен без всяких плясок с хешом, рандомом и всем таким.

Если речь о RSA, то твое сообщение туда банально не влезет.

Вопрос не очень понятен, требуются пояснения.

Алиса шифрует эту строку каким-то симметричным AES128 или RSA

Если это присутствует, то какие в этом ты видишь проблемы и что даст:

Алиса формирует строку вида:
<HASH>-<TIME>-HELLOWORLD-<SALT-64>

для начала стоит определиться - RSA или симметричный AES.

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

в случае с RSA - это набор из публичного и приватного ключей. в этом случае алгоритм будет такой… боб генерит пару RSA и отправляет публичный ключ алисе. она шифрует им сообщение и отправляет бобу. он расшифровывает приватным ключем сообщение. но тут засада на длинну шифрованного сообщения. там лимиты (не помню, смотри «зы»)

но… RSA - дорогой способ шифрования. поэтому используют связку RSA+AES. а именно, рса - для обмена симметричным ключем аес, а потом уже шифруют им все передаваемые сообщения

зы https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D1%82%D0%BE%D0%BA%D0%BE%D0%BB_%D0%94%D0%B8%D1%84%D1%84%D0%B8_%E2%80%94_%D0%A5%D0%B5%D0%BB%D0%BB%D0%BC%D0%B0%D0%BD%D0%B0

Зависит от схемы шифрования «Алиса передаёт зашифрованную строку Бобу. Боб расшифровывает её ключом К, вычисляет хеш от строки (кроме поля ) и сверяет вычисленный хеш с полем» – ты ее не описал.

«Алиса передаёт зашифрованную строку Бобу» - это не схема шифрования, это просто байтики переслать по открытому каналу.

вычисляет хеш от строки (кроме поля ) и сверяет вычисленный хеш с полем» ты ее не описал.

Не описал что, конкретный алгоритм хеширования? Возьмите любой, устойчивость которого вам нравится.

Если это присутствует, то какие в этом ты видишь проблемы и что даст:

Не понял вопроса.

для начала стоит определиться - RSA или симметричный AES.

Спасибо, ошибка. Я нагнал про RSA, он тут ни при чём. Вычеркнул его. Речь о симметричных алгоритмах.

Если это ECB, тут есть большие сомнения в надежности этой схемы.

Речь про CBC скорее. Или РСВС.

Давайте по-русски: «алгоритм, шифрующий строку любой длины в строку такой же длины, шифротекст после чего выглядит как максимально рандомные байтики, не поддающиеся расшифровке без ключа и по статистическим характеристикам которых невозможно определить никакие характеристики исходного текста». То есть, по-тупому говоря «какой-то надёжный блочный симметричный алгоритм».

В чём сомнения?

Если CBC, то что с вектором инициализации?

Зачем это знать? Это вообще не касается идеи алгоритма.

Вопрос в том, что ты хочешь сделать?
Тут за тебя уже некоторые пытаются додумать, но это ненужно.
Если ты зашифруешь, исходное сообщение надежным и не имеющим уязвимостей на текущий момент, симметричным алгоритмом, то зачем все остальное и что это даст?

Я же всё расписал… Смысл треда в 2 вопросах, которые были заданы в стартовом посте. И все.

Тогда убейся ап стену, забанься и в биоректор, ты потратил время кучи людей, а сам не понимаешь чего ты хочешь и не можешь ответить ни на один вопрос.

Это уже платная услуга.

И сколько ты готов за это платить?
В любом случае, дешевле будет обратиться к практикующим врачам, чем пытаться это сделать это на лоре.

судя по описанию, тебе нужно аутентифицированное шифрование (AEAD). Не нужно придумывать велосипеды, для этого уже есть стандартизированные алгоритмы. AES-GCM, если его поддержка есть в железе. Если нет, то ChaCha20+Poly1305.

забавно, что про это написал ровно один юзер в теме. Чем тут занимаются остальные - ХЗ

А криптуха из разнорыбицы? ТС судя по его топикам любит приправлять грибочками.

алгоритмом, типа AES, используя Ключ К. Ключ К - сгенерированные ранее и сохранённые рандомные 512 байт

У AES длина ключа 128, 192 или 256 бит.

Нет, ему в принципе надо почитать про encryption modes, протоколы и первое правило шифрования.

забавно, что про это написал ровно один юзер в теме. Чем тут занимаются остальные - ХЗ

Тупорогий ТС так сформулировал вопрос, что я только после твоего сообщения понял чего он хочет.
А так да, за попытку велосипедостроения в криптографии, нужно жестко карать.

1. я считаю вполне можно сказать что именно Алиса прислал, если хэш сошелся
2. без хэша не понять что именно HELLOWORLD было отправлено

Еще как касается. IV должен быть разным каждый раз, и его надо как-то передавать. Так что это должно быть частью твоего протокола.

<TIME> - текущее время, нужное тут низачем, кроме как влиять на значение и внести немного рандома, ну и отчасти показать свои часы.

Если всё-таки нужно время сообщения, то оставить, иначе - выкинуть.

Ну, например, что не слишком в прошлом.

Боб доверяет Алисе? А то она любое время в сообщении нарисует.

считается ли такой способ ответа на вопрос «Алиса ли прислала строку» мало-мальски вменяемым? В чём уязвимости?

нет, потому, что я могу взять зашифрованную строку и («вскоре») послать её ещё раз, не расшифровывая.

Будет ли это работать?

посмотрите, как challenge-response протоколы устроены. не надо изобретать.

судя по описанию, тебе нужно аутентифицированное шифрование (AEAD). Не нужно придумывать велосипеды, для этого уже есть стандартизированные алгоритмы. AES-GCM, если его поддержка есть в железе. Если нет, то ChaCha20+Poly1305.

забавно, что про это написал ровно один юзер в теме. Чем тут занимаются остальные - ХЗ

Да, нужно аутентифицированное шифрование. Но это широкий класс готовых взрослых решений. И суть моего вопроса не столько в шифровании, сколько в голимой аутентификации «токена». Хотелось бы услышать критику именно по моему алгоритму, когда берётся указанная строчка, шифруется извечтным обоим людям ключом и проверяется на приёмнике.

У AES длина ключа 128, 192 или 256 бит.

Это «внутренний ключ» - ключ для шифровального блочного многораундного ядра. Он является производным от какого-то внешнего ключа/пароля и т.п. Вы же не всегда вводите пароль 128, 192 или 256-битный, а вводите любую строку. Вот мой 512-байтный ключ - это и есть пароль, от которого мы потом как-то делаем производные 128 бит.

Умники в треде, не отвечающие на поставленные вопросы по любым причинам («автор - дебил», не умеет формулировать, потому что Я только с четвёртого раза понял (а может ты дебил, что по 4 раза читаешь и понять не можешь?), либо «автор дебил, потому что изобретать своё шифрование - признак гидроцефала»), вы унылы и не интересны, ибо все паттерны тролления, самоутверждения и прочитанных где-то в интернете мудростей про криптографию, которые вы тут несёте, - давно известны и не новы. И без вас понятно, что изобретать своё шифрование - плохо. Задачи «не делать плохо» вообще не стояло, допускается просрать вообще все полимеры.

Еще как касается. IV должен быть разным каждый раз, и его надо как-то передавать. Так что это должно быть частью твоего протокола.

Почему недостаточно считать, что IV берётся из первых N бит ключа /etc/mykeyhahaha? Кажется, что это настолько неинтересная деталь, что тут достаточно ответить «у меня какой-то нормальный никому заренее неизвестный кроме алисы и боба IV», нет?

нет, потому, что я могу взять зашифрованную строку и («вскоре») послать её ещё раз, не расшифровывая.

Да, это так. Вот отличненько, практически первая конструктивная критика в копилку)

посмотрите, как challenge-response протоколы устроены. не надо изобретать.

Давайте чуть буквальнее. Вы тут хотите указать на то, что Алисе желательно сначала принять от Боба какую-то строку-рандомчик (челлендж), которую формирует Боб (и возможно как-то непросто), которую (строку рандомчик) Алиса должна «вшить» в токен (где-то после HELLOWORLD). Причём, для начала сойдёт даже просто какой-то тупой рандом, который Боб сохранил в ОЗУ и может потом проверить, что он её генерировал.

Да, спасибо. Это годная критика, <TIME> очень тупо: требует доверия Алисе и непонятно какой несёт функционал вообще. К тому же можно посылку от Алисы просто скопировать и повторить в Боба ещё раз и это проканает. Нужен челлендж от Боба.

Нет, IV нельзя переиспользовать. На каждое новое шифрование должно быть новый случайный IV.

Нужен челлендж от Боба.

Для простейшей защиты от replay attack челлендж от Боба не нужен, достаточно добавить в протокол номер сообщения, который Алиса будет увеличивать с каждой отправкой, а Боб будет проверять, что новое сообщение имеет номер больше последнего обработанного.

Да тоже верно. Но у меня Алиса тупая и не переживёт значение счетчика при ребуте… Можно выдавать на старте конечно от Боба, да)

Тогда, Алиса может генерировать уникальный идентификатор сообщения(например GUID), а Боб хранить идентификаторы всех обработанных сообщений.
Но в этом случае порядок сообщений от Алисы уже не гарантировано будет оригинальным, что в определенных случаях тоже может быть уязвимостью.

А почему бы не переиспользовать, учитывая random байтики в начале каждой моей посылки? Они ведь будут корёжить всю цепочку блоков за собой.

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

Я вообще не понимаю зачем все это. Если цель чисто аутентифицировать отправителя, то достаточно просто HMAC-SHA256. Если нужно еще и скрыть контент (который имеет сомнительную ценность в данном случае), то есть AES-GCM.

Ослабляю неслучайным IV потому, что не знаю как Боб узнает IV Алисы.

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

Если все проверки - true, тогда Боб делает вывод, что строка пришла от Алисы, а не кого-то другого.

если Бобу удалось расшифровать сообщение - очевидно что оно от Алисы. ибо по условиям задачи ключ есть только у Алисы и у Боба.

если Боб не верит Алисе и считает, что она может слить всю хурму кому угодно - тогда заявленное решение не работает.

обеспечить защиту от MITM, который будет спамить повторами сообщений, это вопрос из другой оперы.

Да, кажется всё так.

Ослабляю неслучайным IV потому, что не знаю как Боб узнает IV Алисы.

IV надо просто передать вместе с шифрованным текстом в нешифрованном виде. Его не нужно прятать, он не является ключем. Главное чтобы каждая операция шифрования стартовала с нового случайного IV.

Как минимум нет защиты от replay атаки.