Вообщем, надо написать программу шифрования и дешифровки текстового файла по аглоритму Цезаря ( сдвиг буквы на несколько позиций.

Вообщем планирую делать так. Хочу взять текстовый файл, брать из него по символу. Получить код-ANSII этого символа, потом сдвинуть этот символ на 5 (ключ) и потом снова по коду востановить полученый символ и записывать в другой файл.

Я не могу вспомнить 2 функции в С. (лето...., просто вылетело из головы) Функции получения кода симола и востановления симола по его коду. Программировать буду на TC3 (пока нет Студии еще  )

И еще, есть ли какие-то ошибки в моих действия по шифрованию?

Нету таких в си. В си символ суть код символа и наоборот.

GriGor1Z, 

Кстати, имхо, можно применить циклический "реальный"(битовый) сдвиг, на n-битов, заданных ключем. Стоийкость практически такая же как у выше написанного алгоритма, только вот жать можно не только текстовые файлы и выглядет лучше. PS Ключ имеет реальное ограничение 0 до 7.

и этим способом можно

О какой компресии идёт собственно речь ? Ведь колличество данных не меняется. Насколько я помню Rot 3 (шифр цезаря) ничего не сжимает. Это же простой шифр с перестановкой. Код на Python,

 на С++ перевести думаю не составит проблем.

может человек описАлся
естественно речь идет не о сжатии

GriGor1Z, 
Нужно понять, что такое указатель и базовые принципы работы с ним.

вот с использованием STL

Хмм... а если исходный символ будет 255-ым в таблице ASCII ? Переполнение... и не однозначное воспроизведение его потом при дешифровке.

Естественно...

Здесь подразумевается криптостойкость, которая не может быть свойством алгоритмов сжатия информации... Извините.

Добавлено @ 14:25 
Кстати... сложение двух целых программно медленне, чем битовый сдвиг.

Ничего не будет  Вроде, 255-го символа в ASCII не существует.
Для char'а соответсвует: х + 5 == х - 5. И если вместо Х подставить 255, то будет соответсвие 255 + 5 == 255 - 5

0xFF, 0FFh.
ИМХО в бинарниках точно имеется.

Да это, то понятно, просто я сначало было подумал о битовом переполнении, но потом понял, что оно ни коем образом не мешает при обратной дешифровке.

В кои-8р это "ъ" кстати. А в cp1251 это "я". 
А так как ascii-8 8 битная, то 255-ого символа в ней не может не существовать.

Это сообщение отредактировал(а) Mayk - 9.8.2006, 15:53

Есть еще пару вопросов.

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

любой файл - последовательность байт на диске
любой байт - число от 0 до 255
соответственно для шифровки
открываешь файл в бинарном виде
читаешь по байту и прибавляешь к нему ключ циклически (т е если байт равер 254, а ключ 10, то новым значением станет 8)

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

'\0' - Конец строки
'\n' - переход

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

Ключ - это число?
Я думаю, что ненамного сложнее ты сделал)

GriGor1Z, 

Чтобы не было не поняток. Информация зашифрованная таким алгоритмом ломается(точнее подбирается ключ) перебором, причем кол-во переборов не больше 255 

Вот-вот,En_t_end, я это же и имел ввиду)))

Всё зависит от цели. Если надо просто скрыть текст от любопытных глаз, то способ достаточен. Например кому нужна твоя переписка с девушкой? А некоторые вещи не хотелось бы, чтобы папа её прочитал. Но если пап - хакер, тогда конечно придётся переходить к более сложным методам.
ПС:
Кстати, если брать не по байту, а по int, то папе придётся 2^32-1 раз перебирать. 

sergej.z, 

ИМХО нет, все равно если щифровать символ ASCII ты его хоть на сколько раз увеличивай/уменьшай получается, что диапазон шифрованного символа от 0 до 255, то есть 255,254 -переборов. Это как по круговой арене бегать, или как 480 градусов в радианы переводить  Из-за мною упомянутого битового переполнения даже ключ вида 4230000 при добавлении его к байту ASCII даст новый байт, в который может влезть число от 0-255, а ключ можно подобрать, хоть и не 4230000, но тоже верный в диапазоне от 1-255.

Добавлено @ 18:55 

Даже если "пап" хакер можно воспользоватся не сложным методом с применением 1-килобайтного символьного кода)  Если у папы нет мощного кластера под рукой и пары деньков, то не сужденно ему прочитать что-либо 

Это сообщение отредактировал(а) En_t_end - 13.8.2006, 18:48

En_t_end, пусть мимо топика, но расскажи(очень уж интересно) про "несложный метод"))

Хм. И то верно 

А можно так:


Вот это уж взламывать будет подольше пап-хакер)))

Pilligrim, 
Вариант с 4-байтами даже для современной домашней машины как орешки щелкать 

Просто интересно стало, если потребуется расшифровать такого рода файл, то организовать перебор вариантов несложно, но как потом програмно определить какие варианты могут быть "человеческим" текстом?  Не слишком весело просматривать даже 2^32 фрагментов (только для int) 

поидее самый простой способ. 

En_t_end, это я просто со сложением сказал. Пусть сделает по какой-л. формуле: синусы, косинусы. Выбор огромен. И взламывать будет дольше. Тем более, что после записи в файл out, можно еще и побитовую инверсию, провести,а может и или/и. Еще раз повторю:  Выбор огромен.

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

PS:
А если ещё и не знаешь, на каком языке шифровка....

 

Сорри. Ответил на уже закрытый вопрос.   

Это сообщение отредактировал(а) bsa - 13.8.2006, 22:24

Иными словами в шифрованном файле будет не более 256 уникальных значений int'а (а реально даже меньше).


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

хинт для  расшифровки Υ в Χ   (имея преобразованный файл и не имея алгоритма преобразования X в Y). 
наиболее часто встречащаяся буква навряд ли будет твердым знаком. 
Таблицы показывающие вероятность появления каждой буквы в тексте можно или найти в сети, или получить самостоятельно, подсчитав кол-во букв в вашей любимой книге 'Война и Мир'.

хинт для расшифровки Υ в Χ (имея алгоритм и зашифрованный текст)
шифруем 'абвгдеёжзи...юяАБВГД...Я' и получаем таблицу соответствий русских букв и шифрованных букв. Далее дело техники.
Хотя бы tr'ом прогнать.  

Вообще, я имел в виду случай такого рода  (моя вина - не пояснил)


и по-моему, здесь будет порядка 256^sizeof(int) вариантов перебора, и то при условии, 
что мы знаем о представлении каждого символа sizeof(int)  байтами. 
Возможно я ошибаюсь, поправте меня если так.
 
P.S.         С En_t_end я полностью согласен.

Не в тему, но пускай здесь будет, а то код потеряется  в дебрях моего ЖД. Простенький алгоритм. Для данного алгоритма если длинна ключа>=длине длинне текста, расшифровать его будет невозможно ничем. Правда конечно надо один и тот же ключ как можно реже использовать.

Возникло пару вопросов по поводу вот последнего кода, который скинул sergejzr.

Объясните пожалуйста, непросвещённому, как работает функция  encode, а конкретнее, как работает 10-я строка? Там знак "^", что он делает, и почему при кодировке какие-то символы странные берутся? Ну, а если, опишите функцию немного подробней, буду оч благодарен.

И вообще, это всё ещё шифр Цезаря, или что?

Это оператор XOR - побитовое сложение. И это уже не Цезарь. Цезарь легко взломать, a XOR при достаточной длине ключа- невозможно.
Поэтому и символы "странные" т.к без правилъного ключа шифровка может быть чем угодно.

sergejzr, если не имеется в виду применение одноразового блокнота, то XOR - игрушечный алгоритм. Цитата из Брюса Шнайера: "Конечно, алгоритм XOR может помешать вашей младшей сестре прочитать ваши файлы, но настоящего криптоаналитика он задержит лишь на несколько минут"

Ln78, читайте внимательней

Т.е 


Добавлено через 10 минут и 22 секунды
А как ломать XOR описано здесь http://forum.vingrad.ru/index.php?showtopi...st&p=214032
В принципе, ключ с длиной 1/2 мессаги ещё достаточно надёжен.

sergejzr, меня немного смутила категоричность Вашего предыдущего поста о невозможности. Прочитав ссылку, понял Вы понимаете, о чём говорите. А с уточнением о необходимой длине и равновероятности гаммы - получаем именно одноразовый блокнот.