Регистрация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/
Т.е. не тупое копирование ТС, хотя судя по скриншотам, гуй точно взять с него же.
Если не перемудрят, то должно взлететь.
Используют как рекламу для своих проприетарных продуктов. Модель разработки без сообщества как у трукрипта.
И ещё Лицензия
Микрософт не просто так свою лицензию изобретал.
"Как вы лодку назовете", как говорится.
комментариев: 11558 документов: 1036 редакций: 4118
Потрясный перечень улучшений.
Процитированный фрагмент говорит об обратном.
Напоминает симптомы №4 и №5. Почему именно 327661? Почему не 94758595474595? Чем больше, тем лучше что ли? В нормальных системах шифрования эти настройки подбираются автоматически таким образом, чтобы на данной марке процессора ключ выводился где-то долю секунды. Кроме того, у юзера всегда есть возможность задать число итераций руками. Насколько мне известно, всё системное дисковое шифрование в Linux и BSD обычно работает по такому принципу (иногда число итераций фиксировано, но всё равно можно задать руками).
бред воспаленного сознания. крипто-контейнер перебором по словарю вскрывать будут на совсем другой машине.
Незаметно, чтобы они хоть как-либо пиарились.
Написано же «For example», а ты наверное уже весь код их поделия успел изучить. Нашел все отличия от ТС и потому торопишься поделиться с людьми своим мнением?
А не важно. Различия не должны быть сильны. Главное — чтобы не приходилось по минуте ждать отработки KDF (открываешь криптотом, созданный на мощной машине, на слабой, и такое бывает), и, в то же время, длительность была максимальной из тех, что не препятствует комфортной работе. При прочих равных, LUKS, созданный на мощной машине, будет более криптостойким, а на слабых машинах этот параметр немного занижается в пользу удобства (быстроты работы).
Вот и SATtva о том же. Выпячивание такие малозначимых подробностей в основной презентационной статье продукта как бы намекает.
Взлетит, когда за этим будут стоять такая же дотошная основательная 100-страничная научная работа, какая
комментариев: 1060 документов: 16 редакций: 32
магические числа 327661 и 655331 — оба простые.
вам и ему место на харбахарбе.
У вас там уже есть 2 лишних инвайта для нас? ☺
комментариев: 1079 документов: 58 редакций: 59
Так же хотел спросить, я что-то упустил из виду, последний аудит кода, на который кэш собирался, как там дела с прогрессом?
Спасибо.
Этот. Там, кстати, даже проще можно было: если область на диске только одна, достаточно воспользоваться cryptsetup'ом, задав ему offset и size. Если областей диска, которые нужно объединить в скрытый раздел, хотя бы две, то тогда да, нужен dmsetup.
По тем причинам, что не опирается ни на что помимо Linux kernel internals.
Вроде ещё давно писали, что явных бэкдров не нашли.
комментариев: 1079 документов: 58 редакций: 59
Сам я давно хочу отказаться от ТС, как используемого по-умолчанию шифровальщика. Потому, что Гость (21/07/2014 00:23) – правильно подметил о научном доказательном подходе.
Но есть загвоздка – передаваемые криптоконтейнеры в некоторых моментах принимающей стороне придется открывать на говновинде, и решение так или иначе нужно кроссплатформенное. В любом случае спасибо за коммент – теперь безотлагательно начну более глубже знакомиться с LUKS.
Это был поверхностный аудит кода, после собирали деньги на детальный.