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

Может быть надо сравнивать не с c++ компилятором с отключеной оптимизацией, а с си компилятором на полной оптимизации? А то авторы тестов вертят условия тестирования как хотят, лиж бы получить для ихнего любимого дотнета цифру получше. Нене, давайте сравнивать с нормальными языками (с++ нормальным не считается), с нормальными компиляторами (intel c 10), и на нормальных настройках.

 

Ага. А в base64 есть символы, которыми нельзя обзывать файл. Типа \ /. Так что не выход.

 

сделай свой base64 без /\как-нибудь так:

Код (Text):

1. string str = Convert.ToBase64String(data).Replace('/', '-');
2. data = Convert.FromBase64String(str.Replace('-', '/'));

или base62 используй...

 

как вариант имя файла сформировать в виде hex кодов соответсвующих символов:

недостаток очевиден - увеличение длины имени в 2 раза.

 

ntldr
я думаю, с++ попрёт при включении оптимизации кода.

 

Spiteful, там куча подобных символов + разный регистр букв + имя файла увеличивается.
roman_pro, ага, так я и сделал.
Шифрование файлов добавил (TripleDES).

 

А как потом бедному юзеру узнать, где его файл, не читая заголовок каждого файла и не храня все в индекс-файле?
Думаю, получить вывод стандартной команды ls быстрее, чем сначала получить список файлов, а потом читать заголовки каждого. Ваш вариант правильнее, но на формирование списка файлов уйдет бОльшее время.

Представьте тоталкоммандер: два окошка.
В левом - файловая система, в правом - сервер.
В этих двух окнах имена файлов должны быть удобочитаемы.
Также должно присутствовать контекстное меню.

 

имя файла засовыем в заголовок и шифруем вместе с файлом а присваеваем файлу на сервере случайно сгенерированное буквенно -цифровое имя

 

А зачем использовать устаревший алгоритм (3DES), когда есть AES, который "быстрее, выше, сильнее"?

 

flankerx
ноу-хау

 

Длина имени файла ограничена. Представление ее как byte даже не в юникоде значительно ее "раздувает". У стандартного криптопровайдера дотнета какие-то глюки с размером блока в AES. Используя 3DES получилось указать блок меньше.
Сейчас переписываю с с++ алгоритм AES. Посмотрю, насколько скорость возрастет.

 

у 3DES размер блока 64 бита в у AES - 128 бит.

если хорошо напишеш на с++ то возрастет очень сильно. 3DES даже в Си реализации медленнее

 

Как раз так и вышло. Мне главное минимальное отличие в бОльшую строну длины имени файла.

Уже пишу. Напишу на с++ и с# и сравню.

 

Т.е. использовать блочный шифр в режиме поточного (CTR, OFB, CFB) чтобы не "раздувать" зашифрованное имя файла религия не позволяет?

Отличное обоснование выбора алгоритма шифрования!

А готовое оптимизированное взять не пробовал? За тебя уже все давно переписали

 

Не позволяет. В случае потокового шифра можно догадаться о настоящей длине имени файла.

Я только учусь. Опыт как-то надо набирать. Скоро здесь начнут советовать "используй компонент" как в дельфи мля.

 

Предлагаете переписывать криптуху?

 

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

 

Буду благодарен за ссылку на готовое оптимизированное для с#

 

извини, сишарпами не пользуюсь. не моё

[q]Я только учусь.[/q]
Тем более реализовывать крипто самостоятельно не рекомендуется.

Тогда в чем проблема с паддингом до размера блока? размер блока - 16 байт. Если много - используй потоковый режим и руками добавляй паддинг по 4 или 8 байтам. К этим вопросам религия терпима

 

А как тогда криптографию учить? Имхо, практика всегда нужна.