Хранение шифрованных данных на удаленной машине

Хм. Вот зашифрованное имя файла: 3A6665B776 (5 БАЙТ). Как я понял, совет вручную выровнить по x4 БАЙТ, то есть в данном случае - до 8 БАЙТ. Получится что-то вроде 3A6665B776000000. Или же наоборот: alg.c (5 байт) доводим до alg.c__ и шифруем.
Теперь нам его надо расшифровать... И?
Если нигде не хранить информацию о количестве выровняющих байт (помните, что в шифрованных именах файлов должны присутствовать только x00-xFF, на 1 байт шифра), снова приходим к блочным шифрам.

Представим, что будем хранить информацию о количестве выравнивающих символов в конце имени файла. Даже договоримся, что это число не может быть больше 1 символа в имени шифрованного файла (выравнивание маленькое: явно не более 9):
3A6665B77635A9B53 (для наглядности показал расшифрованный конец)
Ага. Теперь мы можем нормально расшифровывать имена файлов.

То есть вы хотите сказать, что нет шифров с длиной блока 2-4-8 байт и надо использовать такой анонизм?
Или есть?

 

2-4 невидал... 8байт = 64бита очень много есть 3des, blowfish, cast, idea...

насчет выравнивания: забивай нули после последнего символа имени файла и шифруй! это лучше alg.c__ потомучто 0 считается концом строки и ненада хранить количество добавленных байт.

 

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

МК - мастер ключ 512 бит, генерится вместе с ключами RSA во время регистраци юзера на сервере, и, также как и приватный ключ RSA, шифруется паролем по PKCS 5 и хранится на компе юзера.
СК - сеансовый ключ 512 бит, генерится для каждого файла который заливается на сервер
E(x, k) - операция шифрования x алгоритмом Blowfish ключем k

1) при заливке файла на сервер его имя, дополненное 8 случайными байтами, шифруется ключем МК:
E(File_name + RND, MK) = EN

2) вычисляется SHA-256 хеш файла:
H(File)

3) генерится СК и с его помощью шифруется сам файл и его хеш:
E(File || H(File), CK) = EF

4) СК шифруется ключем МК:
E(CK, MK) = EK

на сервер передается:
EN || EK ||EF

также на сервере можна создавать дерево папок для файлов.

как вам такая схема?? есть ли в ней недостатки?

 

Сейчас делаю для себя подобную утилитку для бекапов.
Тоже слева локальные файлы, справа удаленные. Нужные файлы/каталоги сжимаются ZIPом локально, им же шифруются (AES-256) и отправляются на сервер по FTP.
Спрашивается, нафига козе баян?

 

нафига тогда весь криптософт если можно все шифровать ZIPом? ))) врядли у всех есть свой ftp-сервер...

 

дописал ))) http://www.cipherwall.com - качаемс)

 

Даже не ftp... соединение по ssh ведь.
А с тем, чтобы удобнее управляться с ними. В моей схеме есть

1. <расшифрованный_файл>
|
2. <передаваемый_в_шифрованном_ssh_туннеле_зашифрованный_файл>
|
3. <зашифрованный_файл_на_сервере>

Информация же передается по сети. В случае с архиватором пункты 2 и 3 равнозначны - файл-то по ftp передавать собрались.
В моем случае при перехвате сетевого соединения "от тебя к провайдеру" перехватчику попадет не тот файл [попадет шифрованная сессия - пункт 2], что упадет на твой сервер [пункт 3]. Эту сессию можно [честно] расшифровать только имея доступ к серверу. А файлы - только имея доступ к твоему компьютеру, потому что шифрование файлов симметричное и ключи по сети не передаются ни в каком виде.
Как бонус - шифруются имена файлов.
Программку я погонял - у меня пока без глюков лежит около 1ГБ разных файлов.
Если кому интересно: http://crypt.netcode.ru/ (исходники на сайте не светятся http://crypt.netcode.ru/downloads/Remote_DCryptSRC.7z)

 

Кстати, если файл зашифрован, то разницы никакой, передаете вы его по открытому каналу (FTP) или по шифрованному (SSH). У вас шифрованный файл + SSH = масло маслянное (не учитывая авторизацию на сервере).

 

а смысл шифрованый файл передавать по шифрованому каналу??
у меня например в программе используется "смешаный" режим передачи пакетов
тоесть шифрованый файл передается на сервер но в пакетах шифруются только их заголовки +
контролируется целосность потока с помощью HMAC.

 

Если будет установлено, что переданный по сети файл и лежащий на сервере идентичны, то можно предположить, с какого компьютера это было сделано.
Например, по закону каждый провайдер загибает свой канал в здание городского ФСБ.

 

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

 

Само собой. В моем случае стояла задача скрыть логин-пароль, ssh был выбран из-за простоты реализации и возможности использовать простой виртуальный хостинг. Ведь чтобы поставить свой обслуживающий сервер нужен уже vds или dds, а это бОльшие затраты.

 

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

Реализованные алгоритмы:
- 3-step X.509 authorization
- RSA with keys length up to 4096 bits
- AES and Twofish in a cascade with two independent 256-bit keys are used for symmetrical encryption (CFB mode)
- SHA-256 and SHA-512 hash functions
- HMAC based on SHA-256
- modified ANSI X9.17 random numbers generator
- PKCS 5.2 with 2000 iterations
- supports additional "corporate" keys
- DoD-5220.22-M and Peter Gutmann's algorithms are used for data wiping (NTFS streams are also wiped).

Скачать:
http://www.cipherwall.com/safecli.zip

Исходный код клиента пока не оформлен нормально, но могу отправить если кому интерессно.

 

Вот это:
- modified ANSI X9.17 random numbers generator
СИЛЬНО смущает.

 

ну в стандарте используется DES а у меня AES+Twofish... уже modified на самом деле он не принципиально изменен... ну например в стандарте на вход подается текущая дата в 64-битном представлении а у меня хеш даты. а так впринципе все по стандарту.