Вложенные криптоконтейнеры

[gliderexpert]

У LUKSа этот CBC (если принудительно включить его) имеет блок длиной 512 байт, тоже особого смысла нет.
А по умолчанию вообще используется CTR.

Получается что идеальный вариант - LUKS на весь том, а внутренние маленькие контейнеры шифровать в режиме CBC, используя размер блока = размеру контейнера?

 

[DoppleKSE]

У LUKSа этот CBC (если принудительно включить его) имеет блок длиной 512 байт, тоже особого смысла нет.
А по умолчанию вообще используется CTR.

Получается что идеальный вариант - LUKS на весь том, а внутренние маленькие контейнеры шифровать в режиме CBC, используя размер блока = размеру контейнера?

Лучше не лезть в размер блока и оставлять его дефолтным, для AES-256 это 32 байта (256 бит)

 

[gliderexpert]

извиняюсь, я не точно выразился - размер блока у aes-шифра понятно что 32 байта, это не трогаем - но когда включаешь режим CBC, лукс использует вот эту длинную цепочку из блоков только внутри сегмента (хз как назвать) в 512 байт (то есть длина цепочки всего 16 раундов), а по идее она должна быть размером с шифрованный том.
В целом это понятно, т.к. если том например 10тб - при изменении хотя бы одного бита, придется переписывать все 10тб.

Но, можно создать несколько маленьких контейнеров, и для самых важных из них включить CBC, у которого цепочка имеет длину равную размеру контейнера.

В общем спасибо за интересную информацию про режимы, буду разбираться.

 

[drpalpatine]

In general, this is understandable, because if the volume is, for example, 10tb - if you change at least one bit, you will have to rewrite all 10tb.

actual not --> AES is not designed for availability only for confidentiality+integrity
it will only affect corresponding block in encrypted data + max few blocks (chaining effect)

example --> 10tb encrypted volume (block size-->16 bytes)
modified block --> suppose block X, XOR inside CBC mode --> change propagates through subsequent blocks (only few blocks mostly)
--> suppose block X at position N --> for next plaintext block N+1, he is XOR with ciphertext block N before encryption --> since only one bit in block X was modify --> XOR only affect corresponding bit in ciphertext block N
--> same with N+2, N+3 ...
*** but far down effect decreases --> diffusion effect by XOR spreads out the changes --> but does not affect all blocks equally


worst case --> one bit change == all subsequent blocks to change --> but very rare, also depend on encryption mode + position of changed bit inside unencrypted data

 

[Whisper]

Идеальное решение задачи.
Предположим что наш противник обладает такими мощностями что ломает любой пароль за секунду.
Математически это возможно потому что пароль не может быть бесконечно разнообразным.
Из этого следует что мы не можем защитить наши данные паролем, нам нужно что то что дает бесконечное количество вариаций и что невозможно брутить по определению.
Брутить можно любой известный криптоалгоритм и даже их комбинации с условием что мы ограничим их конечным числом, это число лего посчитать исходя из характеристик железа, не получится навесть миллион идущих подряд aes, точнее получится но это будет не жизнеспособно с точки зрения производительности.
Таким образом противник брутит любой - кллюч, алгоритм, комбинации алгроритмов.
Невозможно брутить неизвестный алгоритм так как их может быть бесконечно много.
Практические действия, мы будем заливать на наш серв не только пароль но и комбинацию из известных проверенных алгоритмов и 1 свой никому не известный, это может быть например так - aes, свой, туфиш, aes. Мы не можем доверится чисто своему алгоритму(пусть это будет например обычный aes в который мы накинули пару дополнительных ксоров) в соло, так как не можем качественно оценить его стойкость, но нам это и не важно, криптостойкость(идеальную энтропию данных) обеспечат проверенные алгоритмы а наш обеспечивает невозможность брута.

 

[benjaminhustlin]

Идеальное решение задачи.
Предположим что наш противник обладает такими мощностями что ломает любой пароль за секунду.
Математически это возможно потому что пароль не может быть бесконечно разнообразным.
Из этого следует что мы не можем защитить наши данные паролем, нам нужно что то что дает бесконечное количество вариаций и что невозможно брутить по определению.
Брутить можно любой известный криптоалгоритм и даже их комбинации с условием что мы ограничим их конечным числом, это число лего посчитать исходя из характеристик железа, не получится навесть миллион идущих подряд aes, точнее получится но это будет не жизнеспособно с точки зрения производительности.
Таким образом противник брутит любой - кллюч, алгоритм, комбинации алгроритмов.
Невозможно брутить неизвестный алгоритм так как их может быть бесконечно много.
Практические действия, мы будем заливать на наш серв не только пароль но и комбинацию из известных проверенных алгоритмов и 1 свой никому не известный, это может быть например так - aes, свой, туфиш, aes. Мы не можем доверится чисто своему алгоритму(пусть это будет например обычный aes в который мы накинули пару дополнительных ксоров) в соло, так как не можем качественно оценить его стойкость, но нам это и не важно, криптостойкость(идеальную энтропию данных) обеспечат проверенные алгоритмы а наш обеспечивает невозможность брута.

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

 

[Whisper]

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

Правельный вопрс ухудшит ли свой алгоритм энтропию данных, я об этом написал что мы свой непроверенный алгоритм защищаем проверенными. Важно понимать что _НАШ__ДОПОЛНИТЕЛЬНЫЙ_ алгоритм не может ухудшить энтропию по определению, все что он может ухудшить это производительность системы и при этом не улучшить криптостойкость, это максимальный вред который он может нанести.

 

[benjaminhustlin]

Правельный вопрс ухудшит ли свой алгоритм энтропию данных, я об этом написал что мы свой непроверенный алгоритм защищаем проверенными. Важно понимать что _НАШ__ДОПОЛНИТЕЛЬНЫЙ_ алгоритм не может ухудшить энтропию по определению, все что он может ухудшить это производительность системы и при этом не улучшить криптостойкость, это максимальный вред который он может нанести.

Так в твоем решении и вся красота, что комбинация алгоритмов, стандартных и кастомных грузится вместе с паролем, и насколько я понял то, какие именно эти алгоритмы дешифровщик может только предполагать. При расшифровке опираться он будет на стандартные, и вопрос мой был чисто в теории возможно ли свести задачу декрипта модификаций, например, того же AES к однообразному алгоритму, вне вопроса о криптойкости.

 

[Whisper]

Хочу сделать важное уточнение.
В любом деле есть стратегия которая определяет в общих чертах как мы будем это дело разрешать, и есть тактика которая уже определяет как именно будут реализованы те или иные элементы стратегии(например выбор алгоритмов). Я предлагал именно стратегию, все упоминания криптографических алгоритмов были не более чем допущениями. Просто тактику диктует именно стратегия а с ней пока что не определились, как я вижу. Не всем понятно что - стратегия для цели, тактика для стратегии, непонимание этой иерархичности нередко приводит к ненужным спорам.

 

[Whisper]

Так в твоем решении и вся красота, что комбинация алгоритмов, стандартных и кастомных грузится вместе с паролем, и насколько я понял то, какие именно эти алгоритмы дешифровщик может только предполагать. При расшифровке опираться он будет на стандартные, и вопрос мой был чисто в теории возможно ли свести задачу декрипта модификаций, например, того же AES к однообразному алгоритму, вне вопроса о криптойкости.

Задача криптоалгоритма в том что бы на исходные данные с условно низкой энтропией накладывать высокую энтропию ключа.
Теперь давайте предположим что у нас есть данные до крипта 12345, мы их закриптовали и получили 0xacf154e032. Все что есть у нашего противника это 0xacf154e032, он не знает алгоритм наложения ключа и не знает ключ, и не знает исходные данные. И вот он допустим имея супер мощности брутфорсит алгоритм и ключ в результате получает 56789 - как ему оценивать это был успех или нет? Если у вас бесконечный простор в выборе алгоритмов то вы любой мусор можете расшифровать во что угодно.
По поводу сокращения формул. Если ваша формула это (((x + 1) +2) +3) то да сократить ее можно в x + 6, есть ли среди бесконечного количества алгоритмов который вам позволит сократить (((x aes key1) twofish key2) serpent key3) - да есть, потому как в бесконечном количестве возможных алгоритмов есть все возможные алгоритмы, надо только хорошо поискать

 

[benjaminhustlin]

Подозреваю, наш теоретический дешифровщик, взламывая этот супер-секретный контейнер параллельно получит и все секреты вселенной в виде простого текста, залипнет да и плюнет на это дело )

 

[Maxik2005]

двойной крипт, как минимум, снижает вероятность взлома через бэкдор в системе шифрования, который там может быть или может появиться в будущем. и если не считать поверхности атаки, у меня нет оснований думать, что такой способ хоть как-то ослабит защиту данных (не твою защиту перед судьёй или бутылкой, а именно защиту данных).

из практики на сегодняшний день известно только об одном средстве шифрования, об которое все копы обломали свои зубы - это старый добрый трукрипт. я не говорю, что остальные средства априори не секурные. но не стоит на них полагаться на все 100%, пока они не подтвердят свою надёжность в реальном бою с паяльником. про LUKS1 кста в соседней теме уже было обсуждение, там же есть линк на ресерч и инфа по взлому такого диска. и так же учитывай, что с серверами всё намного сложнее, чем с устройствами, к которым у тебя есть постоянный физический доступ.

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

но в целом тема скатилась и уже походит на очередную попытку воссоздать хранилище из фильма миссия невыполнима )) и исходя из моей лично практики, обычно все подобные истории юзеров, которым нужно "аир гэп, 100500 шифрований и хуниксов с защитой от спутниковых атак" заканчиваются словами "чё то я заебался, сделай мне дёдик с виндой десяткой, поставь веракрипт и отключи ТОР, а то инет медленный пздц, пацанам невозможно работать."

 

[registrant]

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

 

[Veil]

Есть тут люди которые на практике сами пробовали ломать Veracrypt

Я не ломал.Но как то пришлось почитать про Верукрипт. После прочитанного понял, что ставить нужно, хрен сломаешь. С любым алгоритмом шифрования взломать невозмжно. Если принимать кой какие меры предосторожности.

 

[Dread Pirate Roberts]

Имеет ли смысл создавать вложенный контейнер Veracrypt - это улучшит криптостойкость, или ухудшит?

точно не знаю, но сам так делаю. только использую Truecrypt вместо Veracrypt.

Hot-plug PCIe+DMA attack not work in modern (2012 year +) hardware.

а Cold-plug?

Дает Вера 3Гиб/сек допустим на AES'е, дает LUKS ну допустим 1,5Гиб/сек для примера (я хз сколько даже усредненно), будет у тебя максимум 1,5Гиб/сек в идеальных условиях, по факту столько же или чуть меньше. Настало время жесткого диска - мы уперлись в его скорость в 100Мб/сек в среднем для HDD или 800 Миб/сек.

ты перепутал названия размерностей, Гб/Gb - гигабиты, ГБ/GB - гигабайты (гигабайт от маркетолуха размером 1000 мегабайт), ГиБ/GiB - гибибайты ("честные" гигабайты по 1024 мегабайт)

и так же учитывай, что с серверами всё намного сложнее, чем с устройствами, к которым у тебя есть постоянный физический доступ.

это да. "если кто-то имеет физический доступ к твоему устройству - то это уже не твоё устройство" © Microsoft

оставив только нешифрованный загрузчик, вводить пароль в него через удаленный ipsec-туннель к KVMу, а дальше с данными работать уже используя шифрованные контейнеры Vera.

/boot тоже можно шифровать
а под "KVM" ты имеешь в виду отдельную коробочку с кей- и трафик-логгером, которую выдал хостер, или встроенный в твой сервер чип BMC?
если в сервере нет BMC и пользоваться мутными коробочками не хочется, то можно использовать dropbear-initramfs, я такое использую на некоторых серверах для расшифровки рутового раздела по SSH.

 

[gliderexpert]

/boot тоже можно шифровать

Не очень понимаю как грузиться с него в таком случае, кто его расшифрует?

а под "KVM" ты имеешь в виду отдельную коробочку с кей- и трафик-логгером, которую выдал хостер, или встроенный в твой сервер чип BMC?

BMC, куда же без него ( Современные серверные мат.платы без этих чипов уже бывают.

 

[Dread Pirate Roberts]

Не очень понимаю как грузиться с него в таком случае, кто его расшифрует?

ты - физическим доступом или через KVM.

BMC, куда же без него ( Современные серверные мат.платы без этих чипов уже бывают.

а в каком BMC есть поддержка IPSEC? или это хостер даёт доступ к твоему BMC только через свой локальный впн?

 

[Maxik2005]

у квм есть виртуальная клава. координаты курсора штатными средствами в лог не пишутся. правда клацать мышкой 30+ символов вида $!@#$ заебёсся ))

 

[gliderexpert]

а в каком BMC есть поддержка IPSEC?

Докупается как доп.опция к HPшному iLO. Не на всех версиях iLO ее можно включить.

 

[George Boole]

Идеальное решение задачи.
Предположим что наш противник обладает такими мощностями что ломает любой пароль за секунду.
Математически это возможно потому что пароль не может быть бесконечно разнообразным.
Из этого следует что мы не можем защитить наши данные паролем, нам нужно что то что дает бесконечное количество вариаций и что невозможно брутить по определению.
Брутить можно любой известный криптоалгоритм и даже их комбинации с условием что мы ограничим их конечным числом, это число лего посчитать исходя из характеристик железа, не получится навесть миллион идущих подряд aes, точнее получится но это будет не жизнеспособно с точки зрения производительности.
Таким образом противник брутит любой - кллюч, алгоритм, комбинации алгроритмов.
Невозможно брутить неизвестный алгоритм так как их может быть бесконечно много.
Практические действия, мы будем заливать на наш серв не только пароль но и комбинацию из известных проверенных алгоритмов и 1 свой никому не известный, это может быть например так - aes, свой, туфиш, aes. Мы не можем доверится чисто своему алгоритму(пусть это будет например обычный aes в который мы накинули пару дополнительных ксоров) в соло, так как не можем качественно оценить его стойкость, но нам это и не важно, криптостойкость(идеальную энтропию данных) обеспечат проверенные алгоритмы а наш обеспечивает невозможность брута.

Накидывать кастомный алгоритм шифрования нет большого смысла. AES (да и большинство современных блочных шифров) в режиме CBC шифрует вполне надёжно. При длинном ключе брутфорсить нереально. Стандартные 128 бит ближайшие лет 10 не взломают, даже если у кого-то появится производительный квантовый копьютер (просто потому что тут нет задач, которые он может решать эффективнее транзисторных). Так что от брута мы защитились уже на этом этапе.
Кастомный же алгоритм шифрования становится просто дополнением к ключу (и храниться видимо будет с ним же, что неудобно). Если алгоритм хранится не с ключом, даже если он остался у вас только в качестве исполняемого файла - его разревёрсят и будут брутить с его использованием. А заморочек с кастомным шифрованием больше (как минимум, нужно компилировать на все платформы, где вы хотите его использовать).
Словом, принцип Керкгоффса не просто так стараются соблюдать.

К слову, если шифровать кастомным алгоритмом шифрования поверх стандартного алгоритма с тем же ключом, то криптостокость как раз можно понизить. Простейший пример, который даст интуитивное понимание почему так может сложиться - представьте, что случайно в качестве кастомного алгоритма шифрования у вас получился алгоритм дешифрования, соотвествующий стандртному алгоритма шифрования, который вы использовали до этого. Если ключи были одинаковые - криптостойкость всей системы уйдёт в 0.
Однако, если зависимости между ключами не будет, то всё будет ок =)