Каким алгоритмом зашифровать текстовый файл?
Если серьезно нужно шифровать, а не играться, то лучше никаким алгоритмом не пользоваться. В том смысле, что не надо пытаться реализовывать известные криптографические алгоритмы или, не дай бог, придумывать свой. Лучше взять готовую реализацию. Если дело происходит под Windows, то Crypto API видимо подойдет. Еще можно глянуть на Crypto++ .
почему бы не попытаться реализовать известный криптографический алгоритм?
Как показывает практика, в таких реализациях находится много ошибок и дыр.
В уже существующих их тоже было не мало, но почти все они уже исправлены.
Т.е пришли проверку временем.
В уже существующих их тоже было не мало, но почти все они уже исправлены.
Т.е пришли проверку временем.
Ты не прав...
Если реализация алгоритма правильная - то дыр в ней быть не может, потому как всегда прилагаются тестовые примеры, по которым можно проверить, правильно ли шифрует реализация или нет.
А вообще, открытых исходников с реализациями любых известных криптографических алгоритмов (c/c++) - навалом просто, они обычно легковестные и разобраться в них вполне реально, не сложнее, чем в системо-зависимом api.
Если реализация алгоритма правильная - то дыр в ней быть не может, потому как всегда прилагаются тестовые примеры, по которым можно проверить, правильно ли шифрует реализация или нет.
А вообще, открытых исходников с реализациями любых известных криптографических алгоритмов (c/c++) - навалом просто, они обычно легковестные и разобраться в них вполне реально, не сложнее, чем в системо-зависимом api.
Если не сильно шифровать надо - то как вариант просто пожать файл каким-нить LZH и поверх XOR-нуть...
А зачем? Если для себя, просто из интереса, то это я понять могу, да. Если это нужно по работе, то лично я не стал бы это делать, а прикрутил бы что-то готовое. Потому что считаю, что велосипеды самопальные - гораздо чаще зло, чем добро.
Как показывает практика, в таких реализациях находится много ошибок и дыр.алгоритм шифрования - это однозначная инструкция о том, как шыфровать файл, никаких неоднозначностей и ошибок в ней быть не может.
В уже существующих их тоже было не мало, но почти все они уже исправлены.
Т.е пришли проверку временем.
а зачем писать? чем тот же PGP не пойдет?
А вообще, открытых исходников с реализациями любых известных криптографических алгоритмов (c/c++) - навалом просто, они обычно легковестные и разобраться в них вполне реально, не сложнее, чем в системо-зависимом api.В том-то и вопрос, какой именно заюзать: md5, RSA... ? Это нужно на работе. Программа будет стоять у многих юзеров, а ставить каждому тяжеловесную библиотеку КриптоАПИ не хочется.
Rar'ом запакуй 
Вот ещё есть такая функция прикольная, в юниксе и прога уже написана
CRYPT(3) BSD Library Functions Manual CRYPT(3)
NAME
crypt, setkey, encrypt, des_setkey, des_cipher, -- DES encryption
SYNOPSIS
#include <unistd.h>
char
*crypt(const char *key, const char *setting);
void
setkey(char *key);
void
encrypt(char *block, int flag);
int
des_setkey(const char *key);
int
des_cipher(const char *in, char *out, long salt, int count);
DESCRIPTION
The crypt function performs password encryption, based on the NBS Data
Encryption Standard (DES). Additional code has been added to deter key
search attempts. The first argument to crypt is a null-terminated
string, typically a user's typed password. The second is in one of two
forms: if it begins with an underscore (``_'') then an extended format is
used in interpreting both the key and the setting, as outlined below.
Extended crypt:
The key is divided into groups of 8 characters (the last group is null-
padded) and the low-order 7 bits of each each character (56 bits per
group) are used to form the DES key as follows: the first group of 56
bits becomes the initial DES key. For each additional group, the XOR of
the encryption of the current DES key with itself and the group bits
becomes the next DES key.
The setting is a 9-character array consisting of an underscore followed
by 4 bytes of iteration count and 4 bytes of salt. These are encoded as
printable characters, 6 bits per character, least significant character
first. The values 0 to 63 are encoded as ``./0-9A-Za-z''. This allows
24 bits for both count and salt.
Traditional crypt:
The first 8 bytes of the key are null-padded, and the low-order 7 bits of
each character is used to form the 56-bit DES key.
The setting is a 2-character array of the ASCII-encoded salt. Thus only
12 bits of salt are used. count is set to 25.
Algorithm:
The salt introduces disorder in the DES algorithm in one of 16777216 or
4096 possible ways (ie. with 24 or 12 bits: if bit i of the salt is set,
then bits i and i+24 are swapped in the DES E-box output).
The DES key is used to encrypt a 64-bit constant using count iterations
of DES. The value returned is a null-terminated string, 20 or 13 bytes
(plus null) in length, consisting of the setting followed by the encoded
64-bit encryption.
The functions, encrypt setkey des_setkey and des_cipher provide
access to the DES algorithm itself. setkey is passed a 64-byte array
of binary values (numeric 0 or 1). A 56-bit key is extracted from this
array by dividing the array into groups of 8, and ignoring the last bit
in each group. That bit is reserved for a byte parity check by DES, but
is ignored by these functions.
The block argument to encrypt is also a 64-byte array of binary values.
If the value of flag is 0, block is encrypted otherwise it is decrypted.
The result is returned in the original array block after using the key
specified by setkey to process it.
The argument to des_setkey is a character array of length 8. The least
significant bit (the parity bit) in each character is ignored, and the
remaining bits are concatenated to form a 56-bit key. The function
des_cipher encrypts (or decrypts if count is negative) the 64-bits
stored in the 8 characters at in using abs(3) of count iterations of DES
and stores the 64-bit result in the 8 characters at out (which may be the
same as in ). The salt specifies perturbations to the DES E-box output
as described above.
The function crypt returns a pointer to the encrypted value on success,
and NULL on failure. The functions setkey encrypt des_setkey
and des_cipher return 0 on success and 1 on failure.
The crypt setkey and des_setkey functions all manipulate the same
key space.
SEE ALSO
login(1 passwd(1 getpass(3 passwd(5)
BUGS
The crypt function returns a pointer to static data, and subsequent
calls to crypt will modify the same object.
HISTORY
A rotor-based crypt function appeared in Version 6 AT&T UNIX. The cur-
rent style crypt first appeared in Version 7 AT&T UNIX.
This library (FreeSec 1.0) was developed outside the United States of
America as an unencumbered replacement for the U.S.-only libcrypt encryp-
tion library. Programs linked against the crypt interface may be
exported from the U.S.A. only if they use crypt solely for authentica-
tion purposes and avoid use of the other programmer interfaces listed
above. Special care has been taken in the library so that programs which
only use the crypt interface do not pull in the other components.
AUTHOR
David Burren <werj.com.au>
В том-то и вопрос, какой именно заюзать: md5, RSA... ?В MD означает message digest.
The
algorithm takes as input a message of arbitrary length and produces
as output a 128-bit "fingerprint" or "message digest" of the input.
из RFC1321
Так что MD5 тебе не нужен.
ставить каждому тяжеловесную библиотеку КриптоАПИ не хочетсяCrypto API входит в состав WinAPI и есть на всех современных виндовсах.
Requirements
Client Requires Windows "Longhorn", Windows XP, Windows 2000 Professional, Windows NT Workstation 4.0, Windows Me, Windows 98, or Windows 95 OSR2 and later.
Server Requires Windows Server "Longhorn", Windows Server 2003, Windows 2000 Server, or Windows NT Server 4.0.
Redistributable Requires Internet Explorer 3.02 or later on Windows 95.
Header
Declared in Wincrypt.h.
Library
Link to Advapi32.lib.
DLL Requires Advapi32.dll.
В том-то и вопрос, какой именно заюзать: md5, RSA... ? Это нужно на работе. Программа будет стоять у многих юзеров, а ставить каждому тяжеловесную библиотеку КриптоАПИ не хочется.md5 - это криптографическая хеш-функция, хотя при желании её можно приспособить для целей шифрования (это удобно для какого-нибудь php, где есть уже встроенная реализация, да и вообще, она везде реализована, вплоть до javascript) - лучше, всё-таки, использовать целевые решения.
rsa - это алгоритм для асимметричного шифрования. Там есть очень много тонких моментов, связанных с генерированием ключей и т.п., поэтому если тебе нужны подобные технологии, то лучше брать готовые системы. GPG, например (свободный аналог PGP).
Из симметричных алготирмов - blowfish, AES, 3DES, ГОСТ-28147. Лучше - первые два, а наверное, ещё лучше - AES (у него есть варианты с разной длиной ключа, лучше брать те, что длиннее). 3DES хорош тем, что изготовлен на основе DES, и легко найти реализации. Плох тем, что очень тормозной... ГОСТ плох тем, что для него нужно изготовить "узлы-замен", что сама по себе операция с некоторыми хитростями. Короче, я рекомендовал бы искать реализации AES. У меня - нет, я давно с этими вещами не работал, а когда в последнее время нужно было что-то - использовал md5 нецелевым образом
по ттх, вроде, рулят blowfish и rijndael
В википедии есть куча ссылок на реализации blowfish, среди них есть очень компактные и удобные.
rijndael - вроде бы тот же AES, если не ошибаюсь. То есть AES-ом он стал, после того, как его выбрали (American Encrypting Standart). Могу, конечно, ошибаться, но вроде так.
может быть. я криптографию три года назад сдавал, все могло и переименоваться сто раз
Ты прав.
Тут надо понимать - хочешь ли ты его расшифровывать?
От этого и возникают вопросы о методе и реализации (обратимое кодирование или нет).
При обратимом кодировании проще всего поксорить с одному тебе известным ключом,
равным по длине твоему тексту - получишь невскрываемый шифр (при нормальном выборе ключа
, например, хорошей случайной последовательностью).
От этого и возникают вопросы о методе и реализации (обратимое кодирование или нет).
При обратимом кодировании проще всего поксорить с одному тебе известным ключом,
равным по длине твоему тексту - получишь невскрываемый шифр (при нормальном выборе ключа
, например, хорошей случайной последовательностью).
1)Кодирование должно быть обратимым
2)Насчет XOR бред
У меня есть текстовый файл. Я его шифрую (XOR-ю). Сравниваю шифрованный и незашифрованный файл и получаю ключ в чистом виде.
Кстати, размер файла может быть неограничен, типичное значение - 10-100 мб. Хранить такой ключ проблемно.
2)Насчет XOR бред
У меня есть текстовый файл. Я его шифрую (XOR-ю). Сравниваю шифрованный и незашифрованный файл и получаю ключ в чистом виде.
Кстати, размер файла может быть неограничен, типичное значение - 10-100 мб. Хранить такой ключ проблемно.
давно бы уже GPG поставил и не изобретал велосипед с квадратными колёсами.
1)извини, но если человек уже имеет незашифрованный файл, зачем скрывать от него ключ?
раздавай всем файлы поксоренные разными ключами.
2) ничего лучше XOR в теории шифрования придумано не было. Это еще с времен Шеннона известно, только вот ключ у тебя должет быть качественный. Ну а вообще так бы и писал - ключ должен быть маленьким - для этого случая в треде ответов хватает.
раздавай всем файлы поксоренные разными ключами.
2) ничего лучше XOR в теории шифрования придумано не было. Это еще с времен Шеннона известно, только вот ключ у тебя должет быть качественный. Ну а вообще так бы и писал - ключ должен быть маленьким - для этого случая в треде ответов хватает.
XOR весь файл - это самое невскрываемое, что есть. ключевые слова "одноразовый блокнот".
ключ действительно равен длине кодируемого сообщения.
Это "абсолютно надёжный" шифр.
ключ действительно равен длине кодируемого сообщения.
Это "абсолютно надёжный" шифр.
1)извини, но если человек уже имеет незашифрованный файл, зачем скрывать от него ключ?А ты не думал, что всегда хочется иметь короткий ключ, который, к тому же, можно использовать долго и для большого числа сообщений? Тогда утеря одного документа не повлечёт за собой раскрытия ключа.
раздавай всем файлы поксоренные разными ключами.
2) ничего лучше XOR в теории шифрования придумано не было. Это еще с времен Шеннона известно, только вот ключ у тебя должет быть качественный. Ну а вообще так бы и писал - ключ должен быть маленьким - для этого случая в треде ответов хватает.Все эти одноразовые ключи представляют исключительно теоретический интерес (а по большому счёту и теоретического интереса не представляют). Проблем из-за них столько, что проще вообще тогда не шифровать, а действовать "административными мерами".
Обсуждается вполне бытовой вопрос, как хранить данные в шифрованном виде, и понятно, что готовые системы для этих ситуаций непригодны. А уж про одноразовые ключи я вообще молчу. По-мойму, постановка вопроса была сформулирована вполне понятно...
PS: Если возвращаться к теме - то важен и другой момент, режим использования алгоритма. Использовать простой ECB (поблочная замена) нельзя, так как опасно, режим "гаммирования" тоже плох, более извращённые режимы - имеют свои минусы при работе с большими файлами (например, когда нужно считать что-то из конца файла). Есть одно интересное решение, которое хотя и требует двух вызовов функции шифрования вместо одного, но зато решает многие проблемы. Пусть у нас есть TEXT(i) - множество блоков, которые нужно зашифровать. Тогда шифруется по формуле
CRYPT_TEXT(i) = Crypt( TEXT(i) ) XOR Crypt( Gamma(i)
где Gamma(i) - некоторая открытая (известная) функция от i.
До тех пор, пока ты внятно не объяснишь чего тебе надо и какие задачи стоят перед тобой, тебе никто реально не поможет.
А ты не думал, что всегда хочется иметь короткий ключ, который, к тому же, можно использовать долго и для большого числа сообщений? Тогда утеря одного документа не повлечёт за собой раскрытия ключа.Похоже Ты не думал об этом!
Все эти одноразовые ключи представляют исключительно теоретический интерес (а по большому счёту и теоретического интереса не представляют).Вот тут я не соглашусь - сплошь и рядом одноразовые ключи используются в Интернете, но их использование никому не навязывается.
Бытовые вопросы решаются бытовыми утилитами, коих полно в инете.
Что касается PS - никто для чужой выгоды таких протоколов придумывать не будет - за это платятся неплохие деньги.
Так что в приват со своими предложениями заработка...
Вот, про AES, бесплатная реализация, и не GPL при этом... Пока я код поверхностно глянул (суммарный объём исходников 200 кб компилировать не пытался. Можно использовать C реализацию, можно - asm (i386-32).
http://fp.gladman.plus.com/cryptography_technology/rijndael/
http://fp.gladman.plus.com/cryptography_technology/rijndael/
1)извини, но если человек уже имеет незашифрованный файл, зачем скрывать от него ключ?
раздавай всем файлы поксоренные разными ключами.
гениально
1 винчестер с файлами, а второй с ключами - офигенно практично.
ничего лучше XOR в теории шифрования придумано не было. Это еще с времен Шеннона известно,да неужели?
Если понимать слово "лучше" как "больше полезных свойств и не меньше криптостойкость", то трудно придумать что-либо более идиотское чем XOR.
Например бесконечное множество алгоритмов, при наличии зашифрованного и открытого файла не позволяют получить ключ менее чем за экспоненциальное относительно размера ключа время, а уж чтоб за линейное с самым маленьким мыслимым коэффициентом (как XOR) - так тем более. А это одно из основных требований к хорошему симметричному алгоритму. Очевидно, что ничто не мешает таким алгоритмам предусмотреть использование сколь угодно больших ключей, а значит если размер ключа сделать превышающим размер файла получим тот же невскрываемый шифр (что делает подобный алгоритм во всяком случае не хуже XOR только на этот раз все зашифрованные одним ключом файлы не оказываются под угрозой в случае, если один из этих файлов открылся случайно.
Если коротко: можно придумать бесконечное множество алгоритмов столь же "абсолютно надежных" (т.е. в том же наивном смысле) как XOR, но обладающих дополнительными преимуществами (которые мягко говоря весьма полезны). Так, что XOR - это полный отстой как в теоретическом так и в практическом плане.
В дополнение к реализациям - огромный набор реализованных алгоритмов есть в иходниках FreeBSD.
Каталог - /usr/src/crypto/openssl/crypto/
Устройство файлов - зничительно более ясное, вроде компилируется (однако правильно ли работает - не проверял, разбираться надо). Но и как и где там чего искать - понятно. Лицензия вроде не GPL, так что тоже хорошо.
Каталог - /usr/src/crypto/openssl/crypto/
Устройство файлов - зничительно более ясное, вроде компилируется (однако правильно ли работает - не проверял, разбираться надо). Но и как и где там чего искать - понятно. Лицензия вроде не GPL, так что тоже хорошо.
ещё раз, XOR - самый криптостойкий. его невозможно вскрыть.
Если третье лицо знает только зашифрованный текст, он НИЧЕГО не сможет получить, даже зная, что сообщение заXORено.
Если третье лицо знает только зашифрованный текст, он НИЧЕГО не сможет получить, даже зная, что сообщение заXORено.
> ещё раз, XOR - самый криптостойкий. его невозможно вскрыть.
в теории - может быть, на практике - нет.
в теории - может быть, на практике - нет.
Блин, ну все же читали где-нибудь про это и прекрасно понимают это... Но только на практике это использовать НЕВОЗМОЖНО, потому как, например, есть ключевое требование к тому, чтобы гамма была одноразовой. Ты хоть думал, какие должны быть протоколы использования подобной системы, если мы говорим не о передаче чего-то по каналу связи (про что Шеннон, кстати, и писал а про шифрование данных? Даже если с каналом связи - и то, проблемы возникают, где хранить этот ключ, чтобы его сотрудники не украли, как передавать этот ключ и т.п. В файлами ситуацию на порядки усугубляется.
Допустим, есть компьютер, на котором хранится файл. Его нужно зашифровать - для этого вызывается ответственный работник и шифрует его, а ключ - уносит в соседнюю комнату в сейф (ну не бред?). Это ещё ладно, это цветочки. Теперь допустим, что необходимо работать с этими данными - тогда получается, что при небольшом изменении файла его нужно перешифровывать с новым ключём (и не понятно, как можно с ним прозрачно работать, если ключ такой большой). Проблем с работой - масса, смысл, в итоге - НУЛЕВОЙ.
Допустим, есть компьютер, на котором хранится файл. Его нужно зашифровать - для этого вызывается ответственный работник и шифрует его, а ключ - уносит в соседнюю комнату в сейф (ну не бред?). Это ещё ладно, это цветочки. Теперь допустим, что необходимо работать с этими данными - тогда получается, что при небольшом изменении файла его нужно перешифровывать с новым ключём (и не понятно, как можно с ним прозрачно работать, если ключ такой большой). Проблем с работой - масса, смысл, в итоге - НУЛЕВОЙ.
безопасность ключа - это вообще отдельная песня и в большинстве теорий под сомнение не ставится
Тут надо уточнять, что имеется в виду не XOR, а шифрование с одноразовым ключём, равным по длине сообщению. Если ключа нет - то вскрыть, конечно, нельзя...
Но такая система не работоспособна, это раз - создаёт дополнительные проблемы с работой с ключём.
А второе, и главное - криптография, это самый надёжный и хорошо исследованный участок в вопросе защиты. В любом случае на практике если и будут ломать, то или красть ключ через троянов, или какое-нибудь хитрое оборудование для перехвата использовать, или подкупать или запугивать сотрудников. Поэтому можно считать, что на практике современные проверенные алгоритмы абсолютно надёжны, потому как по сравнению с ними всё другое - сплошные большие и страшные дыры.
Но такая система не работоспособна, это раз - создаёт дополнительные проблемы с работой с ключём.
А второе, и главное - криптография, это самый надёжный и хорошо исследованный участок в вопросе защиты. В любом случае на практике если и будут ломать, то или красть ключ через троянов, или какое-нибудь хитрое оборудование для перехвата использовать, или подкупать или запугивать сотрудников. Поэтому можно считать, что на практике современные проверенные алгоритмы абсолютно надёжны, потому как по сравнению с ними всё другое - сплошные большие и страшные дыры.
ещё раз, XOR - самый криптостойкий. его невозможно вскрыть.если не поняли суть того, что я написал, то это невероятно тяжелый случай.
Если третье лицо знает только зашифрованный текст, он НИЧЕГО не сможет получить, даже зная, что сообщение заXORено.
еще раз для особо одаренных: к качественному алгоритму шифрования предъявляется много требований, а не только (1) невозможность (или вычислительная сложность) получения открытого сообщения в том случае, когда известно только закрытое.
Еще такими требованиями являются как минимум следующие: (2) выч.сложность (т.е. не менее чем экспоненциальное время выполнения) расшифрования какой-либо части зашифрованного сообщения, если у нас есть другое сообщение в открытом и зашифрованном с тем же ключом виде (XOR сосет (3) конечно же простота (т.е. не более чем полиномиальное относительно размера ключа и размера сообщения время выполнения) самого зашифрования/расшифрования (что у XORа есть (4) невозможность узнать чем одно открытое сообщение отличается от другого (т.е. например получить поблочную разность если известны их шифровки с одним ключом (и тут XOR сосет по максимуму, т.к. XOR двух шифровок - это XOR двух открытых сообщений, т.е. побитовая разность и т.д.
Конечно более криптостойкого алгоритма чем XOR в том смысле, в котором вы употребляете этот термин, придумать нельзя, но можно придумать равный по криптостойкости алгоритм, который будет в этом плане не хуже, а во всех других отношениях ЛУЧШЕ.
1)извини, но если человек уже имеет незашифрованный файл, зачем скрывать от него ключ?Очень простое объяснение:
раздавай всем файлы поксоренные разными ключами.
Программа собирает данные (допустим, о грибах) в файл. Программу каждый день покупают новые грибники. Одни обмениваются своими базами данных. Некоторые грибники нашли редкие сорта грибов и решили зашифровать свои базы данных.
Допустим, у меня есть украденная зашифрованная БД и собственно программа. Тогда я создаю незашифрованную БД-пустышку, сохраняю. Потом шифрую и сравниваю две своих БД. Таким образом нахожу ключ.
Зная ключ, я XORю украденную БД. Получаю секретную информацию.
кстати, могу добавить, что одна из реализаций шифрования на XOR (правда, был примитивный рекуррентый ключ) была взломана. Поэтому встал вопрос о серьезной защите БД
Ты бы постановку задачи дал, что ли - как хранятся данные, которые шифруются, в какой момент нужно шифровать, какие требования... Тогда можно было бы придумать что-нибудь для этого, что годилось бы, и было бы удобно. Потому как криптографический алгоритм - это не единственный важный элемент в системе, важен и режим использования алгоритма и протокол...
Ne tolko teoreticheskii. Imenno etot prosteyshii? no absolyutno stoykii shifr ispolzuetsya na praktike dlya peredachi osobo vajnyx soobscheniy.
Ty ne sovsem prav. Eto ne XOR samyi kriptostoykiy, eto odnorazovaya lenta samaya kriptostoykaya. Algoritmov shifrovaniya, kotorye s beskoneshnoy lentoy klyucha dadut takuyu je absolyutnuyu stoikost', prorva. Sobstvenno, oni vse absolyutno ustoychivy. Prosto esli kluch vse ravno beskonechyi, to XOR realizuetsya prosche vsego.
> Тогда я создаю незашифрованную БД-пустышку, сохраняю. Потом шифрую и сравниваю две своих БД. Таким образом нахожу ключ.
Nepravilno. Ty ne mojesh naiti klyuch, potomu chto on odnorazovyi. Vtoroy raz database zakodiruetsya drugim klyuchom.
Nepravilno. Ty ne mojesh naiti klyuch, potomu chto on odnorazovyi. Vtoroy raz database zakodiruetsya drugim klyuchom.
Блин, ну неужели никто не слышал про CBC, ECB, CFB и иже с ними? Это ж простейшие алгоритмы динамического изменения ключа, которые позволяют легко защищаться от описанного тобой метода анализа.
2) выч.сложность (т.е. не менее чем экспоненциальное время выполнения) расшифрования какой-либо части зашифрованного сообщения, если у нас есть другое сообщение в открытом и зашифрованном с тем же ключом виде (XOR сосет)
(4) невозможность узнать чем одно открытое сообщение отличается от другого (т.е. например получить поблочную разность если известны их шифровки с одним ключом (и тут XOR сосет по максимуму, т.к. XOR двух шифровок - это XOR двух открытых сообщений, т.е. побитовая разность)Два сообщения шифруются разными ключами.
так что по п.2. и п.4 ХОR ни в коем случае не сосёт.
Ещё раз повторю, что я имею в виду под XOR:
XOR сообщения и ключа, равного длине сообщения. Ключ одноразовый.
Единственный минус этого алгоритма - размер ключа. И всё.
Безопасность ключа и его транспортабельность не обсуждается.
е2) выч.сложность (т.е. не менее чем экспоненциальное время выполнения) расшифрования какой-либо части зашифрованного сообщения, если у нас есть другое сообщение в открытом и зашифрованном с тем же ключом виде (XOR сосет)(4) невозможность узнать чем одно открытое сообщение отличается от другого (т.е. например получить поблочную разность если известны их шифровки с одним ключом (и тут XOR сосет по максимуму, т.к. XOR двух шифровок - это XOR двух открытых сообщений, т.е. побитовая разность)Два сообщения шифруются разными ключами.
так что по п.2. и п.4 ХОR ни в коем случае не сосёт.
Ещё раз повторю, что я имею в виду под XOR:
XOR сообщения и ключа, равного длине сообщения. Ключ одноразовый.
Единственный минус этого алгоритма - размер ключа. И всё.
Безопасность ключа и его транспортабельность не обсуждается.
чувак ты читать умеешь, что написано?
Или у тебя логическое мышление отсутствует напрочь?
Помедитируй над моей подписью, что ли.
ты заметил слово ЕСЛИ?
Ты заметил какой текст предшествовал пунктам и какой текст после них?
Я не говорил о том какую схему использования алгоритма ты для нас придумал, я говорил о некоторых требованиях предъявляемых к качественному алгоритму, что написано прямым текстом. И пунктам (2) и (4) XOR не удовлетворяет.
Как использовать алгоритм пользователи решат сами исходя из стоящих перед ними задач: будет надо абсолютная надежность - будут использовать одноразовый ключ размером с сообщение, а будет нужна передача секретных данных по незащищенному каналу (например) будут использовать один и тот же ключ (который есть у них всех) для разных сообщений, а задача хорошего алгоритма обеспечить максимальное количество возможностей (или хотя бы несколько самых тривиальных чего XOR не обеспечивает. Конечно алгоритм не сможет заставить пользователя хранить ключ в надежном месте, но алгоритм запросто может обеспечить возможность использовать ключ для многих сообщений без опасности раскрыть их все, если случайно раскроется одно, нисколько не жертвуя возможностью "абсолютно надежно" пользоваться одноразовыми ключами размером с сообщение.
XOR плох тем, что он не предоставляет самых тривиальных возможностей и уникальных возможностей при этом тоже не предоставляет - бесконечное множество алгоритмов можно использовать для тех же целей и с той же степенью надежности что и XOR, а вот как либо иначе XOR использовать нельзя, а вот многие другие "абсолютно надежные" алгоритмы можно. Ясно в чем претензия? Или по кругу пойдем про уникальный ключ бла бла бла?
Я ничуть не усомнился в "абсолютной надежности" XOR (в том смысле в котором вы подразумеваете). Я лишь утверждаю, что XOR - полный отстой и уточняю в каком смысле, что вовсе не противоречит его "абсолютной надежности".
XOR сообщения и ключа, равного длине сообщения. Ключ одноразовый.да неужели "и все"?
Единственный минус этого алгоритма - размер ключа. И всё.
а не приходило в голову, что жесткое требование одноразовости ключа и то, что он обязан быть почти идеально рандомизирован (т.е. случаен) - это тоже минусы именно алгоритма (а не какие-то неизбежные фундаментальные требования)?
Причем это именно очевидные теоретические минусы, а уж про практическую удобность вообще смешно говорить. XOR фактически вообще не применим ни в одной практической ситуации: если у нас ключ имеет размер сообщения, он уникален для каждого сообщения и содержится в тайне (а все эти требования необходимы то нахрен нам это надо, если мы можем просто взять сообщение и хранить его в тайне вместо ключа? Это абсолютно эквивалентно по надежности и не надо ничего шифровать
Единственное замечание, что в этом случае информация оказывается читаемой (а в случае XOR ключ случайный и зашифрованная информация случайна, так что возникает проблема идентификации, и про взаимосвязь ключа и инфы надо еще догадаться но нам ничто не мешает применить рандомизирующую обратимую функцию к нашим "секретным" данным, лежащим в сейфе, и они тоже будут не читаемы и столь же надежно сохранены, а раскрыть какой функцией мы рандомизировали ни чуть не проще чем выяснить взаимосвязь между ключом и инфой.так и не понял, что ты хотел сказать.
"Если" я заметил - вот только это условие никогда не будет выполнено.
Так и не услышал ни одного вменяемого аргумента против передачи XOR-еного сообщения по открытому каналу (одноразовым ключом, длиной в сообщение).
Чувак, либо ты не сечёшь сам, либо излагай свои мысли более прозрачно.
"Если" я заметил - вот только это условие никогда не будет выполнено.
Так и не услышал ни одного вменяемого аргумента против передачи XOR-еного сообщения по открытому каналу (одноразовым ключом, длиной в сообщение).
Чувак, либо ты не сечёшь сам, либо излагай свои мысли более прозрачно.
Koroche, tvoy glavnyi argument, kak ya ponyal: "esli by XOR byl krut, ego by ispolzovali na praktike". Tak vot, na praktike v osobo kritichnyx situaziyax, kogda nujna absolyutnaya zaschischennost', ispol'zuyut imenno XOR.
так и не понял, что ты хотел сказать.а пытался?
"Если" я заметил - вот только это условие никогда не будет выполнено.конечно не будет
именно в этом суть претензии к XOR, я же почти прямо об этом писал
XOR подразумевает только одну схему использования, которую вы изложили (причем самую неудобную и давно не используемую на практике).
А другие алгоритмы, имея возможность использования с той же схемой, что и XOR позволяют использование и с такой же схемой, что и XOR и с многими другими схемами, чего XOR не позволяет. В этом состоит их преимущество перед XOR, а каких-либо недостатков по сравнению с XOR у них нет.
Так и не услышал ни одного вменяемого аргумента против передачи XOR-еного сообщения по открытому каналу (одноразовым ключом, длиной в сообщение).Может быть это потому, что я не произнес ни одного такого аргумента? Могло это послужить причиной, что вы его не услышали?
Да еще я в добавок явно сказал, что никаких возражений по поводу абсолютной надежности использования именно XOR для передачи сообщения с одноразовым секретным ключом размером с сообщение я не имею (как это тебя не натолкнуло на мысль, что возражать против этого я определенно не стану, раз уж я сам это утверждаю?).
Я утверждал о том, что XOR - это полный отстой (и почти строго сформулировал в каком смысле а это не имеет отношения к применимости его в такой абстрактной (но совершенно не практичной) схеме.
Если бы ты удосужился прочитать мой пост внимательно, то увидел бы аргумент против практичности самого использования одноразового ключа длинной в сообщение.
Неужели непонятно, что для того, чтобы сообщение дошло до адресата (по любому каналу адресату должен быть известен ключ, а значит его тоже надо передать, причем сохранив в тайне. Так зачем же передавать тайно одноразовый ключ размером с сообщение, если вместо этого можно передать тайно само сообщение в точности с такой же надежностью?
Достаточно вменяемый аргумент?
Koroche, tvoy glavnyi argument, kak ya ponyal: "esli by XOR byl krut, ego by ispolzovali na praktike".нет
мои аргументы изложены довольно явно и подробно, и они теоретические, о практичности я тоже рассуждаю теоретически.
Tak vot, na praktike v osobo kritichnyx situaziyax, kogda nujna absolyutnaya zaschischennost', ispol'zuyut imenno XOR.XOR не преобразованного сообщения с не преобразованным ключом? Уверены?
Я могу пока догадаться об одной возможной ситуации такого использования, но "абсолютная защищенность" - это слишком громко сказано. Я могу придумать гораздо "абсолютнее".
Net, argument nevmenyaemyi. Ty mojesh jdad' srochnogo i vajnogo soobscheniya. Kluchom obmenyalis' zaranee, mojet, tri goda im obmenivalis', a soobschenie tebe voobsche cherez otkrytyi radioefir peredadut.
"gorazdo absolyutnee" s tochki zreniya kriptoanaliza (a ne steganografii, skajem) ne byvaet
Ty mojesh jdad' srochnogo i vajnogo soobscheniya. Kluchom obmenyalis' zaranee, mojet, tri goda im obmenivalis', a soobschenie tebe voobsche cherez otkrytyi radioefir peredadut.да, именно такую ситуацию я подразумевал, говоря, что догадываюсь об одной возможной ситуации.
Давай так - на практике неизвестно, какой именно метод испльзуется...
"gorazdo absolyutnee" s tochki zreniya kriptoanaliza (a ne steganografii, skajem) ne byvaetа я и не говорил (и вы в предыдущих постах не говорили что только с точки зрения криптоанализа ситуации "открытое сообщение+неизвестный ключ". Криптоанализ - понятие широкое и применяется для разных ситуаций, а не только для такой.
Как самый простейший (но не самый продвинутый) пример защиты "абсолютнее" описанной - это помимо XOR-а дополнительно применить любой нормальный алгоритм зашифрования с коротким ключом - обязательно перемешивающий биты (ключ запоминается, но не записывается). Тогда очевидно, что раскрытия большого ключа (на которое куча времени от обмена ключами до отправления сообщения) недостаточно, чтобы вскрыть сообщение. И еще более важно, что очень усугубляется проблема идентификации ключа, если предположить, что ключ украден не на дискете с надписью "супер секретный ключ", а в более адекватной ситуации, когда ключ хранится среди огромного непрерывного (не разбитого на файлы) массива данных с другими ключами и просто случайным мусором (в такой ситуации XOR не модифицированного сообщения с не модифицированным ключом сосет - надеюсь понятно почему).
Давай так - на практике неизвестно, какой именно метод испльзуется...ну...
может у товарища источники информации, что нам и не снились
У xor (и аналогов - в некотором роде разумнее add (mod 32) или add(mod 256 есть один плюс - для того, чтобы расшифровать сообщение, не нужен компьютер - нужно лишь, чтобы было зашифрованное сообщение и блокнот с личным ключём. В каких-то вполне реальных ситуациях это может быть весьма полезным (особенно при учёте того, что карманные компьютеры появились совсем недавно). А в том, что кто-то на стационарном канале пользуется подобной схемой, я сильно сомневаюсь, потому как это нафиг не нужно и очень накладно.
У xor (и аналогов - в некотором роде разумнее add (mod 32) или add(mod 256 есть один плюс - для того, чтобы расшифровать сообщение, не нужен компьютер - нужно лишь, чтобы было зашифрованное сообщение и блокнот с личным ключём.тут совершенно согласен, тоже об этом думал
простота - несомненный плюс
Только мы все же не в каменном веке, уж на какой-то микродевайс разорились бы.
Может тогда и сообщение не по радиоканалу, а стуком в рельсу?
Древняя техника сейчас более подозрительная вещь, чем современная микроэлектроника типа какой-то мобилы.
Вообще-то простыми подручными средствами можно обрабатывать и сложные алгоритмы.
Например, простая реализация алгоритма RC4 при помощи колоды игральных карт
Например, простая реализация алгоритма RC4 при помощи колоды игральных карт
>>Я могу придумать гораздо "абсолютнее".
Нет, серьёзно, убей себя об стену лучше.
Ну или книжку почитай умную.
"Ваши идеи, Шариков, космические как по масштабу, так и по глупости".
Чё-то я добрый сегодня, так и быть внесу некоторую ясность.
1) Если длина ключа меньше длины сообщения, то кодирование не является абсолютно стойким. Это несложно показать, рассмотрев пространство закодированных сообщений и пространство их прообразов. "Абсолютная стойкость" - это, к твоему сведению, математический термин, строгое определение которого ты можешь найти в любой книжке по криптографии.
2) Если ты кодируешь одним и тем же ключом два сообщения, то эти два сообщения можно воспринимать как одно большое сообщение, следовательно, ключ получается короче сообщения, см. п. 1.
3) Из п.1 следует, что для абсолютно стойкого кодирования необходимо, чтобы длина ключа была не меньше длины сообщения. Дальше я буду называть такой ключ "одноразовым".
4) Сложение mod 256 или xor (сложение mod 2, на самом деле) с одноразовым ключом гарантированно дают абсолютно стойкое кодирование. Это несложно показать.
5) более того, это самые быстрые алгоритмы, использующие одноразовый ключ. Поскольку ничего более стойкого, чем "абсолютно стойкий" быть не может, совершенно непонятно, зачем ещё что-то придумывать.
6) А вот использование одноразового ключа с большинством других алгоритмов НЕ ДАЁТ абсолютно стойкого кодирования. Поэтому все разглагольствования на тему "а вот в другие алгоритмы можно засовывать ключи разной длины, и получать более или менее стойкое кодирование" суть пиздёж и демагогия.
7) Есть, конечно, классы алгоритмов шифрования, которые работают следующим образом: по данному ключу генерится псевдослучайная key stream, с которой потом ОПЯТЬ ЖЕ КСОРИТСЯ плейнтекст. При этом, если начало key stream взаимно однозначно мапится в пространство ключей, то в такой алгоритм можно скормить одноразовый ключ и получить эквивалент ксора.
8) Совершая дополнительные действия перед ксором, можно абсолютную стойкость потерять. В качестве примера (домашнего задания) можешь рассмотреть мега-кодирование "ксор с обваливанием", которое на вид "защищённее" простого ксора.
9) Рассуждая на темы, о которых ты имеешь крайне поверхностное представление, но которые, на самом деле, достаточно исследованы и разработаны, ты успешно выставляешь себя полным идиотом.
Нет, серьёзно, убей себя об стену лучше.
Ну или книжку почитай умную.
"Ваши идеи, Шариков, космические как по масштабу, так и по глупости".
Чё-то я добрый сегодня, так и быть внесу некоторую ясность.
1) Если длина ключа меньше длины сообщения, то кодирование не является абсолютно стойким. Это несложно показать, рассмотрев пространство закодированных сообщений и пространство их прообразов. "Абсолютная стойкость" - это, к твоему сведению, математический термин, строгое определение которого ты можешь найти в любой книжке по криптографии.
2) Если ты кодируешь одним и тем же ключом два сообщения, то эти два сообщения можно воспринимать как одно большое сообщение, следовательно, ключ получается короче сообщения, см. п. 1.
3) Из п.1 следует, что для абсолютно стойкого кодирования необходимо, чтобы длина ключа была не меньше длины сообщения. Дальше я буду называть такой ключ "одноразовым".
4) Сложение mod 256 или xor (сложение mod 2, на самом деле) с одноразовым ключом гарантированно дают абсолютно стойкое кодирование. Это несложно показать.
5) более того, это самые быстрые алгоритмы, использующие одноразовый ключ. Поскольку ничего более стойкого, чем "абсолютно стойкий" быть не может, совершенно непонятно, зачем ещё что-то придумывать.
6) А вот использование одноразового ключа с большинством других алгоритмов НЕ ДАЁТ абсолютно стойкого кодирования. Поэтому все разглагольствования на тему "а вот в другие алгоритмы можно засовывать ключи разной длины, и получать более или менее стойкое кодирование" суть пиздёж и демагогия.
7) Есть, конечно, классы алгоритмов шифрования, которые работают следующим образом: по данному ключу генерится псевдослучайная key stream, с которой потом ОПЯТЬ ЖЕ КСОРИТСЯ плейнтекст. При этом, если начало key stream взаимно однозначно мапится в пространство ключей, то в такой алгоритм можно скормить одноразовый ключ и получить эквивалент ксора.
8) Совершая дополнительные действия перед ксором, можно абсолютную стойкость потерять. В качестве примера (домашнего задания) можешь рассмотреть мега-кодирование "ксор с обваливанием", которое на вид "защищённее" простого ксора.
int prevEncoded = 0;
for (int i = 0; i < length; i++)
{
encoded[i] = plainText[i] ^ key[i] ^ prevEncoded;
prevEncoded = encoded[i];
}
9) Рассуждая на темы, о которых ты имеешь крайне поверхностное представление, но которые, на самом деле, достаточно исследованы и разработаны, ты успешно выставляешь себя полным идиотом.
Не совсем по существу, но imho
"ксор с обваливанием" настолько же стоек.
"ксор с обваливанием" настолько же стоек.
Реализуй Квадрат Виженера!
Ойёёё.
Да, что-то я обломался Это, наверное, старые воспоминания про ксор с однобайтовым ключом на меня так плохо повлияли. Если там специфически реализовать обваливание, то можно получить половину плейнтекста в чистом виде сразу.
А вот как "соптимизировать" такой ксор что-то думать влом, хотя наверняка можно.
Да, что-то я обломался Это, наверное, старые воспоминания про ксор с однобайтовым ключом на меня так плохо повлияли. Если там специфически реализовать обваливание, то можно получить половину плейнтекста в чистом виде сразу.
А вот как "соптимизировать" такой ксор что-то думать влом, хотя наверняка можно.
Нет, серьёзно, убей себя об стену лучше.мм-да
Ну или книжку почитай умную.
"Ваши идеи, Шариков, космические как по масштабу, так и по глупости".
пожалуй буду разговаривать примерно твоим языком.
Надеюсь, интеллектуально развитых людей не будет очень от этого тошнить, и они смогут извлекать информацию из написанного, отсеивая мусор.
Должно ведь все быть по справедливости, так ведь?
Чё-то я добрый сегодня, так и быть внесу некоторую ясность.ох ты ж ё
снизошел надо же
(до внимательного прочтения постов, на которые наезжаешь, конечно не снизошел, великийбля-могучий-мега-спец)
1) Если длина ключа меньше длины сообщения, то кодирование не является абсолютно стойким. Это несложно показать, рассмотрев пространство закодированных сообщений и пространство их прообразов. "Абсолютная стойкость" - это, к твоему сведению, математический термин, строгое определение которого ты можешь найти в любой книжке по криптографии.с чего это ты решил, что я не в курсе какого-либо из этих пунктов?
2) Если ты кодируешь одним и тем же ключом два сообщения, то эти два сообщения можно воспринимать как одно большое сообщение, следовательно, ключ получается короче сообщения, см. п. 1.
3) Из п.1 следует, что для абсолютно стойкого кодирования необходимо, чтобы длина ключа была не меньше длины сообщения. Дальше я буду называть такой ключ "одноразовым".
4) Сложение mod 256 или xor (сложение mod 2, на самом деле) с одноразовым ключом гарантированно дают абсолютно стойкое кодирование. Это несложно показать.
я в том числе на них и опирался в своих теоретических рассуждениях и если ты не заметил это, то последуй своим повторяющимся рекомендациям и убей себя.
5) более того, это самые быстрые алгоритмы, использующие одноразовый ключ.канешна
кто спорит?
Поскольку ничего более стойкого, чем "абсолютно стойкий" быть не может, совершенно непонятно, зачем ещё что-то придумывать.ну это просто патология
если не понятно зачем после прочтения моих постов или тем более после детального знакомства с криптографией и криптоанализом, то опять же только только убить себя.
6) А вот использование одноразового ключа с большинством других алгоритмов НЕ ДАЁТ абсолютно стойкого кодирования.здесь опять же следствие того, что не удосужился внимательно прочитать, что я писал и задействовать пару извилин, чтобы понять это.
"большинство других алгоритмов" о которых говоришь ты (правильное утверждение, что они не "абсолютно криптостойки") - это наверно стандартизированные и прочие широко используемые алгоритмы, которые разработаны специально для коротких ключей.
Впрочем любой из алгоритмов для коротких ключей, который зашифровывая блок с размером ключа (т.е. маленький для любого блока дает разный результат с двумя разными ключами - то есть при любом фиксированном блоке размером с ключ отображение пространства ключей в пространство шифровок взаимно однозначно (а таковыми являются некоторые из "рыночных" алгоритмов можно использовать как "абсолютно криптостойкий" - в строго математическом смысле, а не "примерно бла бла бла..." Самый тривиальный способ: поблочной шифровкой с разными ключами для каждого блока не превышающего ключ по размеру. (мегаключ=конкатенация всех ключей - разумеется одноразовый)
Доказать в качестве упражнения, млин.
Но так или иначе, если все же прочесть, что я писал, то ясно, что я говорил не только про рыночные алгоритмы, а слово "существует" подразумевал в математическом смысле (так же как и "абсолютно криптостойкий", что было написано прямым текстом а не в смысле "существует на рынке" (и уж тем более я не говорил, что таких большинство на рынке).
Поэтому все разглагольствования на тему "а вот в другие алгоритмы можно засовывать ключи разной длины, и получать более или менее стойкое кодирование" суть пиздёж и демагогия.и после этого ты типа спец по криптографии/криптоанализу?
не нравится не используй нормальные алгоритмы
Не знаю как для кого, а лично для меня алгоритм предоставляющий больше возможностей и не жертвующий никакими из них (включая супер-мега-рульными возможностями XORа абсолютно криптостойкого применения в одной единственной ситуации) заведомо лучше узкоспециализированного. Но понятно и ежу, что в той единственной ситуации, когда это допустимо, покатит и XOR, ADD(mod 256 ADD(mod 2^N) - для любого N, и т.п.
Рынок показал, что не только для меня, а и для всех остальных тоже, видимо кроме вас, хотя рынок конечно - штука не очень показательная.
7) Есть, конечно, классы алгоритмов шифрования, которые работают следующим образом: по данному ключу генерится псевдослучайная key stream, с которой потом ОПЯТЬ ЖЕ КСОРИТСЯ плейнтекст.ну и?
да есть куча такого отстоя типа режима гаммирования без обратной связи ГОСТ-28147-89 и т.д., в некоторых ситуациях сойдет, но в целом сосет.
При этом, если начало key stream взаимно однозначно мапится в пространство ключей, то в такой алгоритм можно скормить одноразовый ключ и получить эквивалент ксора.ааа
эквивалент XORа с полностью случайным числом в качестве ключа размером в сообщение в смысле абсолютной криптостойкости?
щас оборжусь
если напрячь немножко память, то вспоминается, что в криптоанализе все алгоритмы считаются известными криптоаналитику, а значит известен и алгоритм генерации последовательности псевдослучайных чисел.
если задействовать первую извилину, то ясно, что из твоего утверждения "начало key stream взаимно однозначно мапится в пространство ключей" следует, что "начало key stream" того же размера, что и ключ, а поскольку "начало key stream" уж конечно меньше по размеру чем "key stream" (иначе это называлось бы не генерация последовательности случайных чисел, а просто взаимно однозначное отображение и "key stream" равно по длинне сообщению, мы получаем феноменальный вывод, что длинна ключа меньше длинны сообщения. После чего вы отсылаетесь ботать свой собственный пункт (3).
А если вы не это имели в виду, не то хотели сказать, и т.д.
То нефиг использовать громкие слова типа "эквивалент" или надо уточнять в каком смысле "эквивалент".
8) Совершая дополнительные действия перед ксором, можно абсолютную стойкость потерять. В качестве примера (домашнего задания) можешь рассмотреть мега-кодирование "ксор с обваливанием", которое на вид "защищённее" простого ксора.конечно можно потерять - обгадить можно все
code:
int prevEncoded = 0;
for (int i = 0; i < length; i++)
{
encoded[i] = plainText[i] ^ key[i] ^ prevEncoded;
prevEncoded = encoded[i];
}
а можно абсолютную стойкость и не потерять получив дополнительные преимущества.
вот блин:
Ойёёё.
Да, что-то я обломался Это, наверное, старые воспоминания про ксор с однобайтовым к
Впрочем любой из алгоритмов для коротких ключей, который зашифровывая блок с размером ключа (т.е. маленький для любого блока дает разный результат с двумя разными ключами - то есть при любом фиксированном блоке размером с ключ отображение пространства ключей в пространство шифровок взаимно однозначно (а таковыми являются некоторые из "рыночных" алгоритмов)Нука? Скажи мне, пожалуйста, названия этих некоторых "рыночных" алгоритмов. Мне чиста интересно. Потому что в DES, например (ну я просто его полностью читал, поэтому абсолютно уверен ключ перед шифрованием искуственно удлинняется. Кроме того, "разный результат с двумя разными ключами" никто не гарантирует.
---
Не тупи. Мне казалось, что я вполне ясно описал процесс. Есть некоторый алгоритм генерации псевдослучайной key stream по данному ключу, причём если ключ n-битный, то первые n бит кейстрима взаимно однозначно соответствуют ключу (это, конечно же, довольно сильное требование, которому наверняка не все такие шифры удовлетворяют). Тогда удлинняя ключ вплоть до длины сообщения можно плавно получить абсолютно стойкий шифр.
Приведи, пожалуйста, примеры реальных шифров, которые превращаются в абсолютно стойкие при достаточной длине ключа. Если таких нет, то не пизди на ксор.
Нука? Скажи мне, пожалуйста, названия этих некоторых "рыночных" алгоритмов. Мне чиста интересно. Потому что в DES, например (ну я просто его полностью читал, поэтому абсолютно уверен ключ перед шифрованием искуственно удлинняется. Кроме того, "разный результат с двумя разными ключами" никто не гарантирует.Думаю, что некоторые из стандартизированых блочных алгоритмов, у которых размер ключа=размеру блока должны удовлетворять этому условию. (возможно даже DES в своей обновленной версии стандарта 1999 года, где возможно использование нормального 64-битного ключа, а не удлинненного 56-битного).
Но не утверждаю пока.
Поботаю скажу какие именно, если не заломает.
Пока точно могу сказать, что если в ГОСТ-28147-89 при зашифровании блока (64 бит) ограничится только двумя базовыми криптопреобразованиями (с двумя 32 битными кусками ключа то такое зашифрование удовлетворяет указанному условию: "разный результат с двумя разными ключами" для любого блока (это легко доказать). Так, что кусок ГОСТа можно сказать катит.
Только в самом ГОСТ-е для зашифрования производится 32 основных криптопреобразования и ключ 256 бит при блоке 64 бит. Так, что само элементарное зашифрование ГОСТа, конечно не катит.
Приведи, пожалуйста, примеры реальных шифров, которые превращаются в абсолютно стойкие при достаточной длине ключа. Если таких нет, то не пизди на ксор.вот кусок ГОСТа (хоть и не сам ГОСТ) - один из примеров (пока)
кроме того ясно же, что даже ксор дополненный какой-то адекватной формой "обваливания", т.е. обратной связью, тоже лучше чем просто ксор.
И понапридумать даже я сам могу бесчисленное множество всяких "абсолютно стойких" алгоритмов вместе со строгим доказательством их абсолютной стойкости, но при этом они еще будут удовлетворять тем четырем требованиям (и пятому написанному ниже о которых я писал ранее (а не в духе ADD(mod 256) или того же XOR).
пятое требование для приличного алгоритма:
(5) выч.сложность достоверного установления факта, что некие части плейнтекста совпадают, если даны их шифровки с одним ключом, кроме случая полного совпадения, конечно.
Не тупи. Мне казалось, что я вполне ясно описал процесс. Есть некоторый алгоритм генерации псевдослучайной key stream по данному ключу, причём если ключ n-битный, то первые n бит кейстрима взаимно однозначно соответствуют ключу (это, конечно же, довольно сильное требование, которому наверняка не все такие шифры удовлетворяют). Тогда удлинняя ключ вплоть до длины сообщения можно плавно получить абсолютно стойкий шифр.ну это все и так понятно
но когда удлиннишь ключ до длинны сообщения у тебя получится
key stream размером с ключ и это уже будет не псевдослучайный key stream, а просто случайный, потому как взаимно отображается в пространство случайных ключей.
В общем такой подход позволяет применение в большем числе ситуаций, чем обычный XOR, и в этом его несомненное преимущество перед XORом, но тем не менее у него остается все же куча проблем.
Кроме того, "разный результат с двумя разными ключами" никто не гарантирует.Скорее всего, врят ли это выполняется для сильных алгоритмов. Дело в том, что подобная архитектура сильно сужает класс функций, который может выступать в качестве алгоритма, и вообще, вполне возможно, что тогда можно будет придумать алгоритм, который будет ломать этот шифр... Это ОЧЕНЬ сильное ограничение, и неразумное. В первую очередь это касается ситуации, когда длина блока совпадает с длиной ключа.
Думаю, что некоторые из стандартизированых блочных алгоритмов, у которых размер ключа=размеру блока должны удовлетворять этому условию. (возможно даже DES в своей обновленной версии стандарта 1999 года, где возможно использование нормального 64-битного ключа, а не удлинненного 56-битного).
Но не утверждаю пока.
Дело в том, что подобная архитектура сильно сужает класс функций, который может выступать в качестве алгоритма,сужает, но не так уж сильно, если подумать
а еще можно заметить, что в блочных шифрах обычно используются именно обратимые операции (XOR, ADD, табличная подстановка, циклические сдвиги, перестановки битов, байтов и т.п. а вот необратимые типа OR, AND и т.п. как раз не используются.
Тенденция однако.
и вообще, вполне возможно, что тогда можно будет придумать алгоритм, который будет ломать этот шифр...откуда такой вывод?
имхо как раз наоборот: сломать его будет максимально сложно, если такой алгоритм будет грамотно и разносторонне продуман. (главное не протупить в чем-то)
Это ОЧЕНЬ сильное ограничение, и неразумное.тема неразумности не раскрыта
почему не разумное?
В первую очередь это касается ситуации, когда длина блока совпадает с длиной ключа.обычно ключ не меньше блока, а в ситуации когда ключ больше блока выполнение этого условия в принципе не возможно
так, что словосочетание "в первую очередь" звучит как-то странно в этом контексте.
тема неразумности не раскрыта
почему не разумное?
----
Раскрываю тему неразумности.
Микроскоп с приделанной ручкой и плоской железякой неудобен как для наблюдения микроорганизмов, так и для забивания гвоздей.
Если умному человеку нужна абсолютная надёжность, то он использует one time pad + xor, не пытаясь навернуть что-то сверху.
Если умному человеку нужно оптимальное соотношение длины ключа к затратам на вскрытие, он использует AES или elliptic curves - в зависимости от того, есть ли у него надёжный канал. И НИ РАЗУ не задумывается о том, можно ли его алгоритм поднять до абсолютно надёжного, удлинняя ключ.
А ты развёл какую-то левую демагогию.
почему не разумное?
----
Раскрываю тему неразумности.
Микроскоп с приделанной ручкой и плоской железякой неудобен как для наблюдения микроорганизмов, так и для забивания гвоздей.
Если умному человеку нужна абсолютная надёжность, то он использует one time pad + xor, не пытаясь навернуть что-то сверху.
Если умному человеку нужно оптимальное соотношение длины ключа к затратам на вскрытие, он использует AES или elliptic curves - в зависимости от того, есть ли у него надёжный канал. И НИ РАЗУ не задумывается о том, можно ли его алгоритм поднять до абсолютно надёжного, удлинняя ключ.
А ты развёл какую-то левую демагогию.
Если умному человеку нужна абсолютная надёжность, то он использует one time pad + xor, не пытаясь навернуть что-то сверху.правильно: деточка, делай как взрослые дяди говорят и не шали.
Если умному человеку нужно оптимальное соотношение длины ключа к затратам на вскрытие, он использует AES или elliptic curves - в зависимости от того, есть ли у него надёжный канал. И НИ РАЗУ не задумывается о том, можно ли его алгоритм поднять до абсолютно надёжного, удлинняя ключ.
"оптимальное соотношение длины ключа к затратам на вскрытие" - это что тоже строго математическое понятие? Определение в студию.
особенно мне понравился перл про "НИ РАЗУ не задумывается о том..."
Ну шедевр мысли ваще. Манифест "умного человека".
В этом конечно должна быть самая главная цель криптографии и криптоанализа (мы же о них типа беседовали?) - "НИ РАЗУ" не задумываться.
ладно о политике мы говорить сегодня не будем
в том числе и про реально эффективное и надежное использование криптосистем, а не "абсолютно надежное".
А ты развёл какую-то левую демагогию.
как раз то, что ты написал (в посте на который я отвечаю) просто сплошная демагогия
да и вообще: посмотрел бы на что я собственно отвечал и на смысловое содержание самого поста, на который ты якобы отвечаешь (только как-то совсем не по существу вопроса).
а еще можно заметить, что в блочных шифрах обычно используются именно обратимые операции (XOR, ADD, табличная подстановка, циклические сдвиги, перестановки битов, байтов и т.п. а вот необратимые типа OR, AND и т.п. как раз не используются.Нет никакой тенденции. Так - только если смотреть на одном раудне, если же мы берём два раудна, где пусть даже используется один и тот же ключ, то обратимость теряется, потому как для преобразования это не один и тот же ключ, а два разных.
Тенденция однако.
То есть, если у нас для ситуации
c_0 = plain text
c_1 = crypt(c_0, key)
по паре c_0,c_1 всегда можно было восстановить key, то совсем не обязательно, что при
c_0 = plain text
c_1 = crypt(c_0, key)
c_2 = crypt(c_1, key)
по паре c_0,c_2 тоже можно восстановить key. В этом суть проблемы.
откуда такой вывод?откуда такой вывод?
имхо как раз наоборот: сломать его будет максимально сложно, если такой алгоритм будет грамотно и разносторонне продуман. (главное не протупить в чем-то)
Какие дополнительные преимущества может принести это свойство? Я не вижу ничего, чем это может быть полезно, с одной стороны, с другой стороны, чтобы добиться этого свойства, нужно специально проектировать алгоритм и налагать дополнительные ограничения на операции, что совсем не тривиально.
Вообще, шифры ведь ломают "по частям" - когда на основании какого-то набора шифрованных и расшифрованных данных выделяется подмножество ключей из всех возможных, что сужает пространство ключей, а если выделить несколько таких классов - то, возможно, пространство ключей можно сузить до состояния, когда перебрать не составляет проблемы. Частный пример - "линейный криптоанализ", когда составляются линейные уравнения, связывающие биты открытого, шифрованного текста и ключа (естественно, здесь со статистическими значениями работают). Совсем не так просто сделать алгоритм, устойчивый к ЛКА. Но ЛКА можно и обобщить... И чтобы сделать шифр устойчивым, необходимо, чтобы классов ключей выделить было нельзя. Если на функцию налагать дополнительные ограничения, подобные тем, что ты описал - то такие свойства могут появиться. Твоё свойство говорит, что для любой пары (c_i,c_j) существует единственный ключ k, что является, вообще говоря, обобщённой линейностью (причём которой нужно целенаправленно добиваться). В общем случае оно слабо поможет (но шанс разложить его явно выше но заведомо не стоит к нему стремиться...
Из групповых соображений. Функция шифрования - это элемент группы перестановок блоков. Если множество перестановок, соответствующее ключам, образует группу (или при незначительном дополнении получается группа то даже для произвольного случая существуют вероятностные алгоритмы, позволяющие сломать ключ, если не ошибаюсь, за квадратный корень операций относительно полного перебора. Причём в частных случаях ситуация может быть ещё хуже... Поэтому желательно, чтобы не существовало небольших подгрупп, содержащих в себе пространство ключей, или крупное подпространство ключей - иначе ключ (в случае, если он попадёт в соответствующее подпространство) можно будет сломать. Вот, с твоим свойством и сама группа будет меньше (хотя всё равно большая, и дополнить до группы будет нереально и шанс, что среди ключей образуется соответствующее подпространство ключей - явно выше.
Это, конечно, достаточно притянутые "интуитивные" соображения, однако они возникли не с потолка, но по крайней мере, никаких причин для того, чтобы алгоритм с твоим требованием был надёжнее, я не вижу. Впрочем доказать, что среди серьёзных алгоритмов существуют такие, что они обладают этим свойством, ты не сможешь, уверяю - они им явно не обладают, а если бы обладали - то это было бы известно.
гениальноВот именно - практично. Хранение на винте 20 мегов (а это упоминалось в условиях)
1 винчестер с файлами, а второй с ключами - офигенно практично
- стоит около цента.
Болванки сейчас дешевле дискет и стоят примерно 20 центов.
то есть на пользователя получаем 20 центов на ключ. Затраты на написание ксора вообще не обсуждаются.
Пожалуйста оцени реальные затраты на лицензию в любом другом, желательно не менее надежном, алгоритме. Это было бы интересно!
(2) выч.сложность (т.е. не менее чем экспоненциальное время выполнения) расшифрования какой-либо части зашифрованного сообщения, если у нас есть другое сообщение в открытом и зашифрованном с тем же ключом виде (XOR сосет (3) конечно же простота (т.е. не более чем полиномиальное относительно размера ключа и размера сообщения время выполнения) самого зашифрования/расшифрования (что у XORа есть (4) невозможность узнать чем одно открытое сообщение отличается от другого (т.е. например получить поблочную разность если известны их шифровки с одним ключом (и тут XOR сосет по максимуму, т.к. XOR двух шифровок - это XOR двух открытых сообщений, т.е. побитовая разность и т.д.С формулировками согласен, но вот с выводом нет. Как уже многие объяснили - XOR с одноразовым ключем не сосет ни по одному пункту (пункт 2 вообще к нему не применим).
На самом деле ты забыл самый главный пункт - простота реализации. И вот тут с ксором тягаться не кому (главное не перемудрить). Единственная сложность - нагенерить случайных последовательностей, но и их можно купить относительно задешево. Так что если ты готов довериться чужим реализациям - флаг тебе в руки, так как проверить их ты все равно не сможешь.
Вот именно - практично. Хранение на винте 20 мегов (а это упоминалось в условиях)Всё же полезно иногда с тредом ознакомиться, честное слово.
- стоит около цента.
Болванки сейчас дешевле дискет и стоят примерно 20 центов.
то есть на пользователя получаем 20 центов на ключ. Затраты на написание ксора вообще не обсуждаются.
Пожалуйста оцени реальные затраты на лицензию в любом другом, желательно не менее надежном, алгоритме. Это было бы интересно!
Исходная задача - шифрование ФАЙЛОВ. Шифрование файлов и шифрование канала связи - это две совершенно различные области, у каждой свои свойства и у каждой свои проблемы. Одноразовая последовательность годится (и то, с большой натяжкой) для передачи по каналу связи, и крайне неудобна при шифровании данных на диске. Почему - уже расписал. Вкратце - сложность с хранением ключа (с таким же успехом можно уносить в сейф и съёмный диск с файлами) и сложность поддержки возможности изменения файла. Этот метод для шифрования рабочих данных НЕ ПРИМЕНИМ.
Пожалуйста оцени реальные затраты на лицензию в любом другом, желательно не менее надежном, алгоритме. Это было бы интересно!Пожалуйста - USD0=RUR0 - алгоритмы типа AES не лицензируются, существуют бесплатные и полностью свободные (не GPL) реализации, ссылки я приводил. Можешь использовать и массу других проверенных алгоритмов.
На самом деле ты забыл самый главный пункт - простота реализации. И вот тут с ксором тягаться не кому (главное не перемудрить).Как я уже сказал, это как раз заблуждение - реальная реализация (а не профанация) будет очень и очень сложной, на порядок сложнее, чем нормальные алгоритмы.
PS: блин, народ, давайте на нормальном уровне обсуждать... Ну не серьёзно, честное слово...
> Как я уже сказал, это как раз заблуждение - реальная реализация (а не профанация) будет очень и очень сложной, на порядок сложнее, чем нормальные алгоритмы.
"реальная реализация" ксора выполняется самой безрукой студенткой физфака за полтора часа. В железе.
"реальная реализация" ксора выполняется самой безрукой студенткой физфака за полтора часа. В железе.
Ладно, задача - есть большой файл, с которым мы работаем, пусть это xls. У нас есть одноразовый ключ, необходимо обеспечить шифрование файла. Как это делать? Необходимо обеспечить, чтобы после каждого редактирования файл был перешифрован, чтобы если враг похитит предыдущую версию файла, он не смог восстановить новый. Это значит, что в случае одноразовой гаммы необходимо или полностью перешифровать файл, или где-то хранить информацию о том, что такой-то фрагмент файла зашифрован отличным куском одноразовой гаммы. В первом случае - явный перерасход ключа, если файл большой (тот самый винт с гаммой выработается за небольшое время). Во втором случае - далеко не самая тривиальная реализация. Мы ещё рассматриваем ситуацию, когда модифицируемый файл находится в рамках одного офиса... Как дело дойдёт до того, чтобы синхронизировать использование ключей в филиалах - так вообще полная труба будет, в то время как есть масса красивых и удобных схем для подобной работы с классическими ключами.
если файл валяется на компе, то ксор неудобен, это очевидно. Впрочем, это проблемы не ксора, а бесконечной ленты - любой алгоритм на бесконечной ленте неудобен, ни один алгоритм с конечной лентой не криптостоек.
"оптимальное соотношение длины ключа к затратам на вскрытие" - это что тоже строго математическое понятие? Определение в студию.Пьяный штоле?
Затраты на вскрытие - это функция, дающая ожидаемое время для вскрытия ключа заданной длины при условии данных затрат на покупку оборудования (ну и современного состояния вычислительной математики и электронной техники). Или наоборот - стоимость оборудования от желаемого времени вскрытия.
если файл валяется на компе, то ксор неудобен, это очевидно. Впрочем, это проблемы не ксора, а бесконечной ленты - любой алгоритм на бесконечной ленте неудобен, ни один алгоритм с конечной лентой не криптостоек.Вот мы и вернулись к началу беседы
Что за мания к абсолютизму? Я вот какой аргумент приведу - нет данных, чтобы когда-либо была осуществлена кража данных посредством взлома проверенных современных алгоритмов (истории времён второй мировой или закрытых алгоритмов типа GSM не в счёт). Зато есть данные, что на практике для серьёзного и массового коммерческого шпионажа использовались трояны (относительно недавно крупный скандал был то ли в Италии, то ли в Израиле по этому поводу радиоэлектронный перехват, подкуп сотрудников. Реальность такова, что те самые "некриптостойкие" алгоритмы - самое надёжное звено в цепи безопасности. По крайней мере, нужны очень серьёзные основания, чтобы начать всерьёз беспокоиться насчёт того, что сломают именно алгоритм... Всё равно украдут иными способами, ломается там, где тоньше. "Ваш бизнес ещё не перешагнул отметку в миллиард долларов в год - ну и не волнуйтесь по этому поводу тогда".
>> любой алгоритм на бесконечной ленте неудобен, ни один алгоритм с конечной лентой не криптостоек.
Сам-то понял, что сказал?
Если нам нужно шифровать конечные файлы, бесконечная лента нам не нужна.
Сам-то понял, что сказал?
Если нам нужно шифровать конечные файлы, бесконечная лента нам не нужна.
ессно вообще не понимаю, к чему начали ксор обсуждать - на практике он, конечно, применяется, но явно не в той ситуации, которая интересует автора треда.
И понятное дело, что сошлинжениринг гораздо эффективнее взлома хороших алгоритмов
вообще не понимаю, к чему начали ксор обсуждать - на практике он, конечно, применяется, но явно не в той ситуации, которая интересует автора треда.И понятное дело, что сошлинжениринг гораздо эффективнее взлома хороших алгоритмов
Затраты на вскрытие - это функция, дающая ожидаемое время для вскрытия ключа заданной длины при условии данных затрат на покупку оборудования (ну и современного состояния вычислительной математики и электронной техники). Или наоборот - стоимость оборудования от желаемого времени вскрытия.Это если в лоб ломать, но от этого можно раз и навсегда защититься, выбрав ключ от 128 бит длиной... Но ведь никто не может гарантировать, что не сломают более умным способом... Как оценить стоимость взлома, если не известна технология взлома?
сам отлично понял. Что-то ты агрессивен в этом треде. Бесконечная лента - это название типа ключа. Когда его длина совпадает с длиной сообщения. Разумеется, она вполне конечная.
Реально задача была следующая.
Во-вторых, для поддержки изменения файла ты в любом случае должен запустить утилиту криптования. Почему это не может быть процедура ксорирования - делающая все за 1 проход и имеющая можно сказать аппаратное ускорение в процессоре мне не понятно. Для стойкого ксорирования тебе всего-лишь нужна стойкая последовательность, генерировать которую умеют многие, но сейчас, для указанных размеров файлов ее можно и приготовить заранее.
Поэтому твой тезис о неприменимости безоснователен.
Нормальный уровень подразумевает нормальную постановку, после которой, обычно, и обсуждать особенно нечего.
Имеется текстовый файл, надо написать прогу, которая его шифрует. Каким алгоритмом лучше всего воспользоваться?Поэтому исходная задача тобой неверно сформулирована.
Вкратце - сложность с хранением ключа (с таким же успехом можно уносить в сейф и съёмный диск с файлами) и сложность поддержки возможности изменения файла. Этот метод для шифрования рабочих данных НЕ ПРИМЕНИМ.Во-первых, пароли и ключи тоже где-то надо прятать и я не уверен, что для этого не придется использовать съемный носитель (1024 битный ключ уже не запомнишь но и флешку на 1024 бита ты уже не купишь, а все что реально на рынке (>128 Mbyte) представлено уже может использовано в данной схеме.
Во-вторых, для поддержки изменения файла ты в любом случае должен запустить утилиту криптования. Почему это не может быть процедура ксорирования - делающая все за 1 проход и имеющая можно сказать аппаратное ускорение в процессоре мне не понятно. Для стойкого ксорирования тебе всего-лишь нужна стойкая последовательность, генерировать которую умеют многие, но сейчас, для указанных размеров файлов ее можно и приготовить заранее.
Поэтому твой тезис о неприменимости безоснователен.
Пожалуйста - USD0=RUR0 - алгоритмы типа AES не лицензируются, существуют бесплатные и полностью свободные (не GPL) реализации, ссылки я приводил. Можешь использовать и массу других проверенных алгоритмов.Сколько ты заплатишь программисту для "безопасного" внедрения алгоритма в приложение?
Давайте на нормальном уровне обсуждатьМетоды решения поставленной задачи освещены со всех сторон (не предлагалось, вроде, только использовать встроенные шифрующие средства файловой системы).
Нормальный уровень подразумевает нормальную постановку, после которой, обычно, и обсуждать особенно нечего.
"оптимальное соотношение длины ключа к затратам на вскрытие" - это что тоже строго математическое понятие? Определение в студию.Пьяный штоле?
Затраты на вскрытие - это функция, дающая ожидаемое время для вскрытия ключа заданной длины при условии данных затрат на покупку оборудования (ну и современного состояния вычислительной математики и электронной техники). Или наоборот - стоимость оборудования от желаемого времени вскрытия.
чувак ну ты в натуре читать то умеешь?
при известной технологии вскрытия понятно, что такое "затраты на вскрытие", но я же просил определение фразы написанной в кавычках, т.е. определение "оптимального соотношения..."
обязательно заботайте подпись перед прочтением
я же ясно (более менее) сформулировал в чем тенденция состоит.
Вот прет меня склонность собеседников иногда возражать на то, что автор не писал.
Конечно же я имел в виду только элементарные операции когда говорил про тенденцию.
Разве я где-то утверждал что из этого следует, что ВЕСЬ алгоритм при этом должен давать взаимно однозначную функцию от ключа при любом фиксированном открытом тексте (размером с ключ)?
Просто такая тенденция намекает, что может создатели некоторых алгоритмов стремятся к такому свойству (и может статься, что какой-то из существующих блочных шифров этим свойством обладает). Но я вовсе не утверждаю, что так и есть.
и ничего противоречащего этому я не утверждал
кроме того ясно, что хоть это и "совсем не обязательно", но это и не исключено
так что "суть" какой "проблемы" в этом, мне не очень понятно.
Вот эта формальная криптостойкость в точности равна размеру ключа для любой шифровки только при выполнении указанного мной свойства, в любом другом случае она меньше.
Кроме того вы зря не обратили внимание (или уже забыли) в каком контексте я изначально писал про это свойство: я лишь привел в качестве примера свойство, которым может обладать даже хороший блочный алгоритм для коротких ключей, что предоставит возможность использовать такой алгоритм для "абсолютно крипкостойкого" шифрования одноразовым ключом размером в сообщение и при этом такой алгоритм обладает всеми достоинствами хорошего блочного алгоритма.
Ваши возражения сводятся к тому, что при создании алгоритма, обладающего данным свойством, более вероятно наделать глупостей (т.е. получить алгоритм, уязвимый для известных методов криптоатак чем если просто забить на это свойство. Во-первых это не имеет отношения к тому, что я писал (т.е. принципиальной возможности создать хороший алгоритм). Во-вторых может это и так, хотя мне кажется, что вероятность наделать глупостей одинакова: либо создатели знают типичные атаки и внимательно пытаются исключить их применимость или нет. Конечно соблюдение этого свойства требует много дополнительной работы и не факт, что от него значительная польза, но я о пользе ничего и не говорил - суть того, что я говорил в предыдущем абзаце.
Ваши аргументы не только ничего не доказывают (что вы конечно понимаете но имхо даже ничего не иллюстрируют, либо совсем не относятся к делу.
С каких пор линейность как-то связана с обратимостью по ключу и что такое "обобщенная линейность"?
Какая вообще связь между утверждениями "зашифрования образуют группу" и свойством обратимости по ключу? Если зашифрование у нас функция y=f(x,k то "некое подмножество ключей образуют группу" будет означать: для любых k1,k2 найдется k3 такое, что f(x,k3)=f(f(x,k1k2) (остальными аксиомами можно пренебречь, т.к. если они не выполнены, то данное множество зашифрований легко дополнить до группы, увеличив количество элементов не более чем в 2 раза + 1 - расшифрованиями с теми же ключами и тождественным преобразованием). А свойство обратимости по ключу: для любого x выполнено f(x,k1)=f(x,k2) только если k1=k2. Какая между ними связь? Может вы знаете как дополнить такие зашифрования до группы, кроме группы всех возможных преобразований?
PS: вы отличный собеседник, пишите по существу и без эмоционального поноса. Респект.
Ну как это нет тенденции?а еще можно заметить, что в блочных шифрах обычно используются именно обратимые операции (XOR, ADD, табличная подстановка, циклические сдвиги, перестановки битов, байтов и т.п. а вот необратимые типа OR, AND и т.п. как раз не используются.Нет никакой тенденции. Так - только если смотреть на одном раудне, если же мы берём два раудна, где пусть даже используется один и тот же ключ, то обратимость теряется, потому как для преобразования это не один и тот же ключ, а два разных.
Тенденция однако.
То есть, если у нас для ситуации
я же ясно (более менее) сформулировал в чем тенденция состоит.
Вот прет меня склонность собеседников иногда возражать на то, что автор не писал.
Конечно же я имел в виду только элементарные операции когда говорил про тенденцию.
Разве я где-то утверждал что из этого следует, что ВЕСЬ алгоритм при этом должен давать взаимно однозначную функцию от ключа при любом фиксированном открытом тексте (размером с ключ)?
Просто такая тенденция намекает, что может создатели некоторых алгоритмов стремятся к такому свойству (и может статься, что какой-то из существующих блочных шифров этим свойством обладает). Но я вовсе не утверждаю, что так и есть.
То есть, если у нас для ситуацииясное дело, только формулировку "можно восстановить" лучше заменить на "можно однозначно восстановить", а то просто восстановить его всегда можно (для хорошего алгоритма - за экспоненциальное время).
c_0 = plain text
c_1 = crypt(c_0, key)
по паре c_0,c_1 всегда можно было восстановить key, то совсем не обязательно, что при
c_0 = plain text
c_1 = crypt(c_0, key)
c_2 = crypt(c_1, key)
по паре c_0,c_2 тоже можно восстановить key. В этом суть проблемы.
и ничего противоречащего этому я не утверждал
кроме того ясно, что хоть это и "совсем не обязательно", но это и не исключено
так что "суть" какой "проблемы" в этом, мне не очень понятно.
Какие дополнительные преимущества может принести это свойство? Я не вижу ничего, чем это может быть полезно, с одной стороны, с другой стороны, чтобы добиться этого свойства, нужно специально проектировать алгоритм и налагать дополнительные ограничения на операции, что совсем не тривиально.чисто формально: криптостойкость защиты данного зашифрованного сообщения данным алгоритмом - это логарифм по основанию 2 полного количества ключей, которые могут привести к такому зашифрованному сообщению таким алгоритмом.
Вот эта формальная криптостойкость в точности равна размеру ключа для любой шифровки только при выполнении указанного мной свойства, в любом другом случае она меньше.
Кроме того вы зря не обратили внимание (или уже забыли) в каком контексте я изначально писал про это свойство: я лишь привел в качестве примера свойство, которым может обладать даже хороший блочный алгоритм для коротких ключей, что предоставит возможность использовать такой алгоритм для "абсолютно крипкостойкого" шифрования одноразовым ключом размером в сообщение и при этом такой алгоритм обладает всеми достоинствами хорошего блочного алгоритма.
Ваши возражения сводятся к тому, что при создании алгоритма, обладающего данным свойством, более вероятно наделать глупостей (т.е. получить алгоритм, уязвимый для известных методов криптоатак чем если просто забить на это свойство. Во-первых это не имеет отношения к тому, что я писал (т.е. принципиальной возможности создать хороший алгоритм). Во-вторых может это и так, хотя мне кажется, что вероятность наделать глупостей одинакова: либо создатели знают типичные атаки и внимательно пытаются исключить их применимость или нет. Конечно соблюдение этого свойства требует много дополнительной работы и не факт, что от него значительная польза, но я о пользе ничего и не говорил - суть того, что я говорил в предыдущем абзаце.
Ваши аргументы не только ничего не доказывают (что вы конечно понимаете но имхо даже ничего не иллюстрируют, либо совсем не относятся к делу.
С каких пор линейность как-то связана с обратимостью по ключу и что такое "обобщенная линейность"?
Какая вообще связь между утверждениями "зашифрования образуют группу" и свойством обратимости по ключу? Если зашифрование у нас функция y=f(x,k то "некое подмножество ключей образуют группу" будет означать: для любых k1,k2 найдется k3 такое, что f(x,k3)=f(f(x,k1k2) (остальными аксиомами можно пренебречь, т.к. если они не выполнены, то данное множество зашифрований легко дополнить до группы, увеличив количество элементов не более чем в 2 раза + 1 - расшифрованиями с теми же ключами и тождественным преобразованием). А свойство обратимости по ключу: для любого x выполнено f(x,k1)=f(x,k2) только если k1=k2. Какая между ними связь? Может вы знаете как дополнить такие зашифрования до группы, кроме группы всех возможных преобразований?
PS: вы отличный собеседник, пишите по существу и без эмоционального поноса. Респект.
Вкратце - сложность с хранением ключа (с таким же успехом можно уносить в сейф и съёмный диск с файлами) и сложность поддержки возможности изменения файла. Этот метод для шифрования рабочих данных НЕ ПРИМЕНИМ.:
Во-первых, пароли и ключи тоже где-то надо прятать и я не уверен, что для этого не придется использовать съемный носитель (1024 битный ключ уже не запомнишь но и флешку на 1024 бита ты уже не купишь, а все что реально на рынке (>128 Mbyte) представлено уже может использовано в данной схеме.проблема вообще-то не в съемном носителе, а его размере (который должен быть не меньше размера данных) и в необходимости менять его содержимое при каждой модификации данных, отсюда следует фактическая невозможность чтения и модификации данных многими пользователями. Что им при каждой модификации обновленным ключом обмениваться? Почему им вместо этого обновлениями данных не обменяться?
А с небольшим ключом и нормальным алгоритмом данные шифруются с одним и тем же ключом при каждом изменении, который есть у каждого пользователя. Что тут не понятно?
А насчет единственного пользователя, комментарий -а исчерпывающий.
Поэтому твой тезис о неприменимости безоснователен.хотя тезис и не мой, но надеюсь обоснование уже понятно.
Пусть у нас есть nu(l, t) - функция полезности для длины ключа l (чем меньше, тем лучше) (монотонная, ну и какие-то там ещё на фукцию полезности требования накладывались, не помню уже) и затрат на вскрытие t (чем больше, тем лучше). Ну и функция t(l) - затраты на вскрытие ключа длины l на современном уровне развития криптографии и вычислительной техники (это может быть как время при заданной стоимости оборудования, так и стоимость оборудования при заданном времени, в зависимости от задачи). Тогда sup[l] (nu(l t(l - это оптимальное соотношение затрат на вскрытие и длины ключа.
Я не понимаю, ты хочешь чтобы я тебя прямым текстом нахуй послал что ли? Ну спроси ещё чего-нибудь, определение супремума, например, тогда точно пошлю.
Я не понимаю, ты хочешь чтобы я тебя прямым текстом нахуй послал что ли? Ну спроси ещё чего-нибудь, определение супремума, например, тогда точно пошлю.
nu(l, t) - функция полезности для длины ключа l (чем меньше, тем лучше) (монотонная, ну и какие-то там ещё на фукцию полезности требования накладывались, не помню уже) и затрат на вскрытие t (чем больше, тем лучше).(1) супремум - точная верхняя грань, т.е. по сути некое число, а оптимальное соотношение должно быть условием, накладываемым на размер ключа, чтобы мы могли считать его оптимальным. Ну ладно эту смешную оплошность можно простить, считая, что имеется в виду условие максимальности выражения, которое ты написал под супремумом, а не сам супремум.
.....
Тогда sup[l] (nu(l t(l - это оптимальное соотношение затрат на вскрытие и длины ключа.
(2) само выражение под твоим супремумом: (nu(l t(l - что это вообще за хрень? Скалярное произведение что ли?
и почему у функции nu(l,t) в выражении только один аргумент, если ты сам писал выше, что их 2 должно быть (длинна ключа и затраты). Ну эту еще более смешную оплошность (свидетельствующую о том, что ты вообще не понимаешь смысл того, что пишешь, либо делаешь это с полного бодуна) тоже я допустим прощу, полагая условием оптимальности длинны ключа l условие максимальности функции полезности nu(l,t(l при данной длине ключа (что ты наверное хотел написать, но не получилось).
Вот только фигня в том, что это не ответ на вопрос: и ежу понятно, что функция полезности должна быть максимальна, ответом должно быть каков вид этой самой функции полезности.
довольно естественно считать ее вид например таким
nu(l,t) = t/w(l то есть отношение затрат на взлом к затратам на реализацию:
w(l) - затраты времени/денег/ресурсов на разработку криптосистемы при условии, что система должна работать с заданной производительностью либо просто время работы алгоритмов зашифрования/расшифрования (это всегда не более чем полиномиальная функция, для хорошего симметричного алгоритма - линейная).
t(l) - как ты и сказал затраты денег/ресурсов на взлом при ограничении на время выполнения либо просто время выполнения при данной реализации процесса взлома (а вот эта функция растет экспоненциально для хорошей симметричной криптосистемы, для ассиметричной медленнее - экспонента степени меньше единицы, но тоже очень быстро)
Так вот очевидно, что если взять такую функцию, то полезность будет очень быстро возрастать при увеличении ключа для любого адекватного алгоритма. Поэтому обычно чем больше ключ тем "полезнее", поэтому берут обычно просто алгоритм, который не взломаешь за мыслимое время известными методами.
Я не понимаю, ты хочешь чтобы я тебя прямым текстом нахуй послал что ли? Ну спроси ещё чего-нибудь, определение супремума, например, тогда точно пошлю.
ну просто шедевр за шедевром
до этого твоя речь типа была безгранично вежливой?
походу определение супремума ты и сам то не знаешь ( или тщательно скрываешь это знание
)>> что имеется в виду условие максимальности выражения под супремумом.
После этой фразы продолжать дискуссию я не считаю для себя возможным. Спасибо за экскурс в грубины неадеквата, было поучительно. Спокойной ночи.
После этой фразы продолжать дискуссию я не считаю для себя возможным. Спасибо за экскурс в грубины неадеквата, было поучительно. Спокойной ночи.
>> что имеется в виду условие максимальности выражения под супремумом.да уж конечно
После этой фразы продолжать дискуссию я не считаю для себя возможным. Спасибо за экскурс в грубины неадеквата, было поучительно. Спокойной ночи.
какая нафиг с вами может быть дискуссия,
если вам непонятно, что супремум - это ЧИСЛО, равное (грубо говоря) максимальному значению выражения, написанного под супремумом, на заданном множестве, а вовсе не УСЛОВИЕ его максимальности.
непонимание различия между числом и условием - это наверно офигенные глубины неадеквата, не говоря уже о манере отвечать на пару слов вырванных из контекста, не удосужившись проанализировать даже смысл предложения и тем более текста в целом.
спокойного сна
проблема вообще-то не в съемном носителе, а его размере (который должен быть не меньше размера данных) и в необходимости менять его содержимое при каждой модификации данных, отсюда следует фактическая невозможность чтения и модификации данных многими пользователями.Интересно, а если ключ не хранить, а вычислять? все умеют строить одну и ту же key stream. так зачем хранить весь ключ, когда достаточно знать алгоритм и его seed?
Какие здесь затраты на ключ?
Интересно, а если ключ не хранить, а вычислять? все умеют строить одну и ту же key stream. так зачем хранить весь ключ, когда достаточно знать алгоритм и его seed?во-первых это уже будет не XOR, а другой алгоритм. Такой подход и так применяется, например именно так реализуется шифрование в режиме гаммирования без обратной связи ГОСТ-28147. Только генерится не ключ, генерится гамма (термин такой ключом в данном случае является seed или какая-то часть seed, а генерирование гаммы для данного seed является частью алгоритма шифрования (и конечно этот алгоритм считается известным потенциальному взломщику). Очевидно такой подход не является "абсолютно криптостойким", поскольку его криптостойкость равна не более чем размер seed (а не длине сообщения как требуется для "абсолютной криптостойкости").
Какие здесь затраты на ключ?
во-вторых по прежнему разные (в том числе меняющиеся) данные неразумно зашифровывать с одинаковой гаммой, т.е. с "одной и той же key stream" (надеюсь понятно почему а это значит на диске придется хранить часть seed вместе с данными (а другая часть seed - это ключ причем эта часть seed, хранимая на диске должна меняться при перешифровании с тем же ключом.
Оставить комментарий
Corrector
Имеется текстовый файл, надо написать прогу, которая его шифрует. Каким алгоритмом лучше всего воспользоваться?