трансформатор aont

[nsg21]

Написал небольшую программку для разделения секретного файла на несколько частей. Лежит на http://nsg.upor.net/sys/win/aont.htm , описание (на английском) -- там же. Основана на преобразовании типа "или-всё-или-ничего". (Преобразование не содержит секретной информации, типа пароля, и может быть легко обращено, но только при условии что доступны все байты. Если хотя бы часть преобразованного файла отсутствует или повреждена, то оставшаяся часть не может быть восстановлена даже частично.)

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

Изначально я думал использовать для этого отдельную уже существующую утилиту (cut) с последущей склейкой частей с помощью "copy /b a+b+c d". Но это оказалось не совсем то. Во-первых, cut не умеет делить на несколько неравных частей. Я даже было написал свою утилиту (usplit, unequal split) как раз для этого. Но тут-то и выяснилось, что, во-вторых, использование двух команд для одной операции очень раздражает. Так мне пришлось вставлять операции разделения результата на части и склейки их при обратном преобразовании непосредственно в aont.

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

В общем, неинтеллектуальная часть занимает большую половину, всё как обычно.

Comments

[blk-104.livejournal.com]

Прочитав описание на твоём сайте, я понял, для чего такое может понадобиться :)

[nsg21.livejournal.com]

Это ты про раздел Use modes?

[blk-104.livejournal.com]

Да.

[garalex.livejournal.com]

при использовании "Long term storage", чем это будет принципиально лучше или удобней простого шифрования (ключ на флешке, шифрованные данные в открытом хранилище) ?

[nsg21.livejournal.com]

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

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

Я, собственно, и не утверждаю, что произвёл революцию в деле long term storage. Просто интересная опция. Попробовал -- вроде удобно. Надо дальше смотреть.

[garalex.livejournal.com]

а как бить файл на маленький и большой (приведи пример строки)? а если сразу кучу файлов - можно?

[nsg21.livejournal.com]

aont /n:5 fin2005.zip

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

aont /n:5 /s:1k fin2005.zip

разобьёт на пять частей, первые четыре по 1k, остаток в последний файл.
Если файл меньше 5к, то частей будет меньше.

Если не указывать имя выходного файла, то оно просто приписывает суффикс: fin2005.zip.part1 fin2005.zip.part2 и так далее.

Кучу файлов можно for %f in (*.zip) do aont /n:5 /s:1k %f
или как-то так. Вообще я не придумал как удобно указывать несколько файлов на входе. Непонятно как для них всех указать выходное имя. Можно специальный случай, если нет выходного имени, то как в вышенаписанном for.
Ещё труднее с обратным преобразованием, как указать много частей разных файлов и при этом сказать чтобы каждый восстанавливался в своё место? Почти в каждом конкретном случае можно for написать, особенно с новыми виндовскими модификаторами типа %~dpfF. Типа.

for %F in (*.part1) do aont /r %~fF.part* %~fF

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

[garalex.livejournal.com]

раз оно у тебя умеет файлы по умолчанию генерить при шифровании, точно также должно и при расшифровке - искать само с именем .part1... partN.
потом.. ты бьешь на примерно равные куски? и чтоб разбить на неравные "подбирать" размер куска. Но одно из использований - это именно получить один из кусков маленький (для флешки) - почему не задать размер самого маленького куска, а остальные чтоб были поровну? т е - /n:5 /m:1k ---> значит разбить на 5 кусков, при этом один из кусков сделать ровно 1кб (один!)

[nsg21.livejournal.com]

Оно и ищет если сказать name.part*. Или ты предлагаешь, если указать "aont /r имя", а такого файла нет, то оно считает что "имя" -- это выходной файл, а входные "имя.part*"? Это интересная мысль.

Про разбивание на куски я представляю что основной режим -- один или несколько маленьких кусков и один большой. Маленькие -- это как бы ключи, их можно копировать в разные нычки в разных сочетаниях, а большой лежит на открытом сервере. Частный случай /n:2 /s:64 -- однин маленький на флешку, один большой на сервер. А зачем разбивать большую часть на примерно равные я не совсем понимаю.

[garalex.livejournal.com]

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

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