[TOG 0]

Товарищи,

Я сообщаю человеку некое зашифрованное сообщение(AES, длина 16 байт). По условию задачи исходный текст сообщения он знает.

У него есть сильное желание узнать каким паролем зашифровано это сообщение.

Допустим я для шифрования использовал пароль 8 символов(цифры и латинские буквы в верхнем регистре) из которого я сделал хэш.

Хэш я предполагаю делать в цикле примерно так:

for (i=0; i<1000000; i++)
{
SHA256(buf);
}

На моем STM32H743 на вычисление этого миллиона хэшей уходит ~6 секунд. (Это предел по времени, больше уже нельзя).

Вопрос: Как бы понять сколько времени потребуется современному взломщику на подбор такого пароля на каком-нибудь современном железе(майнинговая ферма или чем они пользуются) ?

Например я прочитал в интернете, что NVIDIA RTX 4090 выдает 290 мега-хэшей в секунду. Много это или мало ?

[makc 205]

Почитайте про PBKDF2 - https://ru.m.wikipedia.org/wiki/PBKDF2

[girts 9]

Сугубо имхо - 
На обычном домашнем компе в разумное время реально расчитать до 5 байт брутфорсом.
На чем то заточенном - на пару порядков больше. Скажем, 8 байт.
Так что исходные 8 символов, тем более заглавными - имхо маловато, если использованные алгоритмы "врагу" известны.

Верхний регистр - это ASCII с 0x41 по 0x5A:  (26)^8 = ... за 14 дней и ваш STM32H743 справится.

ЗЫ: а энигма, говорят, погорела на всеми известном приветствии предводителю, которым оканчивалось каждое сообщение....
 

[tonyk_av 37]

4 hours ago, girts said:

На обычном домашнем компе в разумное время реально расчитать до 5 байт брутфорсом.
На чем то заточенном - на пару порядков больше. Скажем, 8 байт.

8 больше 5 на ДВА ПОРЯДКА?

[jcxz 210]

8 часов назад, TOG сказал:

На моем STM32H743 на вычисление этого миллиона хэшей уходит ~6 секунд. (Это предел по времени, больше уже нельзя).

А почему так медленно? Получается: 480e6*6/1e6 = ~2880 тактов на 1 хеш. Вроде по документации заявлено, что должно быть ~66 тактов на 512бит. Т.е. - должно быть в ~43 раза быстрее.

Даже на моём XMC4500, не имеющем аппаратного вычислителя хеша, расчёт SHA256 от 128 бит данных занимает ~6548 тактов (без особой оптимизации). В вашем же МК есть аппаратный вычислитель. Неужто он так медленно работает???  

PS: Или вы программно считаете? Но - зачем??? На МК, имеющем аппаратный вычислитель....  

[TOG 0]

17 hours ago, makc said:

Почитайте про PBKDF2 - https://ru.m.wikipedia.org/wiki/PBKDF2

Спасибо, makc. Интересная штука. Попробую освоить. Жаль ее нет в стандартной STM'овской криптобиблиотеке.

15 hours ago, girts said:

Так что исходные 8 символов, тем более заглавными - имхо маловато, если использованные алгоритмы "врагу" известны.

Верхний регистр - это ASCII с 0x41 по 0x5A:  (26)^8 = ... за 14 дней и ваш STM32H743 справится.

Спасибо, girts. По Вашей формуле получается 26^8 ~ 2e11 (примерно 209 млрд. возможных комбинаций). Но это без учета цифр. Вы же только  латинские буквы посчитали. Если использовать и цифры и буквы, то это уже 36^8 = 3e12 (2821 млрд. комбинаций).

То есть если видеокарта считает ~ 300 мегахешей в секунду, то:

За 1 секунду она сможет перебрать всего 300 паролей.

На 209 млрд. комбинаций уйдет ~ 8000 суток  = 22 года. (подбор пароля только из 8 заглавных латинских букв )

И ~ 100000 суток = 300 лет на подбор пароля из 8 заглавных латинских букв и цифр.

Наверно ферма из 10 тыс. видеокарт такую задачку решит и не подавится. 🤑

9 hours ago, jcxz said:

А почему так медленно? Получается: 480e6*6/1e6 = ~2880 тактов на 1 хеш. Вроде по документации заявлено, что должно быть ~66 тактов на 512бит. Т.е. - должно быть в ~43 раза быстрее.

Даже на моём XMC4500, не имеющем аппаратного вычислителя хеша, расчёт SHA256 от 128 бит данных занимает ~6548 тактов (без особой оптимизации). В вашем же МК есть аппаратный вычислитель. Неужто он так медленно работает???  

PS: Или вы программно считаете? Но - зачем??? На МК, имеющем аппаратный вычислитель....  

Спасибо, jcxz.

Программно считаю.

Да, в RM я вижу, что есть аппаратный вычислитель, но по факту его нет. Хорошо хоть CRC и RNG есть. Аппаратный крипто модуль похоже есть только в STM32H73x.

ST'шники наверно забыли мануал исправить. 

[jcxz 210]

1 час назад, TOG сказал:

Да, в RM я вижу, что есть аппаратный вычислитель, но по факту его нет.

Почему? Вроде в errata ничего нет про неработающий HASH.... Он что по факту - не работает? В какой-то конкретной вашей ревизии чипа или во всех?

18 часов назад, TOG сказал:

Я сообщаю человеку некое зашифрованное сообщение(AES, длина 16 байт). По условию задачи исходный текст сообщения он знает.

У него есть сильное желание узнать каким паролем зашифровано это сообщение.

Допустим я для шифрования использовал пароль 8 символов(цифры и латинские буквы в верхнем регистре) из которого я сделал хэш.

И честно говоря - я так до сих пор и не понял смысла вашей темы...  

Человек знает зашифрованное сообщение и результат его расшифровки? И хочет угадать пароль, которым шифровали?

Но какое отношение длительность вычисления хеша от 8-байтной строки имеет к длительности решения этой задачи??? Что мешает вам дополнить эту 8-байтную строку слева или справа константой любой желаемой длины (которую угадыватель не знает) и считать хеш от этого суммарного массива? И тогда угадывателю нужно будет перебирать не все значения вашей ASCII-строки, а все значения SHA256. Что он будет делать до морковкина заговення даже имея миллион видеокарт.

 

PS: Также я не понял - на кой вы, для генерации ключа AES из пароля, считаете миллион раз SHA256? Почему его нельзя посчитать один раз от "пароль+фиксированная_случайная_константа"? Ведь это будет в ~миллион раз быстрее, а не 6 секунд.

[Arlleex 157]

4 минуты назад, jcxz сказал:

Почему? Вроде в errata ничего нет про неработающий HASH.... Он что по факту - не работает? В какой-то конкретной вашей ревизии чипа или во всех?

У ТС 743.

[jcxz 210]

3 минуты назад, Arlleex сказал:

У ТС 743.

А, ясно блин - уродская документация STM...   Я скачал и просмотрел RM и errata для H743. Там ни слова не сказано, что HASH-а нет и в помине. Но пишут про него (как будто он есть). К стенке нужно ставить за такую документацию....  

[Arlleex 157]

1 минуту назад, jcxz сказал:

А, ясно блин - уродская документация STM...   Я скачал и просмотрел RM и errata для H743. Там ни слова не сказано, что HASH-а нет и в помине. Но пишут про него (как будто он есть). К стенке нужно ставить за такую документацию....  

Нормальная документация, в даташите на 743 ни слова о hash/crypto

https://www.st.com/resource/en/datasheet/stm32h743vi.pdf

в 753, разумеется, есть

https://www.st.com/resource/en/datasheet/stm32h753vi.pdf

RM, как и всегда, дает общее описание периферии всей линейки.

[TOG 0]

19 minutes ago, jcxz said:

Человек знает зашифрованное сообщение и результат его расшифровки? И хочет угадать пароль, которым шифровали?

Но какое отношение длительность вычисления хеша от 8-байтной строки имеет к длительности решения этой задачи??? Что мешает вам дополнить эту 8-байтную строку слева или справа константой любой желаемой длины (которую угадыватель не знает) и считать хеш от этого суммарного массива? И тогда угадывателю нужно будет перебирать не все значения вашей ASCII-строки, а все значения SHA256. Что он будет делать до морковкина заговення даже имея миллион видеокарт.

 

PS: Также я не понял - на кой вы, для генерации ключа AES из пароля, считаете миллион раз SHA256? Почему его нельзя посчитать один раз от "пароль+фиксированная_случайная_константа"? Ведь это будет в ~миллион раз быстрее, а не 6 секунд.

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

[jcxz 210]

30 минут назад, Arlleex сказал:

Нормальная документация, в даташите на 743 ни слова о hash/crypto

Дурацкая документация. Идея - лепить общий документ на совершенно разные чипы - сама по себе дурацкая.

Представьте если бы какой-нить Бош выпустил суммарную документацию на свои пылесос+стиралку+мультиварку+утюг. И вы, среди режимов стирки белья, искали бы как сварить суп. Или гадали бы: этот пункт "слив воды" относится к стиралке или к мультиварке или к утюгу? ....или и к тому и к другому и к третьему, но не к четвёртому?  

30 минут назад, Arlleex сказал:

RM, как и всегда, дает общее описание периферии всей линейки.

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

Вы видимо всегда работаете только с STM, поэтому видимо не подозреваете, что можно сделать по-другому, по-нормальному. В RM-ах NXP, TI, Infineon я что-то не припомню такого бардака как у STM. У Infineon МК линейки XMC4xxx по периферии очень похожи. Некоторая прям один-в-один совпадает. Но при этом Infineon не лепит их в один документ, а выпускает отдельно RM для XMC4500, отдельно - для XMC4700. Очень удобно. Зачем мне винегрет из кучи процессоров если я работаю с конкретным МК, а не со всем винегретом сразу?

А TI так и ещё дальше пошёл: для линейки Tiva например - для каждого корпуса МК (каждой аббревиатуры маркировки) - отдельный документ (даташит+RM)! И не надо гадать - есть эта функция в твоём МК или нет? Всё что описано - есть.

 

PS: Да - и ранее (для линейки F4xx) в RM STM, хоть и лепил уже вместе винегрет из разных МК, но по крайней мере в заголовке описания каждой периферии указывалось к каким именно МК этот раздел имеет отношение:

Цитата

23  Cryptographic processor (CRYP)
This section applies to STM32F415/417xx and STM32F43xxx devices.

Сейчас получается даже такого не делают..... 

Почему я и ошибся с H743, потому как по привычке глянул в заголовок раздела HASH RM и не увидел там замечания об ограничениях на разные чипы линейки.

[jcxz 210]

47 минут назад, TOG сказал:

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

Всё равно ничего не понятно....   Зачем миллион раз то хеш считать? Если хацкеры взломали ваш exe-шник, то чем это поможет???

Думаете, что хацкеры умрут со смеху, увидев расчёт хеша миллион раз? И это обезопасит вас от них?    

 

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

Т.е. - функция будет тратить те же самые 3-7 тыс.тактов на вычисление одного хеша в степени миллион.

Как думаете - как можно ускорить алгоритм сложения числа X самого с собой миллион раз? Правильно - просто умножить его на миллион.  

[Arlleex 157]

28 минут назад, jcxz сказал:

В RM не должно быть разделов не относящихся к данному МК!

Это Вы так думаете. А я (и не только я) нет - и мне удобнее иметь под рукой один мануал, а не горсть разных - у меня используются МК разных типов внутри одной и той же линейки от ST, и это помимо МК других фирм. И я замахался бы переключаться между даташитами, чтобы понять, насколько SPI STM32F427 отличается от F429 или F407.
 

28 минут назад, jcxz сказал:

И вы, среди режимов стирки белья, искали бы как сварить суп. Или гадали бы: этот пункт "слив воды" относится к стиралке или к мультиварке или к утюгу? ....или и к тому и к другому и к третьему, но не к четвёртому?  

Сравнение некорректное. До такого маразма документация ST не доходит. Она исторически всегда придерживалась одного стиля ведения документации - даташит описывает конкретные особенности конкретной модели МК. RM описывает детально всю периферию всех моделей МК. Поэтому разработка становится простейшей - подбираешь МК по даташитам (в кубе быстрее), смотришь там, что все ок, а уже при программировании или при уточнении "скользких мест" смотришь в RM на конкретную периферию.
 

28 минут назад, jcxz сказал:

Вы видимо всегда работаете только с STM, поэтому видимо не подозреваете, что можно сделать по-другому, по-нормальному.

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

Цитата

У Infineon МК линейки XMC4xxx по периферии очень похожи. Некоторая прям один-в-один совпадает. Но при этом Infineon не лепит их в один документ, а выпускает отдельно RM для XMC4500, отдельно - для XMC4700. Очень удобно. Зачем мне винегрет из кучи процессоров если я работаю с конкретным МК, а не со всем винегретом сразу?

А если не очень похожи? Бегать между даташитами каждый раз сравнивать биты? Мне оно на кой? Я в пределах одного документа (иногда одной страницы) увижу особенности и отличия. И даже подозревать не придется, что что-то может отличаться.
 

28 минут назад, jcxz сказал:

А TI так и ещё дальше пошёл: для линейки Tiva например - для каждого корпуса МК (каждой аббревиатуры маркировки) - отдельный документ (даташит+RM)! И не надо гадать - есть эта функция в твоём МК или нет? Всё что описано - есть.

В итоге имеем 100500 документов с почти одним и тем же содержимым. А если где-то есть отличие, то при беглом взгляде его хрен увидишь. А потом, как это обычно бывает, замыленный глаз смотрит совершенно не в тот даташит и из-за отличий в камнях программирование идет поперек борозды, теряя дни отладки.
 

28 минут назад, jcxz сказал:

Сейчас получается даже такого не делают..... 

Это следствие кубов, КМК. Никто сейчас в даташиты не смотрит при разработке железа - в кубе накидали периферии нужной, посмотрели, влезает в выбранный проц или нет - поехали.

[jcxz 210]

16 минут назад, Arlleex сказал:

А потом, как это обычно бывает, замыленный глаз смотрит совершенно не в тот даташит и из-за отличий в камнях программирование идет поперек борозды, теряя дни отладки.

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

PS: Честно говоря мне кажется странной ситуация одновременного программирования двух разных прошивок. Обычно всё-таки: сперва пишется какой-то блок кода в одной прошивке; и потом переключаемся на другую, где так же пишем блок кода. И "блок" - это более-менее функционально законченный кусок кода. А не одна строчка.

Я тоже писал две разные прошивки примерно в одно время. Или прошивку, которая будет компилироваться на разных МК. Но это было не в стиле: "написали строчку для одной прошивки, через минуту - для другой". Особенно - в части программирования железа (низкоуровневое). Да, бывает отладка протокольного взаимодействия двух ПО идёт подобным образом. Но к этому моменту всё железо уже проинициализировано и код работы с ним написан и отлажен (по отдельности). Смешивать разбирательство с низкоуровневой периферией и протокольную обработку - само по себе не гуд.