Сами криптоалгоритмы никаких признаков целостности не проверяют и контрольных сумм не хранят. Это абсолютно справедливо для (X)TEA, AES, Blowfish, RSA, RC4 — это то, с чем я работал. Думаю, для остальных тоже справедливо. Довески — продукт софта типа pgp или WinRAR :-)
У вас данные где-то хранятся, я предполагаю что в некоторой таблице, но это не важно. Просто есть четкая связь между хэшем и зашифрованными данными. По условиям задачи злоумышленник получает доступ к этой информации. После этого он засылает в сервис открытый текст длиной 1 байт, блочный алгоритм этот 1 байт «расширяет» до длины своего блока. Для проверки засылаем открытый текст длиной в предполагаемую длину блока и видим, что длина осталась той же, значит длина блока установлена. Это позволяет установить нижнюю и верхнюю границы длин исходного текста (отличаются они не более чем на blocklen). Наличие хэша на процедуру вообще никак не влияет, но установление длины (диапазона длин) открытого текста может упростить перебор хэша.
Допустим, у нас хранится хэш текста и он же, зашифрованный AES256. Злоумышленник может сделать несколько записей в таблицу с произвольным текстом, следовательно он поймет, что длина блока — 16 символов. Далее, имея неизвестный зашифрованный текст и его же зашифрованным, можно ограничить перебор 16-ю вариантами длины, а не всеми длинами меньше длины зашифрованного текста. Чем меньше длина блока шифрования, тем меньше диапазон длин текста для перебора.
А, а еще лучше — pcap-файл, который был получен при посещении страницы и появлении на ней левой инфы. Оно ж там через 2-3 промежуточных запроса работает.
Хороший код, до боли знакомый :-) В общем, есть подозрение что от выбросов избавиться не выйдет — ОС так работает. Попробуйте осциллом ткнуться, если на осцилле все ровно, а в винде время сильно плавает — винда виновата.
Да даже цифровой не нужен: в цикле гоним с винды сообщения, приемник при приеме ножку вверху, после конца передачи — вниз. Нормально синхронизацию на аналоговом выставить — сразу и минимальное и максимальное время будет видно :-)
Два столбца из 11 у вас будет расшифровано. Потом — знанием русской езыки, тут другого варианта я не знаю :-( Должны получиться сочетания «Л… К» и «О… У». Собственно, количестве букв между Л и К сильно ограничено, учитывая, что ключ должен дать осмысленную букву между О и У. Если там будет любая гласная — значит, предположение о первой неверно.
Повторяю: педивикия какбэ говорит нам, что надо бить текст на куски по 11 символов. Записываем их один под одним. Получаем СТОЛБЦЫ в которых уже можно частотный анализ проводить, так как каждый n+k*keyLen символ зашифрован одинаковым ключегом. А учитывая, что в одном столбце будет три ОДИНАКОВЫХ буковки и что самая частая буква в русской езыке — буква О… Во другом столбце тоже 2 или 3 раза та же сама буковка. А когда вы получете сочетание Л… КО, что в пропуске?
Я вот даже удивляюсь: я получил осмысленные фрагменты, а вы утверждаете, что они не верны. Так не бывает. Тем более что получил я их не на первом наложении ключа.
Ну вот что за люди, а?! Ну зачем вам криптография, если вы не можете даже частотный анализ сделать?! Даже мерзкая педивикия говорит: разбивайте текст на строки длиной «длинаключа». Потом в одном столбце нормально проводится частотный анализ. Я щаз в зюзюку бухой и ключ все равно не вспомню, но оно вскрываемо. Если даже я ошибся с ключегом, я его восстановлю и там будут осмысленные фрагменты текста.
Как правильно пишут в буржуйских книгах по криминалистике: снять образ, а потом играться с ним сколько влезет. Переустановка для сервера — единственно верное решение, я бы не был уверен в том, что вычистил совсем все.
