DiskCryptor - open source программа для шифрования дисковых разделов

Ищу тестеров для опенсорсного проекта. Подробнее - http://freed0m.org/?index=tcwde

 

меня посчитали?

 

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

 

ноутом рисковать не могу, поэтому придётся тестить на страом компе, когда до него доберусь

 

на winxp sp2 работает. 40Гб винт шифровался ~1.5 часа.

 

requiem
Тестили на системном разделе?

 

да. всё нормально грузится. тормозов не замечено.

 

Horosheye delo! Zhal tolko pomoch ne mogu. Ya na Mac OS X.

 

Помочь вы можете дав комментарии к этой реализации PRNG: http://freed0m.org/prng.c
При создании этого PRNG главным требованием является максимально возможный запас стойкости. Так что низкую производительность прошу не критиковать (я это и сам знаю).

 

Ok ya na etot freed0m posmotriu, no... Ochen rekomenduyu moi http://cryptolib.com/crypto/rrand/!

Malenkiy, bistriy... ochen bistriy, a glavnoye cryptographically secure - proveren kak sleduyet. Glavnoye chto yemu ne nado po polchasa razogrevatsa i ne nado usera napriagat. Moi noviy EnRUPT prosche, menshe, bistreye i prochneye, no on yeschio ne opublikovan. Oba ochen pohozhi drug na druga structuroi.

 

Не в обиду будет сказано, но RRAND я бы не стал использовать для генерации ключей. Конструкция не опирается ни на один хорошо исследованый криптопримитив, источник этнропии всего один...
Для чего-либо вроде затирания файлов случайными данными еще можно юзать, для ключей же...
Вдруг завтра выясниться, что выдаваемые им случайные числа на самом деле не так уж и случайны? Зато имеется увереность в том, что свойства хешей достаточно хорошо изучены, и что если с ними будет какая-либо проблема, то мы об этом вовремя узнаем.

 

Posmotrel. Generator svirepiy. Sdelan paranoikom. Takoye ne slomat, no slishkom uzh dorogoi cenoi vsio eto. Medlenno i ogromno. A glavnoye kak raz otsutstvuyet - neprerivniy sbor besplatnoi entropy iz RDTSC. Ya bi vsio eto uskoril i uprostil kak mozhno bolshe, no yesli skorost i razmer ne vazhno, to ya bi po krainei mere ispravil glavnoye - uberi buffer overflow i sobirai po-bolshe besplatnoi entropy:

isprav: rnd_pool[i + n] ^= hval[n];

na chto-to vrode:
rnd_pool[(i + n) % RNG_POOL_SIZE] += hval[n],
* (u_long *) (rnd_pool + (i + n) % (RNG_POOL_SIZE-4)) + (u_long) __rdtsc();

I voobsche perevedi rnd_pool v u_long vmesto u_char, uskor eto kapitalno zabesplatno.

Togda mozhno spat spokoino. XOR ne rekomenduyu potomu chto on slishkom legko zacyclivayetsa yesli na vhode constanta, a ADD budet cherez vse 2^32 elementov prohodit yesli tolko tam ne 0 na vhode. ADD tozhe bijective, no nadiozhneye gorazdo. K tomu zhe v Intel ADD bistreye chem XOR.

A uskoril ya bi eto kak minimum tak:

zameni: sha512_hash(&sha_ctx, rnd_pool, sizeof(rnd_pool))

na: sha512_hash(&sha_ctx, rnd_pool + (i+RNG_POOL_SIZE-96)%(RNG_POOL_SIZE-96), 96); // 96 ili skolko tam maximum bytes kotoriye garantirovanno ne bolshe odnogo bloka hashiruyut

Eto bi uzhe bilo uskoreniye raza v 4, a raznitsi nikakoi. I togda mozhesh pool uvelichit v razmere skolko ugodno bez zamedleniya.

Udachi!

 

Это есть. seed.seed11 = __rdtsc();

Спасибо, полезное замечание.

Я вобще-то бы хотел, чтобы каждый бит выхода rng зависил от каждого бита пула. Оно греет мою параною

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

 

buffer overflow здесь возникнуть не может. переменная i изменяется от 0 до RNG_POOL_SIZE-SHA512_DIGEST_SIZE, а n от 0 до SHA512_DIGEST_SIZE-1
Следовательно индекс не может быть больше RNG_POOL_SIZE-1

 

da ti prav. togda ostav [i + n] kak yest

 

Исходник я не смотрел. У меня вопрос про организацию хранения файлов в зашифрованном томе. Она индексированная или нет?

Скажу упрощенно зачем это надо:
Например, в качестве диска можно использовать удаленный сервер. Так многие бекап хранят, в том числе и я. Бекап может быть несколько десятков ГБ. Я так понимаю, вся зашифрованная информация хранится в одном файле-контейнере (можно хранить каждый файл отдельо, но это не кошерно). Что касается протокола общения с сервером, он должен быть распространенный и безопасный, например, ssh.
Итак. Хотим получить файл "a.txt" - программа скачивает индекс-заголовки (направленный граф для уменьшения трафика), расшифровывает, получает смещение(-я) на файл и скачивает этот кусок.
Такой фичи я еще нигде не видел (исключение - hххp://www.e-nigma.ru/), но там не все бесплатное, да и сервера только их).

 

Odin raz na ves pool ne dostatochno. Eto nichego ne stoit dobavliat v kazhdiye 32-64 bita poola - znachitelniye skachki obrazuyutsa ne tak chasto, no nepredskazuyemo i ih vse mozhno legko lovit postoyannim sborom entropy v prostom cycle.

 

Postaviv sebia na tvoyo mesto, ya s toboi polnostyu soglasen. No ya slishkom horosho znayu kak eto rabotayet. Ya gorazdo boleye paranoid chem ti. Konechno dobavliat razlichniye istochniki tak kak ti eto delayesh dlia inicializacii ili pered generaciyei dolgovremennogo klucha - eto ochen dazhe obiazatelno. No postoyanno ih sobirat - eto bespoleznaya trata vremeni. Yesli ne vozrazhayesh, ya videru tvoi sbor entropy i dobavliu v rrand init chtobi u liudei voprosov bilo menshe. Horosho bi yeschio takoye zhe dlia Mac OS X i dlia linuxov naiti...

No po povodu hash - eto konechno libo dushis zhdi poka SHA-2 dopihtit, libo doveriai avtoru algoritma [v dannom sluchaye mne]. Nadeyus chto kogda moi EnRUPT pobedit v NIST competition na SHA-3, etot vopros budet zakrit.

PS: Ti sobirayeshsa pod Mac OS X eto zaportit? Ochen nado...

 

Это зависит от ФС. Мне вобще пофиг, криптодиск работает уровнем ниже и ничего не знает ни о каких файлах.

Тогда будет закрыт вопрос с доверием к хешу EnRUPT, но никак не к этому коду Вот если вы свой RRAND в стандарт пропихнете, тогда другое дело...

Этот набор функций для сбора энтропии есть только в kernel mode. Для юзермода возьмите примеры из OpenSSL.
И этот набор функций у меня не используется в качестве основного источника этропии, а только в качестве дополнительного модификатора пула. Основной источник - движения мыши собираемые в окне программы и пересылаемые в драйвер (добавляются в пул через rnd_add_buff. Ведь вдруг завтра окажется что возврат этих функций на самом деле не так уж случаен (особенно при частом вызове), а движения мыши используются уже много лет, и никаких нареканий к этому источнику пока не было.

У меня нет ни мака, ни макоси, ни информации о написании под нее драйверов и о процессе ее загрузки. Возможно когда-нибудь такая версия и будет, но в близжайших планах стоит полноценная работа на висте, и возможно поддержка Windows mobile.

 

Потестил на ноуте, платформа Intel Centrino
1.6Ghz,
512mb ram
hdd 60gb

Шифровался системный раздел XP Home SP2, 9Gb, время шифрования 19 мин.

Перегружался многократно, проблем замечено не было.
Скорость загрузки(субъективно), не изменилась