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



ЗЫ: Функция вернет шифрованное значение строки s по паролю Password при первом вызове, и разшифрованное при повторном, если передать результат первоначального вызова функции и тот же Password.

Ну, примерно на уровне того, как и устойчивость логина/пароля admin/admin 
К тому же, как я тебе уже сказал в другой теме, ты теряешь часть данных при криптовании:

ReFrehH, 

Да хоть сколько большая - все равно используешь лишь последний символ. (Вскрывается в течении нескольких секунд)

А вообще: 
1. не пойму - почему на выходе строка (там будет набор из всех 255 значений для одного байта), лучше выдавать byte[]. Да и вообще оперировать бинарными операциями для символов как-то, имхо не очень.
2. xor - это не функция шифрования, это просто обратимая операция, которая используется для наложения шифро гаммы на открытый текст. Она используется практически во всех современных блочных симметричных алгоритмах шифрования.
3. даже если и сделать так, чтобы гаммирование проходило нормально (накладывался не последний символ password, а последовательно все) все зависит от переданного значения password. Но, что то я сомневаюсь что все коды символов этого password будут равномерно и случайно распределены, что password будет при каждой передаче данных новый и что его длина будет большой. -> система имеет плохую криптостойкость.

Советывал бы в топку.

Это сообщение отредактировал(а) Alexandr87 - 6.1.2008, 07:18

Кстати, да. В приведённом коде для каждого символа строки выполняется цикл "шифрования" по каждому символу пароля. Но! Из-за  происходит потеря результата всех итераций, кроме последней. В общем, алгоритм можно сильно ускорить (особенно на длинных паролях) за счёт исключения второго цикла. 

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

подобное можно использовать. например, в армии: в мирное время по надёжному каналу передаём жутко длинный пароль, а при необходимости в сложные времена, когда надёжный канал недоступен, передаём сообщение с использованием этого пароля

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

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

Добавлено через 51 секунду
P.S.
код не смотрел, всё, что написал, относится к корректной реализации 

ну тут уже нужно рассматривать генератор, с помощью которого была сгенерированна шифр-гамма.

+ повторное использование данной шифр-гаммы становится невозможным.

да, спасибо, вариант с int решил проблему).

Alexandr87,


Точно, как я мог не заметить))

Дело в том что работать приходится со строками.

Да, под функцией я не имел ввиду операцию xor, а именно последовательное наложение всех символов password'a, то что ты упоминаешь в след. пункте...

а если предположить:
последовательное наложение с учетом позиции каждого символа в password'е;
случайную генерацию password'a при каждом новом сеансе связи;
длинну password'a меньше длинны сообщения - ?

при использовании, например, таким образом : 


Это сообщение отредактировал(а) ReFrehH - 6.1.2008, 16:09

эквивалентно простой замене.
вскрывается за несколько секунд с любой длиной password`а

Я не понимаю, что вы хотите изобрести?


Это сообщение отредактировал(а) Alexandr87 - 6.1.2008, 16:36

Можно чуть подробнее? я чего то явно недопонимаю. :(



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

Хотелось бы услышать пример такой ситуации.


А ради чего каждый символ строки криптуется всеми символами пароля? Ну, стал алгоритм чуть сложнее и явно медленнее, но криптостойкость увеличилась ненамного. Скажем, на одну миллирдную   
От пользователя защитит, а если дать хакеру - раскусит довольно быстро и даже огорчится от этого. 

Вообще я хочу спросить:
Для чего тебе риптование?
Насколько важные данные?
Что важнее - не дать расшифровать вообще или не дать расшифровать быстро? (первое в принципе неосуществимо для обратимого шифрования, а необратимое вряд ли кому-то нужно  ).
От кого криптуешь?
Каков усреднённый объём данных?

Добавлено через 7 минут и 21 секунду

Ну, тогда используй сдвиг символа в алфавите (надеюсь, базовые понятия из криптографии имеются? хотя учитывая надежду на XOR... в общем алфавит - это набор символов, из которых состоят твои сообщения). Величину сдвига бери из генератора псевдослучайной последовательности. Для расшифровки хватит иметь шифровку и значения для инициализации генератора. Кстати, XOR вместо сдвига тоже подойдёт - каждый символ ксорить по новому числу из генератора.

скажем так. Криптостойкость не увеличилась, а уменьшилась. Вернее стойкости не осталось.


Попробуйте зашифровать в вашей программе строку "abcabc"  с любым ключом. Думаю многое станет ясным. 

Если не стало:
в каждом цикле у вас делается следующее
message[i] ^ key[0] ^ key[1] ^ ... ^ key[n]

Как видите key[0] ^ key[1] ^ ... ^ key[n] есть постоянно.
Каждый символ строки вы ксорите с одним и тем же числом. В результате одинаковым символам открытого текста соответствуют одинаковые "символы" шифртекста. Разным - разные. Далее - частотный анализ на закрытый текст и получаете открытый текст.

ЗЫ. ну и совет - не стоит парить себе моск. Возьмите готовые реализации шифров.

Это сообщение отредактировал(а) Alexandr87 - 6.1.2008, 17:03

в попытке повысить стойкость, но видимо ... 


не очень удачная мысль 


для передачи данных  по сетке

Не сказал бы что очень, но хотелось бы шифровать достаточно стойко.

, согласен, но чтоб расшифровка заняла время больше и пока инфа, например, потеряет актуальность...

сложный вопрос 

В среднем строка длинной 200-300 символов.

Если

то


Зачем изобретать очередной велосипед с квадратными колёсами если их и в нете полно?

Это сообщение отредактировал(а) nornad - 6.1.2008, 17:16

Спасибо за объяснение; совет конешно дельный, только я не смог найти java реализацию свободного для использования алгоритма, может что то порекомендуете  ? (тольк не применяя javax.crypto.*, т.к. работать приходица с J2ME)

о, это вообще приятный метод
представим двух людейв толпе, кричащих друг другу что-то
первое впечатление - ничего секретного передать нельзя
но есть один способ:
выбирается общее большое простое число p (оно известно всем, и подслушивающим тоже)
выбирается общее основание e (тоже всем известно)
потом первый человек загадывает число a (известно только ему) и кричит второму число e^a
получается, что e^a известно всем, а вот a - нет, т.к. взять логарифм быстро не получится (разве что перебором)
второй человек слушает e^a, загадывает b и кричит e^b
получается такая ситуация:
первый знает a, e^b
второй - b, e^a
толпа вокруг знает e^a и e^b
так вот оба человека могут посчитать e^(a*b):
первый - как (e^b)^a
второй - как (e^a)^b
а вот толпа посчитать его не может

а теперь эти люди могут использовать битовое представление e^(ab) для кодирования (например, xor) своих сообщений
т.е. в данном случае есть канал для синхронизации - получения одинакового пароля на обоих концах, и его можно назвать защищённым, но люди не могут контролировать, что именно получится в результате, поэтому по этому защищённому каналу само сообщение передать не получится...

я знаю только о двух уязвимостях:
1. нужно как-то быть уверенным, что ты говоришь именно с тем, с кем думаешь, а не с кем-то, кто притворяется
2. (тут уже упоминалось) нужен качественный генератор случайных чисел для a,b

Я тебе уже рекомендовал.   


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

Добавлено через 1 минуту и 3 секунды

Я упоминал генератор псевдослучайных чисел.

bouncycastle.org
есть версия, работающая на j2me. 

Спасиб, уже разбираю )

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


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