VeraCrypt как замена TrueCrypt


Пишут что базируется на ТС, однако несовместимо с оным по части контейнеров.
Хотят быть лучше оригинала:
For example, when the system partition is encrypted, TrueCrypt uses PBKDF2-RIPEMD160 with 1000 iterations whereas in VeraCrypt we use 327661. And for standard containers and other partitions, TrueCrypt uses at most 2000 iterations but VeraCrypt uses 655331 for RIPEMD160 and 500000 iterations for SHA-2 and Whirlpool.

https://veracrypt.codeplex.com/

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

Комментарии
Гость (20/07/2014 19:16)   

Используют как рекламу для своих проприетарных продуктов[link1]. Модель разработки без сообщества как у трукрипта.
И ещё Лицензия[link2]
Microsoft Public License (Ms-PL)

Микрософт не просто так свою лицензию изобретал.
"Как вы лодку назовете", как говорится.
Гость (20/07/2014 19:27)   
Т.е. лицензию просто взяли и заменили? Чо, нормально так.
— SATtva (20/07/2014 20:48)   
For example, when the system partition is encrypted, TrueCrypt uses PBKDF2-RIPEMD160 with 1000 iterations whereas in VeraCrypt we use 327661. And for standard containers and other partitions, TrueCrypt uses at most 2000 iterations but VeraCrypt uses 655331 for RIPEMD160 and 500000 iterations for SHA-2 and Whirlpool.

Потрясный перечень улучшений.


Процитированный фрагмент говорит об обратном.
Гость (20/07/2014 20:52)   

Напоминает симптомы №4 и №5[link3]. Почему именно 327661? Почему не 94758595474595? Чем больше, тем лучше что ли? В нормальных системах шифрования эти настройки подбираются автоматически[link4] таким образом, чтобы на данной марке процессора ключ выводился где-то долю секунды. Кроме того, у юзера всегда есть возможность задать число итераций руками. Насколько мне известно, всё системное дисковое шифрование в Linux и BSD обычно работает по такому принципу (иногда число итераций фиксировано, но всё равно можно задать руками).
Гость (20/07/2014 21:35)   
В нормальных системах шифрования эти настройки подбираются автоматически таким образом, чтобы на данной марке процессора ключ выводился где-то долю секунды.

бред воспаленного сознания. крипто-контейнер перебором по словарю вскрывать будут на совсем другой машине.
Гость (20/07/2014 21:43)   
Используют как рекламу

Незаметно, чтобы они хоть как-либо пиарились.

Написано же «For example», а ты наверное уже весь код их поделия успел изучить. Нашел все отличия от ТС и потому торопишься поделиться с людьми своим мнением?
Гость (21/07/2014 00:15)   

А не важно. Различия не должны быть сильны. Главное — чтобы не приходилось по минуте ждать отработки KDF (открываешь криптотом, созданный на мощной машине, на слабой, и такое бывает), и, в то же время, длительность была максимальной из тех, что не препятствует комфортной работе. При прочих равных, LUKS, созданный на мощной машине, будет более криптостойким, а на слабых машинах этот параметр немного занижается в пользу удобства (быстроты работы).
Гость (21/07/2014 00:17)   

Вот и SATtva о том же. Выпячивание такие малозначимых подробностей в основной презентационной статье продукта как бы намекает.
Гость (21/07/2014 00:23)   

Взлетит, когда за этим будут стоять такая же дотошная основательная 100-страничная научная работа, какая стоит за LUKS[link5]. См. старое обсуждение[link6] вопроса.
— sentaus (21/07/2014 00:36)   
Судя по комментариям к коммитам, они сейчас всего лишь вычищают код от мелких косяков. Это в целом позитивно, если только вдруг не будет, как в дебиановском openssl.
Гость (21/07/2014 01:15)   
Судя по комментариям к коммитам, они сейчас всего лишь вычищают код от мелких косяков.

магические числа 327661 и 655331 — оба простые.

Вот и SATtva о том же.

вам и ему место на харбахарбе.
Гость (21/07/2014 01:32)   

У вас там уже есть 2 лишних инвайта для нас? ☺
— ressa (10/01/2015 02:39)   
Господа, кто следит за форками TrueCrypt? Какой больше доверия вызывает и по каким причнам?
Так же хотел спросить, я что-то упустил из виду, последний аудит кода, на который кэш собирался, как там дела с прогрессом?
Спасибо.
Гость (10/01/2015 19:36)   

Этот[link7]. Там, кстати, даже проще можно было: если область на диске только одна, достаточно воспользоваться cryptsetup'ом, задав ему offset и size. Если областей диска, которые нужно объединить в скрытый раздел, хотя бы две, то тогда да, нужен dmsetup.


По тем причинам, что не опирается ни на что помимо Linux kernel internals.


Вроде ещё давно писали, что явных бэкдров не нашли.
— ressa (10/01/2015 20:35)   

Сам я давно хочу отказаться от ТС, как используемого по-умолчанию шифровальщика. Потому, что Гость (21/07/2014 00:23) – правильно подметил о научном доказательном подходе.
Но есть загвоздка – передаваемые криптоконтейнеры в некоторых моментах принимающей стороне придется открывать на говновинде, и решение так или иначе нужно кроссплатформенное. В любом случае спасибо за коммент – теперь безотлагательно начну более глубже знакомиться с LUKS.
Это был поверхностный аудит кода, после собирали деньги на детальный.
Гость (10/01/2015 21:01)   

LUKS умеет[link8] TrueCrypt-контейнеры, проблема только с их созданием будет.
— ressa (10/01/2015 21:44)   
TrueCryptOnDiskFormat[link9]
Он же вроде создает, не?
cryptsetup -c aes-xts-plain luksFormat <device>, этот самый xts-plain – не он ли в формате ТС-контейнеров?
Кстати, как бекап заголовка сделать на случай использования luksErase?
— unknown (10/01/2015 22:24)   

Это режим дискового шифрования, а LUKS — это формат заголовков. Само по себе ни то, ни другое не означает Truecrypt.
— ressa (10/01/2015 23:36)   
Спасибо, я сделал ложные выводы по второму предложению.
XTS mode is potentially even more secure than cbc-essiv (but only if cbc-essiv is insecure in your scenario). It is a NIST standard and used, e.g. in Truecrypt. From version 1.6.0 of cryptsetup onwards, aes-xts-plain64 is the default for LUKS. If you want to use it with a cryptsetup before version 1.6.0 or with plain dm-crypt, you have to specify it manually as "aes-xts-plain", i.e.

Подскажи, пожалуйста, по поводу бэкапа заголовка, на случай эрайза контейнера.
Гость (11/01/2015 12:56)   

/comment82437[link10]


luksErase[link11] в моей версии cryptsetup'а нету, поэтому не экспериментировал. По старинке использую -q с luksKillSlot.
— ressa (11/01/2015 16:40)   
Гость, спасибо тебе, как всегда выручаешь и советом и настаалением, ведь приведенный тобой коммент – твой же? Там все понятно и доходчиво, благодарю. Надо бы сюда в черновик или в Руководства запилить по cryptsetup шпаргалку.
Гость (11/01/2015 16:49)   

Приблизительно все комменты на этом форуме мои. :-)


Многие вещи писали in situ, поэтому сыры, неполны и недоработанны. Более того, никто их дорабатывать не будет до тех пор, пока кому-то для личных целей не понадобится что-то существенно большее, чем уже описано где-то на сайте. Впрочем, большинство ваших вопросов по cryptsetup элементарно снимаются чтением man cryptsetup, а также гуглежом по форуму. Например, интересует опция luksHeaderBackup — вводим в гугле «luksHeaderBackup site:pgpru.com» и видим все обсуждения этой опции здесь. Можно и поиском по сайту воспользоваться — для одного искомого слова он худо-бедно приемлемо работает.
— ressa (11/01/2015 17:36)   

Ну в этом я точно не сомневаюсь)
Я так и ищу по pgpru.com, т.к. стандартный поиск мне ни разу не помог.

Ссылки
[link1] http://www.idrix.fr/Root/

[link2] https://veracrypt.codeplex.com/license

[link3] https://www.pgpru.com/biblioteka/statji/hanaanskijjbaljzam

[link4] https://www.pgpru.com/comment40301

[link5] http://clemens.endorphin.org/nmihde/nmihde-A4-os.pdf

[link6] https://www.pgpru.com/comment37379

[link7] https://www.pgpru.com/comment82946

[link8] https://www.pgpru.com/comment73378

[link9] https://code.google.com/p/cryptsetup/wiki/TrueCryptOnDiskFormat

[link10] https://www.pgpru.com/comment82437

[link11] https://code.google.com/p/cryptsetup/wiki/Cryptsetup164