Важное дополнение: Выяснилось, что хэши номеров банковских карт в утекшей БД вычислялись без каких-либо "дополнительных мер предосторожности", описанных в основной части статьи!
Что означает, что мои предположения в конце статьи, во второй части, были не верны, и лучше исходить из предположения, что все номера карт из утекшей БД уже сейчас известны похитителям!
Только что поднялся шум по поводу утечки данных пользователей Сберспасибо, и о том, что из-за использования "устаревшего" SHA-1, хэшированные им номера банковских карт в базе якобы элементарно "восстановить".
Сначала - пара нюансов касательно использования устаревшего SHA-1:
- Он до сих пор используется как основной в госучреждениях США.
- Да, от него решено уйти в США, но это решение принято... Всего 3 месяца назад(!)
- Уйти от него в госучреждениях США планируется к... 2030(!) году
Пруф: https://www.nist.gov/news-events/news/2022/12/nist-retires-sha-1-cryptographic-algorithm
Это к тому, что не так просто сменить алгоритм хэширования в большой системе.
Это не оправдание его использования, а один из возможных вариантов, почему он все еще используется - еще не успели перейти на новый.
К тому же, есть еще один нюанс - несовершенство SHA-1, о котором идет речь - имеет значение для формирования цифровых подписей больших электронных документов. Оно облегчает внесение несанкционированных правок в подписанный электронный документ, так чтобы они не изменили его цифровую подпись - то есть облегчает подделку подписанных цифровых документов.
А вот в контексте сокрытия исходных значений номеров банковских карт в таблице БД путем хэширования - преимуществ у более современных и криптостойких алгоритмов хэширования в общем-то нет.
Как не раз указали в комментариях - если не были предприняты дополнительные меры предосторожности, то независимо от использованного алгоритма хэширования, исходные номера карт очень легко получить, просто вычислив хэши для всех возможных номеров карт (того же Сбера), и сравнив полученные хэши с записями в таблице БД.
Теперь основная часть - ТЕОРИЯ относительно тех самых "дополнительных мер предосторожности".
- Хоть многие IT-шники и либерасты, но отнюдь не дураки (в своей профессиональной области), и возможность (риск, если угодно) кражи БД всегда подразумевается с самого начала разработки любого продукта. Поэтому собственно конфиденциальная информация в ней и хэшируется/шифруется.
- Не будучи дураками (в своей области, в массе своей), IT-шники прекрасно понимают, что на хэши таких малых объемов информации, как пароли, номера карт - можно очень бодро совершать атаки. Вплоть до, как отмечалось в новости, прямого перебора номеров карт. И следовательно этому тоже надо противодействовать - исходя из предположения в п.1
- Для нивелирования возможности "восстановления" исходной информации из хэша, применяется так называемая "соль" - пристегивание к целевой информаци (номеру карты) какого-либо достаточно объемного "левого" мусора (соли), не хранящегося в базе с хэшами, и вычисление хэша уже для всей этой конструкции "[номер_карты]+[мусор-соль]".
Не зная этой "соли" (а так же не имея исходного кода серверной части, чтобы знать как "соль" комбинируется с номерами карт) - "восстановить" номер карты из хэша НЕВОЗМОЖНО даже теоретически.
И эта "соль" может быть чем угодно - хоть полным текстом "Война и Мир" толстого, и реализация ее добавления тоже может быть разной (по сложности для выполнения атаки).
Приведу в качестве примера, два крайних, полярных случая (оба почти никогда не используются в жизни, но дают хорошее понимание того, какова может быть минимальная и максимальная безопасность - в реальности в банках используется обычно нечто промежуточное):
1. В простейшем случае, когда информация не критична (скажем пароли пользователей в БД мелкого форума) это может быть просто забитая в исходный код серверной части форума длинная строковая константа со случайным набором символов - одна и та же для всех пользователей.
В этом случае, чтобы "восстановить пароли" из хэшей украденной БД - нужно еще "довеском" и украсть исходный код серверной части (подчеркиваю - исходный код, а не скомпилированные и обфусцированные исполняемые двоичные файлы с сервера), посмотреть как хэшируются пароли, и атаковать хэши паролей из БД соответствено - с пристегиванием той обнаруженной длинной строковой константы.
2. В наиболее "серьезных" случаях - эта "соль" не только не хранится в исходном коде серверной части, она вообще не хранится нигде на компьютерах/серверах в готовом виде. А берется из
- Отдельного, специально обученного, железного шкафа
- Стоящего в сильно охраняемом помещении, с физическим доступом к нему под роспись в журнальчике
- Отвечающего на запросы о предоставлении этой самой "соли" исключительно от собственных серверов компании (валидация по целому комплексу признаков - MAC-адрес и IP-адрес из белого списка, VPN-шлюз, проприетарная авторизация, и прочее пропорционально степени паранойи)
- Возвращающего индивидуальную "соль" для каждого пользователя - скажем на основе его номера телефона, передаваемого этому шкафу в запросе
3. Совсем параноидальный, отдельный случай, как пример того, насколько может быть защищена информация, из разряда "когда надо серьезно, но требуется гарантировать защиту хэшированных данных даже в случае КРАЖИ ВСЕГО":
В этом случае можно, как вариант, использовать МНОГО СОЛИ :)
Ну то есть, в комментариях к исходной статье очень многие бодро рассуждали, о том как они за 10 минут пересчитают хэши всех возможных номеров карт. Так вот спешу вас огорчить - даже в этом случае легкой атаки скорее всего не получится, если организация серьезно относится к безопасности информации. То есть если даже удалось украсть:
- БД
- "Соль"
- Исходный код серверной части (чтобы понять как "соль" комбинируется с номером карты перед вычислением хэша)
То вы запросто можете обнаружить, что "соль" - это допустим двоичный файл размером в десяток (или сотню) гигабайт.
Да, именно так - вы обнаружите что хэш для ОДНОГО номера карты у вас вычисляется допустим 5 - 30 секунд (для одного гигабайта данных на относительно мощном современном ПК SHA-1 вычисляется 1-2 секунды).
Далее можете сами прикинуть, сколько лет у вас займет вычисление хэшей для миллиардов всех возможных номеров карт, исходя из 5 секунд на один номер, и прикинуть сколько будет стоить аренда облачных мощностей для решения этой задачи за месяц, и стоит ли игра свеч вообще, учитывая что это только номера карт, без CVV, доступа к кодам 3D-SECURE и тд.
А так же не забыть, что максимум через пару лет у всех карт из БД уже истечет срок годности.
Ну и под конец - немного моих личных соображений о произошедшем.
Очевидно, (как справедливо подметили в комментариях, ничего не очевидно, поэтому...)
Я ПРЕДПОЛАГАЮ, что у укравших БД Сберспасибо, кроме хэшей номеров банковских карт нет
- Ни "солей" для них (иначе бы об этом визг стоял до небес)
- Ни исходного кода серверной части чтобы понять как "соли" комбинируются с номерами карт перед вычислением хэшей (иначе визг об этом стоял бы выше чем до небес)
- Ни доступа к достаточно большим и достаточно дешевым (чтобы оправдать получение только номеров карт, без дополнительной платежной информацмм) вычислительным мощностям, ибо они не сотрудники университетов со спонсируемым доступом к суперкомпьютерам
Да, конечно, в их распоряжении есть "бот-неты", но те бот-неты приносят куда более стабильный и гарантированный доход, рассылая спам, чем считая хэши с околонулевой вероятностью получить хоть сколько-то полезную в контексте надежного получения дохода информацию.
Как следствие - я считаю маловероятным, что похитителям удастся восстановить исходные номера карт из этой БД (хоть это и не исключено, я не защитник Сбера, не его сотрудник, не имею доступа к информации о том, что еще было/не было украдено помимо БД, и к каким пресловутым "дополнительным мерам предосторожности" Сбер прибегает на случай кражи БД типа произошедшей).
Комментарии
Доступно изложено.
Спасибо.
Доступно, но бесконечно коряво и с ошибками. Вот это вот что такое, а?
Так никто не делает, ибо это и бессмысленно и не нужно. Потому что вам же нужно вот это:
А это гораздо проще делается. Вам не нужна большая соль, вам нужен крутой засол!
Берёте 160 бит (если у вас SHA-1, которая 160-битная) случайной соли (это всего-навсего 20 символов, у некоторых личностей имя-фамилия длинее) и смешиваете с номером. Вычисляете SHA-1. А потом ещё раз SHA-1. И ещё раз SHA-1. И снова SHA-1. И так - пока не надоест (обычно несколько тысяч раз гоняют в цикле, иногда могут несколько миллионов раз прокрутить, как железо становится мощнее, так добавляют прогонов). И всё.
SHA-1 необратима (да-да, до сих пор… на самом деле даже MD-2, MD-4 и MD-5 до сих пор не обратили, у них у всех есть атаки, которые не позволяют использовать их для подписи сертификатов, но обращать их не умеют до сих пор), так что этого более, чем достаточно.
Причём это не то, что я вот прям сейчас выдумал, а это хорошо известная техника, применяемая с незапамятных времён (статья в Wikipedia в 2007м годом датируется, но криптобиблиотеки освоили сию нехитрую премудрость ещё раньше), совершенно непонятно почему автор статьи начал выдумывать совершенно ненужные (в реальности даже вредные) гигбайты.
Как мне тут не раз уже сказали - не выдавайте свои домыслы за факты. Вы голову даете на отсечение, что так нигде не делают?
Неспециалисту, или отставшему от жизни - конечно не понятно.
Специалисту же прекрасно понятно, что такой подход на данный момент - единственный (в контексте "могут украсть и БД, и соли") который гарантирует исключение риска эффективного использования атакующим ферм GPU.
Почему так? Поясняю ниже.
Во-первых, соль не может быть случайной. Вы должны иметь возможность в будущем добавить в точности ту же соль при хэшировании полученных вновь данных, идентичность которых ранее захэшированным надо проверить.
Во-вторых, этот наивный и ленивый подход уже не работает - вы либо отстали от жизни в теме, либо просто не в теме. Лет 5 минимум как это стало бесполезным, с тех пор как стали бурно развиваться GP-GPU вычисления.
Добавление пары десятков байт соли с последующим циклическим хэшированием никак не устраняет ключевой проблемы - возможности эффективного использования GPU для перебора хэшей / поиска коллизий.
Вот именно - атакующий берет 5-6 видеокарт типа RX 6800 - и все, время определения всех номеров банковских карт из БД по прежнему исчисляется несколькими днями - несмотря на миллионы "прокруток".
А вот на гигабайте соли - GPU уже становится медленнее, чем CPU. И выходит из гонки.
Предвижу ваше возражение "А я просто тогда не миллион, а миллиард раз хэш от хэша посчитаю".
Спешу огорчить - это не сработает. Потому что если вы будете считать миллиард раз хэш от хэша - у вас сервер повесится, не сможет обрабатывать запросы с необходимой скоростью. А атакующий просто возмет еще пяток видеокарт, и подождет не пару дней, а пару недель - для него-то это не проблема.
А вот хэш с гигабайтной солью - сервер считает за секунду-две, а на GPU перебирать - уже смысла ноль.
То, что вы называете солью -- это не соль, а ключ. Соль -- случайна и несекретна.
Хорошо, давайте предположим что вы используете случайную соль.
Пользователь ввел пароль.
Вы сгенерировали случайную соль, которую в будущем не сможете сгенерировать снова, пристегнули ее к паролю, и посчитали хэш.
Через некоторое время пользователь снова вводит пароль, и вам надо проверить его правильность. На руках у вас - только хэш, полученный на предыдущем шаге.
Ваши действия?
Сразу скажу - если соль принципиально не секретна и хранится здесь же, рядом с хэшем - то ценности и смысла в использовании этой соли - абсолютный ноль, в принципе - как вы ее пристегивали к хэшируемой информации, так атакующий пристегнет.
Так же сразу скажу - использовать PRNG с заданным зерном - вам нельзя. Потому что вы сказали про случайную соль. А НЕ ПСЕВДОслучайную.
Псевдослучайная же соль - случайной не является по определению. Она является тем, чем я ее и называл - отнюдь не случайным "информационным мусором" (для простоты понимания не-специалистами).
И хеш, и соль соль хранится в базе (часто просто в одном значении в виде объединения).
Потом при проверке берется соль, берется ввод от пользователя, хэшируется строка соль+ввод и проверяется с хранящимся хэшем.
Это же типовой алгоритм.
Это защищает от атаки при помощи радужных таблиц - которая потеряла актуальность.
Это не защищает вообще от атаки прямым перебором - которая стала актуальной даже для "хороших" паролей.
Мне не важно, насколько алгоритм типовой - я знаю что он перестал давать достаточную защиту. Этого для меня достаточно, чтобы перестать его использовать, сколь бы "авторитетным" и "устоявшимся" он ни был.
Нет такого понятия "достаточная защита".
Для построения защиты строится модель угроз и выбираются меры противодействия.
То есть вам наплевать, будет защищаемая вами информация скомпрментирована через неделю после утекания БД, или через год. Ясно :)
А вот все остальные дураки-то - говорят про "достаточную стойкость шифра", оценивают за сколько взломать можно в случае кражи/перехвата сообщения...
Да. Представьте себе, что в требованиях безопасности закладывают время, в течении которого защита должна работать, а дальше никаких гарантий не дается.
Вы только что выше написали, что "нет такого понятия как достаточная защита".
И вот уже сами описываете ключевой критерий для оценки достаточности защиты.
Пожалуйста, наведите порядок у себя в голове, прежде чем сыпать в комментариях чушью :)
Так достаточная защита -- это многокритериальная задача, и зависит от формулируемых критериев. Неужели это так сложно понять?
Одна и та же реализация в одной постановке будет достаточной, а в другой -- нет.
Вы только что выше написали, что "нет такого понятия как достаточная защита".
И вот уже сами буквально закидываете меня вариантами методологий определения достаточности защиты
Пожалуйста, наведите порядок у себя в голове, прежде чем сыпать в комментариях чушью :)
Если есть такое понятие, напишите, что оно означает.
Или наведите у себя порядок в голове, подтяните теорию и не трахайте другим мозг.
Защита считается достаточной, если затраты на ее преодоление превышают ожидаемую ценность (либо ущерб от раскрытия) самой информации к моменту преодоления защиты.
Зачем вы вообще полезли в дискуссию, не понимая даже таких элементарных основ?
Выучите основы. Потом выучите теорию. Потом попрактикуйтесь (нет, проректорство - это не практика, это отупляющая административная должность). После всего этого вы сможете что-то написать на тему, не опозорясь с первого же слова незнанием азов из учебников, к строгому следованию которым сами же и аппелируете :D
Что такое затраты, как они вычисляются? Что такое ценность, как ее посчитать?
Давайте, раскрывайте тему, а не занимайтесь балабольством и демагогией.
Вы тоже заценили потерю измерения… хотя бы располагаемых ресурсов.
Затраты вычисляются как (нижняя, как правило) оценка расходов (в конечном итоге - финансовых) на преодоление защиты - то есть кражу (получение в свое распоряжение) защищаемой информации, и последующее извлечение/восстановление/взлом ее до того момента времени, как она потеряет свою ценность, (как целиком, так и отдельных представляющих интерес для похитителя, так и риск для владельца, ее частей), реализуемое силами мощных программно-аппаратных комплексов, "трудо-дни" которых и составляют немалую часть той самой финансовой ценности.
Ценность информации определяется (вычисляется, если угодно) клиентом. Для безопасника - это готовый входной параметр.
Понимаю, вы проректор - практики ноль, опыта ноль, понимания сути процессов - ноль. Но чтобы у проректора было меньшее понимание темы, нежели у его студентов? Это ново. Прямо как ЕГЭ :)
Бла-бла-бла. Ясно все, никакой конкретики, одно балобольство. Делаем вывод, что никакой "достаточной защищенности" в природе не существует.
Наведите у себя порядок в голове.
Ну, вы можете делать любые выводы какие вам заблагорассудится - благо нести чушь в современном социуме не запрещено :)
А понятие "достаточности защиты информации" существует в каждой книге по информационной безопасности или криптографии, начиная с любого учебника вуза на эту тему, и оно всегда звучит практически одинаково, с некоторыми вариациями: "Исходя из этого, формулируется принцип достаточности защиты информации: защиту информации принято считать достаточной, если затраты на ее преодоление превышают ожидаемую стоимость самой информации"
Первый попавшийся учебник: https://www.labirint.ru/books/123118/
Нет правда, вам не стыдно быть безграмотнее даже абитурентов вашего вуза? (хотя вы писали что вы были проректором - и теперь я вижу за что вас поперли)
Вы настолько не читаете, что и кто вам пишет, что уже приписываете мне ЧУЖИЕ слова про "хотя вы писали что вы были проректором".
Кончайте этот балаган, вы достаточно уже опозорились.
Ох ты ж, точно, проректором-то был BDima-криптовалютчик :)
Да, вот это вы меня уели, вот это конфуз - оказывается вы даже до проректора не доросли :)
Пардон муа конечно - но теперь хотя бы понятно, почему вы даже элементарных понятий из вузовских учебников по информатике и защите информации не знаете.
Но съезжаете с темы мастерски, тут прямо мое почтение - как только ссылку на конкретный пример учебника получили - сразу хлоп, и другая тема - кто и что мне пишет, а про "достаточность защиты информации" вроде как вы и не оконфузились даже, утверждая что такого понятия якобы не существует. Или это от испуга - боязнь учебников? :)
Давайте еще с терминами определимся.
То, что вы в статье назвали соль, на самом деле называется:
См., например, https://en.wikipedia.org/wiki/Pepper_(cryptography)
Можете считать меня параноиком, но я считаю что не должно быть ничего открытого "по умолчанию".
Те кто преднамеренно хранят соль в открытом в виде вместе хэшируемыми данными - сродни дуэлянтам, которые договорились стрелять по очереди, стоя друг перед другом лицом к лицу, с установленной дистанции - "потому что так принято". Ну а я выстрелю в спину, с расстояния поближе.
Я предпочитаю усложнять задачу атакующему на каждом шагу. У всех соль хранится в той же БД в открытом виде - а у меня в независимой БД, на другом сервере, к которому вообще нет никакого доступа ниоткуда, кроме единственного запроса на получение значения соли с адресов из белого списка.
Да, я ее использую так же как все используют обычную соль. И даже называю обычной солью. И даже закладываю возможность ее компроментации. Но храню и использую вот так вот, не "в открытом по умолчанию" виде.
"И что ты мне сделаешь?" (с) :D Как атакующий, похитивший основную БД и решивший что уже получил все что нужно - разве что поплачешь.
Если я теперь ее из-за этого обязан называть "секретной солью", при том что риск ее компроментации заложен как "штатаный"... Нет, я не считаю что обязан в своей статье, не претендующей на роль официального образовательного материала, из-за этого называть ее "секретнойс солью" :)
Вы можете делать что угодно, никто вам это не запретит.
Но вы хотя бы термины используйте понятные другим, что бы не было бессмысленных споров, когда вы "перец" называете "солью" и т.п.
Так как мне называть соль, которая хранится в другой БД, на другом сервере? Секретная соль? Но я вроде не закладываюсь на ее секретность. Ее утекание в случае кражи основной БД предполагается весьма вероятным. Просто не на 100% вероятным, как в случае когда она лежит в основной БД.
Все равно называть ее секретной солью, потому что иначе у вас картина мира не складывается?
Ну тогда давайте вообще все что есть в базах - называть секретным - ведь утекание базы никогда не считается заведомо на 100% имеющим место в будущем, чуть ли не "запланированным". А значит и обычная соль - внезапно оказывается секретной. На полшишечки, но секретной.
Если не закладываетесь на ее секретность, то это просто соль. А у вас -- велосипед.
Да-да, все что не строго по уччебнику (желательно с готовой реализацией в nuget-пакетике) - велосипед.
Продолжайте погромировать мышкой :)
Скажите пожалуйста: nuget соответствует PMS?
Я бы описанную систему назвал велосипедом, у которого из-за дополнительной сложности слабые стороны могут вылезти в самых неожиданных местах.
Ложное чувство безопасности очень опасно.
Не надо атакующих за дураков держать. Смогли утянуть основную базу, и с этой защитой тоже разберутся.
Поменьше пустых слов, побольше дела - укажите хоть какой-нибудь ослабление защищенности из-за хранения несекретных солей отдельно от хэшируемых данных.
Ложное оно как раз у тех, кто слепо делает все "по учебнику", не понимая сути происходящего, и при этом будучи уверенным что "раз по учебнику - значит безопасно". Написано "хранить соли в БД вместе с хэшируемыми данными" - значит так и сделаем. Зачем нам самим думать - ведь авторитетный дядя сказал что это безопасно.
...и все - к тому моменту когда атакующие осознают, что взлом хэшей не удается, потому что "чего-то не хватает", и надо где-то на серверах искать и тянуть дополнительную базу, с солями - в лучшем случае брешь уже будет закрыта и данные защищены от компроментации, в худшем случае - это даст дополнительное время до компроментации хэшированных данных.
Давайте, чтобы вы не были голословными в утверждениях относительно ненужности отдельного хранения солей, рассмотрим вполне жизненную ситуацию:
Вопросы:
1. сколько у похитителя уйдет времени прежде чем он достоверно определит, что к паролям перед хэшированием что-то еще добавлялось?
2. сколько у похитителя уйдет времени, прежде чем он достоверно определит, в колонке "pwdSha1hash" хранятся MD5-хэши, к которым в конец добавляются 4 случайных байта?
3. сколько у похитителя уйдет времени, и сколько ему потребуется совершать дополнительной активности в локальной сети организации (рискуя обнаружением бреши/утечек), чтобы найти и похитить БД с солями?
4. сколько у похитителя уйдет времени, чтобы достоверно определить, что соли не просто конкатенируются с хэшируемыми данными в конец, а перемешиваются менее тривиальным способом, и надо еще тянуть и исполняемые файлы, декомпилировать их, и смотреть что происходит с солями?
- Вы уверены, что все это дополнительное время до компроментации данных (равно как и шанс сорвать компроментацию полностью, если хотя бы на одном из этих п.1-п.4 похититель сдастся/зафейлится и "не сможет пройти дальше") - абсолютно не нужны, и только создают ложное чувтсво безопасности?
Кашу маслом не испортишь.
В смысле - хэши солью. =)
Хэш без соли - деньги на ветер :)
Вполне доступное пояснение. Думаю гораздо опаснее счас это светить свои данные при оформлении скидочных карт.
Большое Спасибо, было очень интересно.
Сам из сферы ИТ но в целом с защитой СУБД на таком уровне не работал.
Спасибо, за разъяснения.
Все равно нет гарантии, что кроме слива БД в "широкий доступ" не было слива ПО и "соли" тем, кто заказал музыку.
Зы и по любому сбербанк надо за слив данных гнобить на издядную сумму штрафа. ИМХО.
Гнобить конечно надо, кто ж спорит, как я отметил под статьей - это в любом случае серьезный косяк Сбера.
Как отметил и про то что гарантии отсуствия рисков нет - но мне лично все-таки кажется, что
если бы украли еще и исходные коды и соли - то про это бы тогда трубили еще громче эти DLBI или как их там...
Если бы украли и исходные коды и соли и это было бы важно — то тех идиотов, которые не знают как key stretching выполняется нужно было бы уволить, а потом расстрелять. Ну или расстрелять, а потом уволить — неважно.
Ибо key stretching решает задачу защиты пароля шифрования накопителя, в первую голову, а там условия жёсткие, однако:
Так что если всё сделано грамотно (в смысле не снижали ниже плинтуса количество раундов при вызове соответствующей функции), то соль у злоумышленников, наоборот, уже есть, исходники можно найти (в криптоиндустрии крайне не рекомендуется свои велосипеды изобретать, так что использовалась, наверняка, какая-нибудь стандартная библиотека), но максимум, что вы с этим сможете сделать — проверить что Вася Пупкин, какой-нибудь, имеет право на скидку (имея имя оного Васи и номер его карты). Всё.
Ну вот как выяснилось выше - вы не знаете как выполнять key stretching, наивно полагая что детский подход с циклическим хэшированием еще хоть как-то защищает от атак на хэши - что теперь - расстреливать вас? :D
Не будьте столь категоричны - были ли помимо БД украдены вдобавок и соли и исходный код - это всегда важно. Это как минимум позволяет оценить по порядку величины время до момента компроментации защищаемой информации, и определиться со срочностью (и наличием необходимости вообще) и объемом мер для минимизации ущерба. Как максимум - если не удалось украсть скажем соли - вообше не переживать за риск компроментации данных.
Что за бред вы несете? Вы вообще в курсе про аппаратные средства шифрования?
Про то что ключ шифрования накопителя ноутбука никогда не хранится в самом ноутбуке (какому идиоту это вообще могло придти в голову?). Ключ шифрования хранится в USB-стике (как самый расхожий вариант).
И этот ключ - уже сложный до невозможности, 4096-битный как минимум. К нему вообще не применимо понятие key stretching, если вы используете его хэш вместо него самого - вы этим наоборот, радикально снизите защищенность зашифрованых данных.
И этот USB-стик с ключом шифрования накопителя очень сложно украсть вместе с ноутбуком - например, потому что он стальной цепочкой закреплен на браслете на руке владельца ноутбука, а при обрыве цепочки стирает ключ - поэтому этот USB-стик невозможно забыть в ноутбуке, и невозможно срезать с браслета.
Можно конечно отрезать владельцу ноутбука руку, или украсть заодно и владельца ноутбука - но для противодействия этому используются уже другие меры защиты информации :D
"4096-битный как минимум ключ", это вообще из другой оперы: RSA и асимметричного шифрования. К защите носителей отношения не имеет.
Вы действительно считаете, что длина ключа как понятие присутствует, и как параметр имеет влияние на криптостойкость - только в асимметричном шифровании? :D
Для симметричного шифрования сейчас по факту ключ в 128-бит с AES за глаза. Хотя в российской криптографии для Кузнечика размер ключа зафиксирован в 256 бит.
"За глаза" - это сколько? Сколько потребуется на получение номера банковской карты, с 4 первыми известными цифрами, зашифрованного AES128? А RC5 с 2040-битным ключом?
Вы в курсе, что абсолютной криптостойкостью обладает только один известный шифр - при этом - самый примитивный, "подстатоновочный шифр"? Как раз при достаточной длине ключа - равной длине сообщения.
Вопрос про "Сколько потребуется не понял", что вам надо?
И я в курсе, что есть класс шифров "одноразовый блокнот" и Клод Шеннон доказал, что для достижения идеальной секретности ключ одноразового блокнота должен быть не короче сообщения (плюс некоторые другие условия).
Но так же я знаю, что это непрактично.
Хрестоматийное: удобство vs безопасность…
Это хорошо, что вы в курсе таких азов.
А вы в курсе того, что есть симеетричные шифры, которые по стойкости значительно выше AES256, особенно с достаточно длинными ключами - и что эти "достаточно длинные ключи" - вполне себе практичны, при длинах порядка нескольких тысяч бит?
Более того, что они в некоторых случаях даже более практичны, чем AES256 - например при шифровании больших файлов.
И замечательно подходят, помимо прочего, для аппаратного шифрования устройств хранения данных.
Что собственно и имелось в виду в изначальном ответе про "шифрование винта ноутбука с ключом длиной например 4096 бит".
Да, я в курсе, что любую задачу можно решить сколь угодно сложным и сколь угодно дурацким способом.
Это я уже от вас слышал - "все что не в учебнике - дурацкое, и в осмыслении не нуждается" :)
Буквально девиз джуна из индии. Так держать :)
Кстати, помните историю с приснопамятным патчиком для OpenBSD?..
Страницы