Специалисты из компании Red Hat подняли (https://securityblog.redhat.com/2014/05/07/defeating-memory-.../) заслуживающий внимания вопрос интеграции средств защиты от проведения атак, основанных на корреляции времени выполнения операции и степени совпадения данных, сравниваемых функцией memcmp. Используемая по умолчанию в Glibc реализация memcmp подвержена проблеме, которая позволяет предсказать значение сравниваемых данных.
Например, если memcmp используется при сравнении ключа шифрования c входными данными, то атакующий может байт за байтом подобрать значение с которым осуществляется сравнение. Техника атаки основана на том, что memcmp завершает выполнение после первого несовпадения, т.е. атакующий может передать случайный набор данных и изменять значение первого байта, отслеживая время выполнения операции. Устойчивое увеличение времени будет сигнализировать об успешности подбора первого байта, после чего можно начать подбирать второй байт и т.д.
В качестве решения проблемы предлагается перейти на использование реализации функции memcmp, время выполнения которой явно не зависит от степени совпадения строки (например, можно сравнивать элементы в случайном порядке или сравнивать блоки в несколько байт). Включение по умолчанию подобного варианта функции в Glibc рассматривается как маловероятное (с позиции производительности, текущий вариант memcmp предпочтительней), поэтому как наиболее реалистичный вариант рассматривается возможность задействования защищённой версии memcpm при сборке Glibc с опцией "-D_FORTIFY_SOURCE=2".
URL: https://securityblog.redhat.com/2014/05/07/defeating-memory-.../
Новость: http://www.opennet.me/opennews/art.shtml?num=39730
и насколько реально этим воспользоваться?
Это ещё что, высший пилотаж - восстановление данные по шуму конденцаторов компьютера (http://www.opennet.me/opennews/art.shtml?num=38689)
> и насколько реально этим воспользоваться?В ряде случаев - вполне. К криптографическим примитивам одно из требований - чтобы время выполнения не зависело от ключа/пароля/etc. Иначе можно будет последовательно подобрать.
И одно дело если ты будешь подбирать 20-символьный пароль как 26^20 и другое - как 26 * 20 :). Есть некоторая "небольшая" разница в сложности подбора. Первое ты загнешься подбирать, а вот 520 попыток в хучшем случае - это уже звучит как заявка на победу, не так ли?
520*N всё-таки, потому что чтобы точно оценить разницу времени исполнения учитывая параллельно выполняющиеся задачи и другие факторы нужно много больше 1 попытки. Но таки да, сложность всё равно деградирует с экспоненциальной до линейной.
> 520*N всё-таки,Ну да, как-то так. Кстати не в тему, но по общей логике очень похоже на взлом WPS. Там, конечно, бестолковость в протоколе, но - именно такого плана.
нудк, обфускации в линуксе - практически не было(две наивные вещи были, по-дефолту и все).
все из-за лобби и троллинга Линуса против "маструбирующих на безопасность" всех и вся, работу которых он либо не силен оценить, либо у него свой(или тех от кого он зависит)интерес против.
ожидать релиза новой версии libastral.so ?
> будет сигнализировать об успешности подбора первого байтаНа третий день Зоркий Глаз заметил что у сарая нет стены. В смысле, все кто хоть немного интересовался криптографией - уже давно в курсе что memcmp() использовать для вещей типа проверки паролей и прочего - не айс. Как раз вот поэтому вот. А редхат сказочно откапитанил, да :).
> - не айс. Как раз вот поэтому вот. А редхат сказочно
> откапитанил, да :).редхат предложил с опцией "-D_FORTIFY_SOURCE=2" делать memcmp более защищённым, и в чём капитанство ?
Не капитанство, а слоупочество. Даже в дебиане это уже в стейбле по умолчанию, а в генте ещё лет 5 назад было.
И что в Debian? Защищённый memcmp? Вы ничего не попутали?
> И что в Debian? Защищённый memcmp? Вы ничего не попутали?Капитанство и слоупочество - в том что кому оно было надо - уже много лет знали что memcmp в криптографии использовать *НЕЛЬЗЯ*. По именно этим причинам. И даже если в каком-то редхате это починят - кроме него есть туева хуча платформ где это не так, поэтому любой уважающий себя криптографический софт сам делает свою функцию сравнения которая всегда завершается за фиксированное время. Ну то-есть делается сравнение вообще целиком всего input, независимо ни от чего, при несовпадении взводится флаг, при возврате отдается состояние этого флага - или совпало, или нет. Это менее оптимально по скорости но более стойко к атакам на времянки типа упомянутых.
>редхат предложил с опцией "-D_FORTIFY_SOURCE=2" делать memcmp более защищённым, и в чём капитанство ?В том что защищенность покупается хоооорошим просадом в скорости ... А очрованные на всю шляпу РХ-ники предлагают юзать этот слоупок для всех тонн софта...
Вместо того чтобы написать свою реализацию для криптодел ...
Но юзать для гвоздей молоток а для шурупов - отвёртку - это не по RH-ному :)
> Например, если memcmp используется при сравнении ключа шифрования c входными данными, то атакующий может байт за байтом подобрать значение с которым осуществляется сравнение.а нельзя например при сравнивании ключей -- использовать другую функцию нежели memcmp?
кто именно (и кого?) заставляет ключи сравнивать именно через memcmp?
> а нельзя например при сравнивании ключей -- использовать другую функцию нежели memcmp?да йопт
int memcmp(void *x, void *z, size_t n)
{
struct timespec request, remain;
unsigned char a, b;
int count = 0;
request.tv_sec = 0;
request.tv_nsec = 0;for (; n--; x++, z++) {
a = *(unsigned char *)x;
b = *(unsigned char *)z;srand(time(NULL));
request.tv_nsec += rand() % 1000000;
clock_nanosleep(CLOCK_REALTIME, 0,&request, &remain);if (a != b) {
return (a - b);
}
}
return 0;
}> кто именно (и кого?) заставляет ключи сравнивать именно через memcmp?
В новости есть ссылка https://securityblog.redhat.com/2014/05/07/defeating-memory-.../
>> ... For a concrete example, the following piece of code from OpenVPN
>
> /* Compare locally computed HMAC with packet HMAC */
> if (memcmp (local_hmac, BPTR (buf), hmac_len))
> CRYPT_ERROR ("packet HMAC authentication failed");.
> clock_nanosleepЧто, компьютеры стали слишком быстрыми?
надеюсь за правду эти "ускоряющие циклы" ни кому в голову не придёт вставлять
> надеюсь за правду эти "ускоряющие циклы" ни кому в голову не придёт
> вставлятьза правду — вряд ли. а за деньги — запросто.
> да йоптЧто это за буита, павлин? А просто сравнить весь input целиком и взвести флаг если не совпало, а потом вернуть флаг - это слишком просто, да? Хрена себе у благородного дона художества. Иди дельтаплан построй - хочу посмотреть что у тебя с таким подходом получится :).
> Что это за буита, павлин? А просто сравнить весь input целиком и
> взвести флаг если не совпало, а потом вернуть флаг - это
> слишком просто, да?да. намекну: нужно как минимум два цикла.
> да. намекну: нужно как минимум два цикла.А зачем? Гоняем цикл, прописываем в нем флаг. Тезис о том что присвоение флагу одного значения занимает больше или меньше значения чем другого - конечно имеет право на жизнь, но это мы уже лезем глубоко в недра оптимизаторов компилятора и придется асмовые портяны смотреть. Если это реально беспокоит, можно сделать единственную рандомную задержку при возврате, а-ля каркуша, например. Чисто технически, загрузка в регистр проца что 7 что 10 (допустим, 7 означает что все пока совпадает, а 10 - что не совпало) занимает сама по себе одинаковое время (по крайней мере, причин почему бы это было не так - изначально нет). Еще - может, ты от cache hit/cache miss хотел защититься? В случае обычного сравнения это вроде пофигу, т.к. время возврата не несет полезной информации о причинах почему оно такое, в отличие от оригинального memcmp, время выполнения которого пропорционально позиции на которой началось несовпадение, что можно померять. Бывают брейнфакнутые случаи, типа scrypt, у которого известный недостаток - характер доступа к памяти зависит от пароля и в результате cache hit/cache miss потенциально теряет информацию о исходном ключе. Но в случае просто сравнения - нельзя ли пояснить млдель угрозы от которой делается защита?
вот чтобы не лезть глубоко и получить более-менее амортизированное время без копания в асме, проще всего сделать два цикла с двумя флажками.
p.s. с одним циклом можно *попытаться* точнее определить, какой именно байт не совпал, если чо.
> А просто сравнить весь input целиком и взвести флаг если не совпало, а потом вернуть флаг - это слишком просто, да?К сожалению, современные процессы работают очень хитро. И лично я не уверен, что при таком алгоритме нельзя будет повторить такого рода атаку. Например, вполне ненулевая вероятность, что timing будет отличаться из-за работы кеш-а. Нужно изучать этот вопрос внимательнее.
А вообще, мне не нравится идея усилять memcpy в FORTIFY. Я его с какого-то времени начал использовать почти везде, а у меня нет нигде кода, требующего защищённого memcpy. А даже если был бы, я бы использовал отдельную реализацию (не вижу смысла тормозить весь код из-за этого).
> а нельзя например при сравнивании ключей -- использовать другую функцию нежели memcmp?В openssl есть для этого CRYPTO_memcmp(), например. Но бывает так, что авторы кода по недосмотру используют memcmp. Вот от них и пытаются защищаться.
Где-то проскакивала информация, что в DRM у консоли Wii использовалась strcmp вместо memcmp. Вот это был фейл.
> Где-то проскакивала информация, что в DRM у консоли Wii использовалась strcmp вместо
> memcmp. Вот это был фейл.А у Сони вообще рандом был не рандомным нифига, что позволило народу посчитать приватный ключ из-за особенности применяемого алгоритма на основе эллиптических кривых :). Читать факин мануалы на применяемые алгоритмы торгаши и DRMщики и их cpaныe наймиты не любят :).
> В openssl есть для этого CRYPTO_memcmp(), например. Но бывает так, что авторы
> кода по недосмотру используют memcmp. Вот от них и пытаются защищаться.Irinat - ты мужчина? Если так давай ко мы тебя кастрируем, чтоб ты кого не снасильничал. Ничего личного - просто "от них и пытаются защищаться" же.
Ещё раз - в криптософте поведение стандартной memcmp() вызывает проблему (а в остальном софте - вызывает восторг :) ... значит и надо криптописателей снабдить медленной но в этом смысле надёжной финкцией, а всем остальным оставьте БЫСТРУЮ!
Интересно, а специалистам из редхата не приходило в голову, что подобная атака требует больше вычислительных ресурсов, чем простой подбор ключа?
> Интересно, а специалистам из редхата не приходило в голову, что подобная атака
> требует больше вычислительных ресурсов, чем простой подбор ключа?Думаю нет, посколько они образованные люди в отличие от вас и разницу между O(2^N) и (N) видят.
> требует больше вычислительных ресурсов, чем простой подбор ключа?Щаз. Вон WPS почти так и разломали - последовательно подбирая цифры по одной :).
ну вообще -- при взломе WPS нет необходимости анализировать время.там просто две группы цифр.
каждую из этих двух групп -- подбираем отдельно (сначало первую потом вторую).
кстате взлом WPS работает только в том случае если WiFi-точка отвечает разными ответами взависимости от того в какой из двух групп ошибка (многие современные WiFi-точки так уже не делают).
> ну вообще -- при взломе WPS нет необходимости анализировать время.Да, однако логика последовательного подбора по цифрам - как раз в духе этого самого.
> каждую из этих двух групп -- подбираем отдельно (сначало первую потом вторую).
Насколько я помню, одну подбирают целиком, вторую по отдельным цифрам, что как раз очень даже ололо.
> современные WiFi-точки так уже не делают).
Ну да, конечно, известный бэкдор - это не айс!
Там 8 десятичных разрядов, первая группа из 4 разрядов проверяется отдельно от второй. Однако 8-й разряд последовательности - есть функция от первых семи, т. о. во второй группе надо перебирать лишь три разряда. Итого 11000 вариантов для полного перебора, а в среднем - 5500, что совсем плохо.Почему WPS придумали именно таким - для меня большая загадка. Да, потом разработчики оборудования понадобавляли всяких костылей для усложнения атаки, но от этого не стало сильно лучше.
> Устойчивое увеличение времениПри условии, что время компьютера устойчиво, а то это как секс в гамаке - попадёшь-непопадёшь.
> При условии, что время компьютера устойчиво, а то это как секс в
> гамаке - попадёшь-непопадёшь.А можно просто туда-суда пару тысяч раз, потом уже статистика - залетела/не залетела :).
> Включение по умолчанию подобного варианта функции в Glibc рассматривается как маловероятное (с позиции производительности, текущий вариант memcmp предпочтительней), поэтому как наиболее реалистичный вариант рассматривается возможность задействования защищённой версии memcpm при сборке Glibc с опцией "-D_FORTIFY_SOURCE=2".что-то в redhat понабрали каких-то тупых наркоманов, каждая новость хлеще другой. Вместо того, чтобы сделать отдельную ф-ю специально предназначенную для криптографии и аутентификации, они решили притащить эти костыли в библиотеку общего назначения. Идиоты.
> они решили притащить эти костыли в библиотеку общего назначения. Идиоты.Девиз онанимных оналитегов: Новость не читай - коммент пиши!!!
https://sourceware.org/ml/libc-alpha/2014-01/msg00763.html
Ща конечно заплачет "- этого нет русской новости,..." :`(Неидиот, английский-то знаешь? Упрощу задачу, для твоего IQ можешь перевести последние три слова.
> We implemented the first approach, based on BSWAP, on top of the GNU C library
> implementation of memcmp that is targeted at the current line of x86 CPUs which
> have fast unaligned loads. It turned out that the cost was mostly negative. For
> example, sorting a random permutation of /usr/share/dict/words using qsort was
> about ten per cent faster than before.
>> они решили притащить эти костыли в библиотеку общего назначения. Идиоты.
> Девиз онанимных оналитегов: Новость не читай - коммент пиши!!!А то ! :)
> https://sourceware.org/ml/libc-alpha/2014-01/msg00763.html
> Ща конечно заплачет "- этого нет русской новости,..." :`(А ещё тот кусок овсокода который ты запостил - тоже не о том что по ссылке :)
В общем понятно. У меня из нормальных остался только один аргумент против. То что они предложили - только для Ынтелей\(амд?) работает. На армах к примеру она так и будет опасной. Но юзать будут то что в мэйнстриме, а мэйнстрим 99,999% на ...
> Техника атаки основана на том, что memcmp завершает выполнение после первого несовпаденияДа нивапрос, будем проверять ВСЁ!!!
int memcmp_s(void *x, void *y, size_t n)
{
unsigned char a, b;
unsigned char ret;for (ret = 0; n--; x++, y++) {
a = *(unsigned char *)x;
b = *(unsigned char *)y;if (a != b && ret == 0) {
ret = (a - b);
}
}
return (ret != 0 ? ret : 0);
}> т.е. атакующий может передать случайный набор данных и изменять значение
> первого байта, отслеживая время выполнения операции.
>
> return (ret != 0 ? ret : 0);
>Я, конечно не мастер, и вообще мне страшно писать на такие сайты для взрослых, но что делает эта строка? проверяет равен ли ret нулю, если не равен возвращает ret иначе ноль?
Может сократить доreturn ret. Или мы ret не очень доверям???
> Или мы ret не очень доверям???Выбирай по-вкусу:
1. Преждевременная оптимизация залог ошибок!
2. Программирование "сверху-вниз".
3. Это идея, а не код.
Домашнее задание по оптимизации:Сделать туже логику, но без переменной ret;
Всех С Днём Победы!!!!
> Домашнее задание по оптимизации:
> Сделать туже логику,
> но без переменной ret;угу. потому что сейчас там ошибка.
>> Или мы ret не очень доверям???
> Выбирай по-вкусу:
> 1. Преждевременная оптимизация залог ошибок!
> 2. Программирование "сверху-вниз".
> 3. Это идея, а не код.4. Говнокод
> 4. Говнокодсудя по тому, как он этот говнокод защищает, не желая признавать ошибки — это не просто говнокод, это выстраданый ночами кусок кода; лучшее, на что павлуша способен, видимо. надеюсь, мне никогда не придётся увидеть худшее.
>> 4. Говнокод
> судя по тому, как он этот говнокод защищает, не желая признавать ошибки
> — это не просто говнокод, это выстраданый ночами кусок кода; лучшее,
> на что павлуша способен, видимо. надеюсь, мне никогда не придётся увидеть
> худшее.Ты что, первый раз такое от него увидел? павлуша всегда был говнокодером - ничем он не удивил и в этот раз.
по-моему, раньше он свою чушь так яростно не защищал. или я внимания не обращал, или напился на праздник.
> Может сократить до return ret
return !!ret;
>> Может сократить до return ret
>return !!ret;снова ошибка. man memcmp.
>>> Может сократить до return ret
>> return !!ret;
> снова ошибка. man memcmp.Неа, ошибки нет. return ret можно заменить на return !!ret, если хочется редуцировать именно до 0 или 1, и это абсолютно корректно. Это демонстрация трюка на случай, если кто-то про него не знает.
Участвовать в соревнованиях по переписыванию memcmp или других библиотечных функций я не собираюсь. Для занятий на досуге есть другие, более интересные и более нужные мне задачи.
функция называется memcmp_s(). функция ЯВНО пытается (хоть и неправильно) возвращать именно то, что возвращает memcmp(). твой код поломал её ещё больше. но «ошибки нет», ага.
> твой код поломал её ещё больше. но «ошибки нет», ага.Обрати внимание на то, что ret объявлен как unsigned char.
Может всё-таки обратишь своё стремление искать ошибки в более конструктивное русло? В мире куча open source проектов, которые не отказались бы от ещё одной пары глаз, просматривающих код на предмет багов. А искать ошибки в наколенных поделиях на форумах это, знаешь ли, как-то мелко.
>> твой код поломал её ещё больше. но «ошибки нет», ага.
> Обрати внимание на то, что ret объявлен как unsigned char.обрати внимание на то, что про уже наличествующую до тебя ошибку я сказал раньше.
> Может всё-таки обратишь своё стремление искать ошибки в более конструктивное русло?
спасибо, без твоего ценного указания я и не догадывался, как можно применить моё умение видеть ошибки. но ты открыл мне глаза!
Фишка в том, что возвращаемый результат сохраняется один раз, но проверяются все байты.
if (a != b && ret == 0) {
ret = (a - b);а не какого цвета ret
И эта, оба, хвать здипить покажите ваш код!
> Фишка в том, что возвращаемый результат сохраняется один раз, но проверяются все
> байты.фишка в том, что у тебя неправильно возвращает результат: по спекам должно возвращать отрицательное в соответствующем случае, а у тебя никогда отрицательного результата не будет. это раз.
два: время исполнения всё равно зависит от значений, хоть и не так сильно.
три: утекают данные о точной разности.
ну, и всякие мелочи типа const, __restricted и ты пы.
так что фишка в том, что показанная фигня не особо лучше memcmp(), да ещё и с ошибками.
> И эта, оба, хвать здипить покажите ваш код!
зачем? тебя же тоже никто за руку не тянул, ты сам свою лапшу сюда вывалил. вот и обтекай теперь.
> два: время исполнения всё равно зависит от значений, хоть и не так сильно.Да ты чо???!!!
if ( 55 != 47 ) будет отличатся от if ( 56 != 48 ) ??? :)
>> И эта, оба, хвать здипить покажите ваш код!
> зачем? тебя же тоже никто за руку не тянул, ты сам свою лапшу сюда вывалил. вот и обтекай теперь.хвать здипить покажите ваш код! маны я и без тебя наизусть знаю
>> два: время исполнения всё равно зависит от значений, хоть и не так сильно.
> Да ты чо???!!!а ты подумай про неполное вычисление условий и про записи в память, гыгы. и про то, что это неплохо бы амортизировать хотя бы двумя циклами.
> хвать здипить покажите ваш код!
зачем? тебя же тоже никто за руку не тянул, ты сам свою лапшу сюда вывалил. вот и обтекай теперь.
> маны я и без тебя наизусть знаю
тем не менее, в реализации облажался.
> покажите ваш код!int
memcmp_s(const void *s1, const void *s2, size_t n)
{
return CRYPTO_memcmp(s1, s2, n);
}
>> покажите ваш код!
> int
> memcmp_s(const void *s1, const void *s2, size_t n)
> {
> return CRYPTO_memcmp(s1, s2, n);
> }Пля, толант.
> Пля, толант.его код — в отличие от твоего — без ошибок.
> его код — в отличие от твоего — без ошибок.Глядя на авторов openssl я бы на него 100 баксов не поставил...
>> его код — в отличие от твоего — без ошибок.
> Глядя на авторов openssl я бы на него 100 баксов не поставил...а это уже совсем других людей ошибка. нельзя же считать, что ошибка именно в коде, который использует некие библиотечные функции, если в самих функциях ошибки.
>> покажите ваш код!
> return CRYPTO_memcmp(s1, s2, n);Ха-за :) Но - таки - ДА!
>> покажите ваш код!
> int
> memcmp_s(const void *s1, const void *s2, size_t n)
> {
> return CRYPTO_memcmp(s1, s2, n);
> }Можно сделать static inline, чтобы уменьшить на одну обёртку. А ещё подумать на тему всяких "restrict"-ов. :)
Достаточно угадать длину ключа и последний байт.
>Достаточно угадать длину ключа и последний байт.Посмотрел на код еще раз, отменяетсяю
>> Техника атаки основана на том, что memcmp завершает выполнение после первого несовпадения
> Да нивапрос, будем проверять ВСЁ!!!
if (a != b && ret == 0) {
ret = (a - b);
}Разное время выполнения в зависимости от того, "ret == 0" или нет. По сути ровно та же атака в силе, просто заметить увеличение/уменьшение времени выполнения становится сложнее.
Чисто математически задача немного сложнее ведь, что все так пренебрежительно к ней относятся? :(
> Чисто математически задача немного сложнее ведь, что все так пренебрежительно к ней
> относятся? :(понекропостим: на самом деле именно memcmp() в криптографии нафиг не упёрся, нужен memequ(). то есть, тупо флажок «равно/не равно», причём точно в виде ноля и единицы, например. вот тут задача уже резко упрощается и решается буквально в две строки.
а кто продолжает использовать memcmp() там, где надо memequ(), тот идиот, и к криптографии его подпускать вообще нельзя.
Странный подход. Так-то взломщик может неким путём подменить библиотеку с оной функцией на самописную и спокойно ломать ключ. Надо не на реализации конкретной функции в системе полагаться, а разрабатывать надёжные алгоритмы защиты, не допускающие подобного рода анализов. Обновлять memcmp -- это просто сооружать костыль. Задача системных функций -- выполнить свою работу как можно быстрее при как можно меньшем объёме памяти. С тем же успехом можно в Уголовный Кодекс принять закон, запрещающий анализ времени выполнения memcmp.
>взломщик может неким путём подменить библиотеку с оной функцией на самописную и спокойно ломать ключНу, как-бы, взломщик не сможет перезапустить демоны, проверящие ключи со своей LD_PRELOAD_PATH=..., не имя при этом рутовых прав.
а это и не обязательно делать. Достаточно пропатчить plt таблицу, не очень сложная операция
> а это и не обязательно делать. Достаточно пропатчить plt таблицу, не очень
> сложная операцияправда, сделать это весьма проблематично, если у тебя рута нет, но когда такие мелочи смущали благородных донов?
если у человека уже есть рутовый доступ, то поздно пить боржоми. но часто это вовсе не так.
> Странный подход. Так-то взломщик может неким путём подменить библиотеку с оной функцией
> на самописную и спокойно ломать ключ. Надо не на реализации конкретной
> функции в системе полагаться, а разрабатывать надёжные алгоритмы защиты, не допускающие
> подобного рода анализов. Обновлять memcmp -- это просто сооружать костыль. Задача
> системных функций -- выполнить свою работу как можно быстрее при как
> можно меньшем объёме памяти. С тем же успехом можно в Уголовный
> Кодекс принять закон, запрещающий анализ времени выполнения memcmp.контроль целостности системы, с включенной реалтайм-частью - ведь никто не запрещает ставить ? Но НЕТУ этого на 99% серваков, тем не менее.
>рассматривается возможность задействования защищённой версии memcpm при сборке Glibc с опцией "-D_FORTIFY_SOURCE=2"А не лучше ли использовать выбор времени исполнения варианта memcmp, например, установкой какой-либо глобальной переменной?
в любой непонятной ситуации - х*ячь глобальную переменную!!!111
> в любой непонятной ситуации - х*ячь глобальную переменную!!!111всегда так делаю, брат жив!
>> в любой непонятной ситуации - х*ячь глобальную переменную!!!111
> всегда так делаю, брат жив!Пишешь с холодильника? :D
> Пишешь с холодильника? :DТы там этого, потише. Уже есть холодильники с ведроидом, так что вы уже довыпендривались, фаготы.
>> в любой непонятной ситуации - х*ячь глобальную переменную!!!111
> всегда так делаю, брат жив!А как же этот, multi-threading?
> А как же этот, multi-threading?а нас в ПТУ такому не учили.
>> А как же этот, multi-threading?
> а нас в ПТУ такому не учили.Зато научили скакать :)
Чтобы добиться устойчивого среднестатистического увеличения времени при нынешних скоростях процессоров и задержек сети - необходимо вбивать один и тот же пароль как минимум 1000 раз. Задержка сети - миллисекунды, задержка memcmp - наносекунды, полученные результаты все равно будут в рамках погрешности.
вообще-то memcmp предназначена для сравнения данных. безопасность там не предусмотрена by design. если кому нужна безопасность, разумнее сделать что-то типа memcmp_slow_but_secure_fapfap и использовать её (но только не пихать её во все дыры чисто из принципа, а использовать её в тех местах, где это действительно нужно, а во всех остальных местах использовать memcmp)
Так они придут к тому, что каждый вызов любой функции будет сопровождаться цифровой подписью.
> Так они придут к тому, что каждый вызов любой функции будет сопровождаться
> цифровой подписью.В правильных системах это, почти, так и есть. Не подпись, но аппаратный ключ.
По крайней мере на всякие exec/open. А ещё есть VAX/Open/VMS там похожее by design
прекрати бредить, обезъянка
> В правильных системах это, почти, так и есть. Не подпись, но аппаратный ключ.иногда мне так и хочется процитировать какую-нибудь фразу из очередного американского кино про суперсекретных агентов...
типа:
"IP-адрес зашифрован через RSA.. о боже! мне потребуется не менее 30 минут чтобы взломать его!"
> есть VAX/Open/VMS там похожее by designЭто ты о чём? Чета не распарсил ....
Почему бы не оставить memcmp в покое и не добавить memcmp_crypto?
Не вижу смысла терять производительность в тех приложениях и частях приложений, где нет необходимости защищать буфер.