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

Кстати, если Stable поменять на Nightly, опять становится побайтовым loop. Вот это уже забавно, тоже надо будет глянуть

Не успел отредактировать.
Неплохо разложило на 128 (судя по инкрементам на 16) бит. Надо будет завтра глянуть как в гошном коде у тс соптимизировало. А почему не на 256? Регистры xmmX вроде до 256 расширяются.

В ночнушке могли оптимизацию отключить для отладки чего-либо.

Разве что у них на сервере. А то господа бывает продакшн код через nightly собирают. Сейчас уже менее актуально, но все же

кратно записи файловой системы. Современные системы вроде 8 КБайт пишут. Ранее было принято 4 КБайта. Кратно 8КБ не ошибёшься :)

Всем спасибо за приятную тему. Я, увы, спать.

+1

Осиль ман openssl и не занимайся фигнёй.

fn xor_iter(a:&[u8], b:&[u8]) -> Vec<u8> {

Как на этом можно писать? Что за закорючки непонятные? На тебе вот нормальный, понятный код:

template <class T, class = typename std::enable_if<std::is_integral<typename T::value_type>::value>::type> auto xor_iter1(const T& a, const T& b) {
    return ranges::views::zip(a,b) | ranges::views::for_each([](std::pair<typename T::value_type, typename T::value_type> p) { return ranges::yield(p.second ^ p.first); });
}

Вы еще выполните rm и спросите, кто он такой чтобы удалять ваши данные

А мне так удобнее было парсить. Конкретно для этой задачи.

Для максимальной безопасности - да. А что вы собственно хотели от ксор-шифрования?

А при чём тут rm?

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

Это фича не языка, а компилятора. Если бакенд тот же (гцц, шлнг), то на го он сделает ровно тем же образом, а на Го есть бакенд под гцц. Разумеется, это также значит, что и на Сях будет ровно так же соптимизировано.

vertexua

Причём тут вообще «современный язык»?

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

Я бы в случае когда данные больше ключа - делал чтобы программа падала с ошибкой. И добавил бы ключ «-f,–force» чтобы выбрасывать часть

создать два буфера с размером большего файла

Отличная идея для шифрования файлов в 50 гигов на компе с 8-мю гигами.

Привет копетан.
Я где-то употреблял «современный язык»?

где-то употреблял «современный язык»?

Вертексуа: «Го - современный язык, там такой фигней уже не заморачиваются.» Я это ему, а не вам написал, алё.

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

слышь, матрос, зачем собрался смотреть, как у ТС соптимизировано, если заранее понимаешь, что у него будет в точности такой же листинг?

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

И от го, и от раста, и от последних компиляторов плюсов и си можно такое ожидать. Я ещё до того как увидел листинг ассемблера знал что там скорее всего будет

Когда пишу код и хочу увидеть там sse, то пишу адекватный код, иногда смотрю выхлоп ассемблера чтобы проверить, не наоборот - стразу строчить оптимизацию руками. С другой стороны да, так можно словить регрессию

Напомнило как давно в интернете, какой-то школьник предлагал скачать или даже купить его программы на delphi для решения квадратных уравнений.

что вы собственно хотели от ксор-шифрования

Ну вообще, ксор-шифрование - единственный абсолютно стойкий шифр

mmap()

Не всем нужно ксорить файлы в 50 гигов.

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

какая разница есть есть mmap() который за тебя всю работу сделает?

Можно и так, да.

Ну да.
Я про ненужность в принципе. Хотя хз, используется ли где «одноразовый блокнот» в реальных боевых условиях

Шифровать центральные процессоры и прочие не совсем законные данные, возможно

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

Кому не интересно - мимокрокодил к уже сделанным м оттестированным тулзам общего назначения.

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

Сочувствую.

Если выставить оптимизацию (O1 и больше) то оно даже не генерит код функции, сразу все считает.

Я inline(never) ради спорта поставил в код

Чтобы увидеть htop, словить инфаркт и кричать что хром выжрал всю память?

Чтобы увидеть htop, словить инфаркт и кричать что хром выжрал всю память?

Виртуальную память, Карл!

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

Можно даже прямо указать что ты будешь читать последовательно с помощью madvise().

Зачем нужно форсировать свопирование , если можно обойтись вовсе без него.

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

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

Заглянул одним глазом в сырцы. Какой ужасный гомнокод!

Не делай так больше, пожалуйста. И твоя «крипта» ломается скорее всего на раз-два.

Ну xor сложно накосячить, разве что ключ реюзать. Он этого строго не делает. Пользователь может, да

Меня уже убил разбор ключей (закат солнца в ручную) вместо flag.

Дальше даже смотреть не стал. Ибо одна большая простыня и 146% ключ там ре-используется.

Я уже ныл на первой странице

Есть такая штука в теории шифрования:

Если не известен тип информации пароль (хешкод) - то расшифровать практически невозможно.

Это касается «почти» и 1 байтного ксор шифрования.

А если оно будет 8 байтным... :)

Nuff said: https://crypto.stackexchange.com/questions/59/taking-advantage-of-one-time-pad-key-reuse

Я не про ассиметричное шифрование.

Я про тупой ксор набором нескольких байт.

Если без шуток, то в треде таки обсуждается симметричное шифрование, оно в корне отличается от всяких ssl…

Оно в принципе даже более надёжное, если не «палить» свой пароль. Файлы зашифрованные симметричным методом предполагают только личное использование без передачи третьим лицам вместе с паролем.

В flag можно указать один и тот же ключ несколько раз?

Можно.

package main

import (
	"flag"
	"fmt"
)

type multi []string

func (m *multi) String() string     { return fmt.Sprint(*m) }
func (m *multi) Set(s string) error { *m = append(*m, s); return nil }

func main() {
	var m multi
	flag.Var(&m, "m", "multiple arg")
	flag.Parse()
	fmt.Println(m)
}

И пример:

go run main.go -m a -m b
[a b]

Окей, не знал. Пойду исправлять

madvise + MADV_DONTNEED

Если я запускаю программу как

./xorf -k key file

То flag парсит это как

keys: [key]
files: [file]

Но если я запускаю программу как

./xorf file -k key

То flag парсит это как

keys: []
files: [file -k key]