LINUX.ORG.RU
ФорумTalks

xorf - простая тулза для XOR-шифрования файлов

 , ,


1

1

Смотрите, какой ненужный велосипед запилил:

xorf - простая тулза для XOR-шифрования файлов. Пример использования:

# Зашифровать файл text.txt, используя ключи из файлов key1 и key2:
$ xorf text.txt key1 key2 > encrypted1.txt

# Начать генерировать новый ключ, зашифровать им файл encrypted1.txt, записать ключ в файл key3
$ xorf encrypted1.txt -k key3 > encrypted2.txt

# Для того чтобы расшифровать encrypted2.txt, нам понадобятся все ключи:
$ xorf encrypted2.txt key1 key2 key3 > decrypted.txt

# Теперь text.txt и decrypted.txt - одинаковые файлы:
$ cmp text.txt decrypted.txt

Ключом может выступать абсолютно любой файл, хоть /dev/urandom, хоть фильм в формате mkv.

Если кому-то ВНЕЗАПНО эта шняга понадобится, держите.


Поцаны не кочайте мне весь диск зашхорило!212

Deleted
()
Ответ на: комментарий от egorcod

А я и не спорю. Ксорить с конечным ключём всё-равно небезопасно. Про это у Шнаера хорошо разжовано было много лет назад. Но байтово это просто задница в плане скорости. Перепиши хотя бы на 64 бита, можно будет сразу 8 байт обрабатывать.

imul ★★★★★
()
Ответ на: комментарий от imul

Потестил сейчас на очень слабом компутере, 1 гигабайт параллельно с генерацией ключа ксорится 2.5 минуты. Мда, слабовато

egorcod
() автор топика
Ответ на: комментарий от egorcod

dd из /dev/urandom пишет гигабайт за 25 секунд

egorcod
() автор топика
Ответ на: комментарий от egorcod

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

imul ★★★★★
()
Ответ на: комментарий от imul

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

xorf обрезает данные под размер самого маленького источника. Если ключ будет меньше данных, он обрежет данные

egorcod
() автор топика
Ответ на: комментарий от egorcod

В смысле обрежет данные? Начало поксорит, а потом пойдёт нексоренное? Или речь идёт о периодическом применении того же короткого ключа? Так это смысла не имеет. Как только в данных попадется блок с нулями длиной более ключа, то ключ находится из шифрованных данных поиском цикличных повторений. Если не нули, но одинаковые числа, то есть всего 256 вариантов ключа.

imul ★★★★★
()
Ответ на: комментарий от imul

Он обрежет данные под размер самого маленького источника. Ключ больше данных - он обрежет ключ. Данные больше ключа - он обрежет данные.

egorcod
() автор топика
Ответ на: комментарий от egorcod

Массив байт ничем не отличается от массива 64-битных интов, кроме выравнивания на 8. Забей на го, пиши на си. Там даже 128-битными можно оперировать.

imul ★★★★★
()
Ответ на: комментарий от egorcod

Зачем ты повторяешь одно и то же? Хочешь я опять напишу, что ключ короче данных — очень плохой для ксора? Я же даже объяснил почему. При этом ключ тебе надо где-то хранить. Но, лучше хранить затравки для функции гаммирования.

imul ★★★★★
()
Ответ на: комментарий от egorcod

Си — это самое простое, Керниган&Ричи прочитываются за 3-4 часа. На гошку будет очень похоже.

imul ★★★★★
()
Ответ на: комментарий от imul

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

egorcod
() автор топика
Ответ на: комментарий от imul

Ну, будет время, когда-нибудь поучу

egorcod
() автор топика
Ответ на: комментарий от egorcod

Как я из того, что ты обрезаешь данные должен понять, что ты не используешь ключ размером меньше данных. У тебя есть 1кб данных. Ключ у тебя 512 байт. Ты обрезал данные на 512 байт и поксорил. Что дальше со следующими 512 байтами?

imul ★★★★★
()
Ответ на: комментарий от egorcod

Тебе нужно зашифровать 1 гигабайт. Ты генерируешь 3 ключа по 1 гигабайту, ксоришь и хранишь уже 4 гигабайта? В код не смотрел, с телефона не очень удобно.

imul ★★★★★
()
Ответ на: комментарий от egorcod

Я это учел. Иначе было бы 5.
А какой смысл ксорить трижды? Почему не дважлы я прекрасно знаю, но зачем трижды?

imul ★★★★★
()
Ответ на: комментарий от egorcod

Просто при доказанном отсутствии периодичностей в ключе более одного раза ксорить смысла нет. Но это больше требование к функции гаммирования. А по другому обычно никто и не делает именно из-за необходимости хранения ключей. Так что программа нужнее не станет. А в качестве тренировки прекрасно. Если ещё и обрабатывать сразу по 64 бита, то будет хороший опыт.
Завтра доберусь до компа и скину тебе бенчи реализации кузнечика для 8 битной и 128 битной реализации. Это переделанная реализация Сааринена. https://github.com/mjosaarinen/kuznechik?files=1 — можешь сам оригинал собрать и погонять бенчи и оценить как размер обрабатываемых зараз данных влияет на скорость.

imul ★★★★★
()
Ответ на: комментарий от imul

А ещё буферы для входящего и выходящего стримов сделать 8 КБ или больше но кратные 8. Тоже полезно для скорости чтения записи.

HIS
()

Побайтово? Надо тебя ремнем выпороть. По яйцам.

kirk_johnson ★☆
()
Ответ на: комментарий от Deleted

Помогут чему? Быстрее работать точно не будет. В примере же сразу шлёпается 128 бит если есть нужное расширение команд в проце.

imul ★★★★★
()
Ответ на: комментарий от Deleted

Речь про быстродействие, а не про сахарок. Если у тебя есть абстракция работающая с 512-байтными числами, реализованная внутри через байтовые операции, то и работать она будет со скоростью как байтовая реализация, сколько щёк не надувай.

imul ★★★★★
()

@egorcod а почему бы тебе в свою программу шифрование перемешиванием не добавить?

torvn77 ★★★★★
()
Ответ на: комментарий от goto-vlad

Лучше сказать, что данные вообще мало кому нужны. Поэтому самые полезные команды rm и shred.

imul ★★★★★
()

Позабавило как в треде ускоряли с помощью SIMD xor файлов… считанных с диска. Ах ну да, все прямо их tmpfs будут xorить данные в 1 TB

Парсить ключи командной строки библиотекой не солидно, автор?

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 2)
Ответ на: комментарий от imul

Так если у тебя 8 битный мк то и 32 бита не будет, и 16. Не понял вообще че ты хотел мне сказать.

Deleted
()
Ответ на: комментарий от imul

Го - современный язык, там такой фигней уже не заморачиваются. Вот побайтовый код (в Го, уверен то же самое)

fn xor_iter(a:&[u8], b:&[u8]) -> Vec<u8> {
    a.iter().zip(b).map(|(av, bv)| av ^ bv).collect()
}

Ссылка

https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=74c5c9432e9adf2982f9dc022f125061

Нажимаем «…» -> Show Assembly

.LBB9_11:
	movups	(%r13,%rdx), %xmm0
	movups	16(%r13,%rdx), %xmm1
	movups	(%r12,%rdx), %xmm2
	xorps	%xmm0, %xmm2
	movups	16(%r12,%rdx), %xmm0
	xorps	%xmm1, %xmm0
	movups	%xmm2, (%rax,%rdx)
	movups	%xmm0, 16(%rax,%rdx)
	movups	32(%r13,%rdx), %xmm0
	movups	48(%r13,%rdx), %xmm1
	movups	32(%r12,%rdx), %xmm2
	xorps	%xmm0, %xmm2
	movups	48(%r12,%rdx), %xmm0
	xorps	%xmm1, %xmm0
	movups	%xmm2, 32(%rax,%rdx)
	movups	%xmm0, 48(%rax,%rdx)
	addq	$64, %rdx
	addq	$2, %rdi
	jne	.LBB9_11
	testq	%rsi, %rsi
	je	.LBB9_14

SSE инструкции и никаких танцев с бубном.

Вишенка на торте, если переделать с u8 на u64 - тот же ассемблер.

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 4)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.