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.

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

Побайтово? Ужас.

imul ★★★★★ ()

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

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

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

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

А как мне на го 64 бита ксорить? У него же бинари являются массивами с байтами

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

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

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

Ксорить с конечным ключём всё-равно небезопасно

Всмысоле, как я вам гаммирование взломаю? 0_o

egorcod ()
Последнее исправление: egorcod (всего исправлений: 1)
Ответ на: комментарий от egorcod

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

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

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

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

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

Я с го поверхностно знаком. Там разве нет 64-битного целого?

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

Там есть uint64 как тип. Но бинарные данные хранятся как массив байтов

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

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

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

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

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

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

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

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

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

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

imul ★★★★★ ()
Ответ на: комментарий от 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 ★☆ ()
Ответ на: комментарий от HIS

Обычно же размеру записи файловой системы.

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

Там даже 128-битными можно оперировать.

И 256, и 512! И все это без библиотек!

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

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

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

Помогут чему?

Числам вмещающим себя больше чем 2^64

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

Прости, а кто ты такой, чтобы решать, что можешь выбросить мои данные?

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

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

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

Прости, а кто ты такой, чтобы решать, что можешь выбросить мои данные?

Не всем нужны твои данные.

goto-vlad ()

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

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

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

imul ★★★★★ ()

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

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

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

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

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

Просто непонятно зачем ты влез первым сообщением. Предполагаю от скудоумия.

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

Я не предлагал симд для ксора. Я предлагал обычний инт64 который есть в проце и без симда.

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

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

cvs-255 ★★★★★ ()
Ответ на: комментарий от 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)
Ответ на: комментарий от vertexua

Неплохо разложило на 256 бит. Надо будет завтра глянуть как в гошном коде у тс соптимизировало.

imul ★★★★★ ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)