А во втором случае — и если есть возможность сговора, то задача неразрешима.
Предположим такой алгоритм существовал бы. Тогда все участники группы кроме одного, после вычисления среднего балла могли бы сговориться, и вычислить по этому же алгоритму также и свой средний балл. Зная общий средний балл, и средний балл группы без одного человека — можно вычислить средний балл этого одного человека.
Но:
* размер шрифта меняется какими-то крупными скачками, не подобрать подходящий
* начертание шрифта странное, как будто он полужирный
* Там, где были переводы строк в исходном документе — вставляются принудительные переводы строки (хотя на экране)
Случая с растровыми страницами сложнее, и я его не рассматриваю. PDF текстовый, текст оттуда копируется, но нужно, сохранив структуру документа и форматирование, избавиться от принудительной разбивки по строкам и страницам (A4).
Сказал, что придумывать опасно, но не могу удержаться от ещё одного варианта:
1. Клиент генерирует случайный большой ключ X. Отсылает его серверу (шифруя глобальным общим ключом)
2. Сервер генерирует случайный большой ключ Y. Отправляет его клиенту (шифруя глобальным общим ключом)
3. Клиент посылает запрос, шифруя его ключом concat(X, Y)
4. Сервер посылает ответ, шифруя его ключом concat(X, Y)
Тут replay-attack не работает, потому что каждая сторона сама генерирует часть ключа сессии, и поэтому concat(X, Y) каждый аз будет разным.
Если враг подменит X или Y, то общий ключ не будет выработан.
@KLUBS
Просто подписи (которая кстати если есть шифрование не обязательна) и шифрования недостаточно из-за replay attack. Чтобы решить эту проблему нужно использовать что-то генерируемое случайно с обоих сторон, или использовать timestamp (но возня с timestamp мне не кажется надёжной).
Велосипеды придумывать опасно, так что лучше найти «канонические» решения этой проблемы и найти их в реализованном виде на нужных языках или аккуратно закодить самому.
Как гарантировать одноразовость токенов? Сервер может её гарантировать (условно) потому что токен большой и генерируется случайно.
А клиент? Он должен хранить все использованные ранее токены и проверять чтоб не было повтора? Это нереально, тем более если клиент запускается не с одного ПК. Если он не хранит использованные ранее токены, то возможен такой поворот событий:
1. Отсылаем запрос на получение токена.
2. Сервер генерирует токен, который шифрует ключем знакомым клиенту и отправляет клиенту. (злоумышленник сохраняет шифрованный ответ)
3. клиент посылает запрос, шифруя токеном
4. сервер посылает ответ, шифруя токеном (злоумышленник копирует шифрованный ответ себе)
5. клиент хочет послать ещё запрос, посылает запрос на получение токена
6. злоумышленник отвечает ему сохранённым в пункте 2 ответом
7. клиент посылает запрос (злоумышленник может сравнить этот запрос с запросом из пункта 3, и сравнивая их на равенство может получить какую-то дополнительную информацию)
8. злоумышленник отвечает ему сохранённым в пункте 4 ответом
Токен использован дважды, ответ сервера подменён, клиент ничего не заметил, злоумышленник торжествует.
Или приложение спрашивает: «Какой у меня сейчас баланс?». Злоумышленник перехватывает ответ сервера (не расшифровывая его), и возвращает этот ответ на все последующие запросы приложения. Таким образом приложение будет думать что всё ок, но это не так. Хотя описанная схема от такого не защищает, для этого нужно привязывать ответ к конкретному запросы, например используя случайный id запроса и указывая его в ответе.
Но это всё велосипеды, SSL бы от всего описанного защитил бы, нужен аналог, но который можно реализовать на уровне PHP.
А если запросы не только GET? Если запрос вида «перевести 100$ от пользователя A к пользователю B»? Злоумышленник сохранит это запрос, и спустя час повторит.
Кажется мне, что AES не защитит от клонирования злоумышленником легитимных запросов. Там нет ни рандомизированной установки соединения (как в SSL), ни timestamp-ов с проверкой на повторы, как описано по ссылке топикстартера.
Насчёт аутентификации — по Вашей ссылке всё описано.
md5 гарантирует, что запрос отправлен тем, кто знает api_secret, без него контрольную сумму не составить
Что должен делать сервер:
* получить запрос
* вычислить sign, сравнить его с переданным, если не совпадает вернуть «Incorrect signature.». Это гарантирует, что запрос отправлен вышей программой, т.к. только она могла создать правильный sign.
* проверить, что переданный timestamp отличается от текущего времени на сервере не более чем на 100 секунд, если это не так — то вернуть «Invalid timestamp.». Это защищает от того, что злоумышленник перехватит запрос подержит его у себя часок, и начнёт посылать его много раз подряд.
* Проверить, что за последние 200 (= 100 * 2) секунд не было запроса с таким же sign. Защита от повторов. Использованные sign необходимо хранить в служебной таблице в течение минимум 200 секунд. Нужно для защиты от дублирования злоумышленником запросов.
Эти пункты гарантируют, что будут обрабатываться только запросы от авторизованной программы (которая знает секретный ключ), ключ не может быть перехвачен злоумышленником, слушающим трафик, и запросы не могут быть клонированы злоумышленником.
Защищать передаваемые данные можно любым шифрованием, но проще всего SSL.
