Извините, верно так:
Для защиты от обращения ключа по известному ОТКРЫТОМУ тексту применяют множество раундов шифрования и перемешивание ключевой информации.
Тогда лучше было бы забивать случайной информацией уже после зашифрования, тогда бы шифр выдал вам случайную последовательность еще лучших характеристик.
А /dev/random является криптостойким генератором случайных последовательностей?
Именно для этого в криптосистемах для дисков применяются разные алгоритмы смешения криптотекстов. Например блок может использовать криптотекст предыдущего для модификации исходного открытого текста. Посмотрите про CBC и XTS например.
Современные алгоритмы производят шифртекст, который отвечает многим требованиям случайности. Тоесть по его характеристикам угадать, что скрыто невозможно.
Для защиты от обращения ключа по известному криптотексту применяют множество раундов шифрования и перемешивание ключевой информации.
Поэтому 64 мегабайтный ключ не имеет смысла, а только замедлит работу, ведь придется шифровать по 64 (возможно меньше или больше) мегабайта за раз.
После авторизации в OAuth можно вызывать любые сервисы, которые предоставляет провайдер OAuth. В Твиттере например есть вервисы типа 'status/update' и т.д. Тоесть к OAuth можно прикрутить любые сервисы, главное их задокументировать, а вызовы будут инкапсулироваться в OAuth запросы.
Методология измерения не совсем правильная. NtDelayExecution переносит поток из списка плнируемых в список ожидания. Повторный запуск произойдет через заданный интервал + время до следующего планирования + время на смену контектов потока. Поэтому маленькие интервалы никогда не будут правильно измеряны в ОС с планировщиками общего назначения. А при больших интервалах кажущаяся точность появляется потому, что отношение необходимой задержки к накладным расходам становится больше — накладные расходы меньше влияют на результат измерения. При переключении задач может также происходить инвалидация кеша процессора, его заполнение требует время, вероятность велика, если код долго не получал управления из-за того, что был отложен — скорее всего неиспользуемый код был вытеснен.
rdtsc также не является реальным показателем, как уже говорили про разные ядра и процессоры также стоит отнести регуляцию частоты в мобильных решениях. Также, с появлением переупорядочивания на конвеере в процессорах Интел не гарантируется, что rdtsc исполнится не раньше, чем предшествующие инструкции.
Таким образом, чтобы точно измерить интервал, надо не выходить в ожидание, а наоборот занять процессор полностью, время от врмени получая метки времени, желательно как-то избегать переключения задач или учесть накладные расходы на переключение — для этого необходимо будет найти способ определения моментов переключения контекстов, Clerk на васме писал про некоторые фичи Windows, которые позволяют засечь момент переключения контекстов.
Также желательно инвалидировать кеши 1 уровня перед замерами и очищать конвеер (например дальним вызовом, только тут может помешать предсказание переходов...).
Как раз позавчера посмотрел документальный фильм данной тематики: „Путешествие на край Вселенной” от National Geographic. Очень круто описывают размеры объектов вселенной и даже затрагивают теорию большого взрыва. Всем советую посмотреть.
1) Ниодная проактивная защита такое про пропустит без предупреждения
2) В статье совсем не DLL инъекция, как заметили другие комментаторы, DLL инъекцию можно осуществить либо документированным способом ака хуком, инъекцией кода, подгружающего DLL, патч импортов файла, заменой DLL и т.д.; а здесь, как я понял, просто инъекция исполняемого кода
1)
SELECT *, (
SELECT id
FROM photo_image AS pi
WHERE pi.g_id = pg.id
AND (
is_main_foto =1
OR is_main_foto =0
)
ORDER BY is_main_foto DESC
LIMIT 1
) AS Image_id
FROM `photo_gallery` AS pg
WHERE `c_id` =2
AND `is_published` =1
HAVING Image_id IS NOT NULL
ORDER BY `ordi` DESC
2) Для случая, когда известно, что у фотки точно есть слейдующая и предыдушая придумал такое:
SELECT pi2.id, pi2.ordi, pi3.id, pi3.ordi
FROM `photo_image` AS pi
INNER JOIN `photo_image` AS pi2 ON pi.g_id = pi2.g_id
INNER JOIN `photo_image` AS pi3 ON pi2.g_id = pi3.g_id
WHERE pi.`id` =167
AND pi.`is_published` =1
AND pi2.`is_published` =1
AND pi3.`is_published` =1
AND pi2.id != pi.id
AND pi3.id != pi.id
AND pi3.ordi > pi.ordi
AND pi2.ordi < pi.ordi
ORDER BY `pi2`.`id` ASC, pi3.id DESC
Если фотка первая или вторая, то можно дополнительный запрос использовать на проверку граничных значений.
3) Тут явно одним запросом не обойтись, пока идей нет. Хотелось бы посмотреть вариант автора.
Для защиты от обращения ключа по известному ОТКРЫТОМУ тексту применяют множество раундов шифрования и перемешивание ключевой информации.
А /dev/random является криптостойким генератором случайных последовательностей?
Современные алгоритмы производят шифртекст, который отвечает многим требованиям случайности. Тоесть по его характеристикам угадать, что скрыто невозможно.
Для защиты от обращения ключа по известному криптотексту применяют множество раундов шифрования и перемешивание ключевой информации.
Поэтому 64 мегабайтный ключ не имеет смысла, а только замедлит работу, ведь придется шифровать по 64 (возможно меньше или больше) мегабайта за раз.
rdtsc также не является реальным показателем, как уже говорили про разные ядра и процессоры также стоит отнести регуляцию частоты в мобильных решениях. Также, с появлением переупорядочивания на конвеере в процессорах Интел не гарантируется, что rdtsc исполнится не раньше, чем предшествующие инструкции.
Таким образом, чтобы точно измерить интервал, надо не выходить в ожидание, а наоборот занять процессор полностью, время от врмени получая метки времени, желательно как-то избегать переключения задач или учесть накладные расходы на переключение — для этого необходимо будет найти способ определения моментов переключения контекстов, Clerk на васме писал про некоторые фичи Windows, которые позволяют засечь момент переключения контекстов.
Также желательно инвалидировать кеши 1 уровня перед замерами и очищать конвеер (например дальним вызовом, только тут может помешать предсказание переходов...).
2) В статье совсем не DLL инъекция, как заметили другие комментаторы, DLL инъекцию можно осуществить либо документированным способом ака хуком, инъекцией кода, подгружающего DLL, патч импортов файла, заменой DLL и т.д.; а здесь, как я понял, просто инъекция исполняемого кода
SELECT *, (
SELECT id
FROM photo_image AS pi
WHERE pi.g_id = pg.id
AND (
is_main_foto =1
OR is_main_foto =0
)
ORDER BY is_main_foto DESC
LIMIT 1
) AS Image_id
FROM `photo_gallery` AS pg
WHERE `c_id` =2
AND `is_published` =1
HAVING Image_id IS NOT NULL
ORDER BY `ordi` DESC
2) Для случая, когда известно, что у фотки точно есть слейдующая и предыдушая придумал такое:
SELECT pi2.id, pi2.ordi, pi3.id, pi3.ordi
FROM `photo_image` AS pi
INNER JOIN `photo_image` AS pi2 ON pi.g_id = pi2.g_id
INNER JOIN `photo_image` AS pi3 ON pi2.g_id = pi3.g_id
WHERE pi.`id` =167
AND pi.`is_published` =1
AND pi2.`is_published` =1
AND pi3.`is_published` =1
AND pi2.id != pi.id
AND pi3.id != pi.id
AND pi3.ordi > pi.ordi
AND pi2.ordi < pi.ordi
ORDER BY `pi2`.`id` ASC, pi3.id DESC
Если фотка первая или вторая, то можно дополнительный запрос использовать на проверку граничных значений.
3) Тут явно одним запросом не обойтись, пока идей нет. Хотелось бы посмотреть вариант автора.