Comments 82
Если просто умножать на матрицу, разве это не приведёт к линейным корреляциям между шифрованными и не шифрованными данными, тем самым сломав всю безопасность?
Если я правильно понял ваш вопрос, то как раз для решения данной проблемы используется различное количество итераций и использование различных матриц на каждой итерации, что существенно усиливает криптостойкость.
Любое последовательное перемножение на группы матриц можно свести к умножению на одну единственную матрицу, следовательно «задача сводится к предыдущей».
В мире криптоанализа любые незначительные линейные корреляции между входом и выходом — это сразу гвоздь в гроб алгоритма. Так например случилось с DES, там один из S-box ов оказался с незначительными линейными характеристики, что в итоге привело к возможности значительно снизить переборную сложность взлома алгоритма.
А вы предлагаете прямую линейную зависимость…
В мире криптоанализа любые незначительные линейные корреляции между входом и выходом — это сразу гвоздь в гроб алгоритма. Так например случилось с DES, там один из S-box ов оказался с незначительными линейными характеристики, что в итоге привело к возможности значительно снизить переборную сложность взлома алгоритма.
А вы предлагаете прямую линейную зависимость…
Это не совсем так, здесь не написано что этот алгоритм используется в первую очередь для шифрования изображений (например первая картинка — это одна итерация шифрования), к тому же количество если считать что «Любое последовательное перемножение на группы матриц можно свести к умножению на одну единственную матрицу», то это так, но откуда у вас в наличии все имеющиеся матрицы?
Количество вариантов матрицы равно 2^8n, где n-количество байт, таким образом при использовании float мы получаем 2^32 вариантов матриц, соответственно при x количестве итераций количество комбинаций возрастает до 2^32x, таким образом, допустим при 15 итерациях количество возрастает до 2^480, что представляет собой немаленькое число.
Количество вариантов матрицы равно 2^8n, где n-количество байт, таким образом при использовании float мы получаем 2^32 вариантов матриц, соответственно при x количестве итераций количество комбинаций возрастает до 2^32x, таким образом, допустим при 15 итерациях количество возрастает до 2^480, что представляет собой немаленькое число.
Если вы последовательно умножите некоторую матрицу на 15 разных матриц с некими числовыми значениями в ячейках, то результат получившийся в итоге может быть получен уменьшением исходной матрицы на всего одну матрицу, т.е. последовательное умножение на 15 матриц можно свести к умножению на одну матрицу, главное найти параметры для этой матрицы.
А дальше начинается проблема: например если злоумышленник сможет заставить вас зашифровать своё сообщение и вернуть ему шифрованный результат (вполне обычный сценарий в мире сетевых протоколов), то нахождение секретного ключа, т.е. параметров «мастер матрицы» — сведется к решению системы линейных уравнений, — задача с которой справится за доли секунды даже микроконтроллер. И это только один из многочисленных способа эксплуатации линейности между входом и выходом.
А дальше начинается проблема: например если злоумышленник сможет заставить вас зашифровать своё сообщение и вернуть ему шифрованный результат (вполне обычный сценарий в мире сетевых протоколов), то нахождение секретного ключа, т.е. параметров «мастер матрицы» — сведется к решению системы линейных уравнений, — задача с которой справится за доли секунды даже микроконтроллер. И это только один из многочисленных способа эксплуатации линейности между входом и выходом.
ЗЫ извиняюсь за опечатки — с телефона пишу
Ваша идея верна, есть несколько но:
1) Никто не заставляет вас шифровать все данные N разными матрицами последовательно, для того чтобы злоумышленник выявлял «мастер матрицу», вы так же можете разделить все данные на Х частей и каждую часть шифровать своей матрицей
2) При KPCA, т.е. то что вы описали как «А дальше начинается проблема:» решить систему «линейных уравнений» будет не совсем просто хотя бы потому, что при создании матрицы используется 4 неизвестных, а зашифрованные вектора состоят из трех элементов, таким образом мы получим три уравнения с четырьмя неизвестными.
1) Никто не заставляет вас шифровать все данные N разными матрицами последовательно, для того чтобы злоумышленник выявлял «мастер матрицу», вы так же можете разделить все данные на Х частей и каждую часть шифровать своей матрицей
2) При KPCA, т.е. то что вы описали как «А дальше начинается проблема:» решить систему «линейных уравнений» будет не совсем просто хотя бы потому, что при создании матрицы используется 4 неизвестных, а зашифрованные вектора состоят из трех элементов, таким образом мы получим три уравнения с четырьмя неизвестными.
Уважаемый, не пытайтесь изобретать криптографию, не имея хотя бы базовых знаний в этой области.
Даже всемирно известные эксперты-криптографы умудряются делать ошибки в дизайне алгоритмов, из за которых вся крипто-надежность летит к чертям.
И спасает тут только глубочайший анализ сотнями экспертов.
Ваш алгоритм уязвим практически ко всем возможным атакам, коме самых примитивных :-)
Даже всемирно известные эксперты-криптографы умудряются делать ошибки в дизайне алгоритмов, из за которых вся крипто-надежность летит к чертям.
И спасает тут только глубочайший анализ сотнями экспертов.
Ваш алгоритм уязвим практически ко всем возможным атакам, коме самых примитивных :-)
> 1) Никто не заставляет вас шифровать все данные N разными матрицами последовательно, для того чтобы злоумышленник выявлял «мастер матрицу», вы так же можете разделить все данные на Х частей и каждую часть шифровать своей матрицей
Я вас не очень понял, вы предлагаете менять ключ шифрования раз в несколько блоков? Современные алгоритмы обычно без проблем могут шифровать порядка 2^32 блоков, минимум, в зависимости от режима, без смены ключа и нарушения безопасности.
> 2) При KPCA, т.е. то что вы описали как «А дальше начинается проблема:» решить систему «линейных уравнений» будет не совсем просто хотя бы потому, что при создании матрицы используется 4 неизвестных, а зашифрованные вектора состоят из трех элементов, таким образом мы получим три уравнения с четырьмя неизвестными.
Ну тогда достаточно будет иметь две пары шифрованных/нешифрованных сообщений и у злоумышленника будет 4 неизвестных и 6 уравнений.
Я вас не очень понял, вы предлагаете менять ключ шифрования раз в несколько блоков? Современные алгоритмы обычно без проблем могут шифровать порядка 2^32 блоков, минимум, в зависимости от режима, без смены ключа и нарушения безопасности.
> 2) При KPCA, т.е. то что вы описали как «А дальше начинается проблема:» решить систему «линейных уравнений» будет не совсем просто хотя бы потому, что при создании матрицы используется 4 неизвестных, а зашифрованные вектора состоят из трех элементов, таким образом мы получим три уравнения с четырьмя неизвестными.
Ну тогда достаточно будет иметь две пары шифрованных/нешифрованных сообщений и у злоумышленника будет 4 неизвестных и 6 уравнений.
(П.С. не увидел ответа quarck)
Я конечно извиняюсь, но вы пропустили мимо комментарий выше, цепочку умножения матриц по закону умножения матриц можно свести к одной, а следовательно хоть 15, хоть 20 итераций всё равно конечно преобразование выглядит как умножение на одну единственную матрицу:
B' = (((P(q1) * B) * P(q2)) * P(q3)) = (P(q1) * P(q2) * P(q3)) * B = (P(q')) * B
По этому при количестве итераций не нужно будет подбирать 15 матриц, а достаточно подобрать всё так же одну.
Я конечно извиняюсь, но вы пропустили мимо комментарий выше, цепочку умножения матриц по закону умножения матриц можно свести к одной, а следовательно хоть 15, хоть 20 итераций всё равно конечно преобразование выглядит как умножение на одну единственную матрицу:
B' = (((P(q1) * B) * P(q2)) * P(q3)) = (P(q1) * P(q2) * P(q3)) * B = (P(q')) * B
По этому при количестве итераций не нужно будет подбирать 15 матриц, а достаточно подобрать всё так же одну.
Посмотрите пожалуйста ответ чуть выше. А именно пункт 1.
Хотелось бы прояснить еще 1 момент, почему на бумаге ваша формула верна, а при реализации алгортма не совсем.
Для примера можете просмотреть код, представленный в статье, там представлена упрощенная реализация этого алгоритма для uchar.
Представьте что у вас есть матрица 3х3 и вектор пикселя изображения, например (222, 111, 55), после их умножения вектор например стал (444, 222, 110)
Но дело в том что данные хранятся в uchar, соответственно выполняется «обрезание» mod 2^8, таким образом результирующий вектор будет (188, 222, 110), и он будет использоваться для следующей итерации шифрования, таким образом нельзя сделать результирующую «мастер матрицу», надеюсь объяснено понятно, вариант в пункте 1 выше является разновидностью.
Для примера можете просмотреть код, представленный в статье, там представлена упрощенная реализация этого алгоритма для uchar.
Представьте что у вас есть матрица 3х3 и вектор пикселя изображения, например (222, 111, 55), после их умножения вектор например стал (444, 222, 110)
Но дело в том что данные хранятся в uchar, соответственно выполняется «обрезание» mod 2^8, таким образом результирующий вектор будет (188, 222, 110), и он будет использоваться для следующей итерации шифрования, таким образом нельзя сделать результирующую «мастер матрицу», надеюсь объяснено понятно, вариант в пункте 1 выше является разновидностью.
mod 256 умножение ничем не хуже обычного умножения, в плане криптоанализа.
Я скажу даже больше, атакующему вообще не важно знать, как у вас устроен алгоритм внутри, достаточно знать что между входом и выходом — есть линейная зависимость.
Данная задача может быть решена так сказать в «в общем случае», для вектора N бит и искомой битовой матрицы N*N. Только тут уже потребуется N пар, и умножения все будут по модулю 2.
Я скажу даже больше, атакующему вообще не важно знать, как у вас устроен алгоритм внутри, достаточно знать что между входом и выходом — есть линейная зависимость.
Данная задача может быть решена так сказать в «в общем случае», для вектора N бит и искомой битовой матрицы N*N. Только тут уже потребуется N пар, и умножения все будут по модулю 2.
Если можете, предоставьте пожалуйста ссылку для решения задачи в общем случае, хотелось бы понять как именно это делается, из вашего предложения не совсем ясно.
mod 2^n это не жесткий mod 256, он зависит от количества n бит элемента вектора (для uchar выше это 8), на случай если вызывает сомнение почему mod 256.
Но, надеюсь, ситуация прояснилась что нельзя создать «мастер матрицу» или вы меня здесь поправите?
mod 2^n это не жесткий mod 256, он зависит от количества n бит элемента вектора (для uchar выше это 8), на случай если вызывает сомнение почему mod 256.
Но, надеюсь, ситуация прояснилась что нельзя создать «мастер матрицу» или вы меня здесь поправите?
Делается очень просто, N пар «вход-выход», записывается N уравнений с ячейками матрицы в качестве неизвестных, и линейно решается по модулю 2.
Мастер матрицу — почему же нельзя, все можно, арифметика на кольце mod 256 — практически такая-же. Деление только отличается (кстати имнно по этому у меня сомнения, что вы сможете расшифровать шифрованное обратно, если вы храните числа по модулю 256 :-) )
Мастер матрицу — почему же нельзя, все можно, арифметика на кольце mod 256 — практически такая-же. Деление только отличается (кстати имнно по этому у меня сомнения, что вы сможете расшифровать шифрованное обратно, если вы храните числа по модулю 256 :-) )
Если можете, предоставьте пожалуйста ссылку для решения задачи в общем случае, хотелось бы увидеть на конкретном примере, не совсем понятно почему по модулю 2.
Я написал вам, что там не mod 256, а mod 2^n, читайте пожалуйста.
Я рад что у вас есть сомнения, но у меня есть рабочий проект, который шифрует и расшифровывает обратно, основная часть его представлена здесь, всегда можете испробовать.
Видимо это мой первый и последний пост на хабр, слишком радостно тут встречают.
Я написал вам, что там не mod 256, а mod 2^n, читайте пожалуйста.
Я рад что у вас есть сомнения, но у меня есть рабочий проект, который шифрует и расшифровывает обратно, основная часть его представлена здесь, всегда можете испробовать.
Видимо это мой первый и последний пост на хабр, слишком радостно тут встречают.
Вам лишь справедливо указывают на недостатки
Посмотрите например: en.m.wikipedia.org/wiki/Hill_cipher — особенно раздел Security, там подробно все написано, алгоритм практически 1-в-1 такой же, что и у вас
Посмотрите например: en.m.wikipedia.org/wiki/Hill_cipher — особенно раздел Security, там подробно все написано, алгоритм практически 1-в-1 такой же, что и у вас
Простите, немного устал объяснять, данная статья основана на переработке статей Tomoyuki Nagase и некоторых других авторов, к сожалению в открытом доступе их нет, одна из них, например Secure Signals Transmission Based on Quaternion Encryption Scheme.
Вы можете узнать всю необходимую информацию оттуда, а именно почему он (или его вариация M-QES) является более защищенным в отличие от Hill Cipher и какие методы использовались для улучшения этой защиты по сравнению с Hill Cipher.
Один из вариантов таков, что все статьи этого автора по QES неверны, а правы вы, тогда приношу свои извинения.
Данная статья в первую очередь является обзорной и показывает возможности применения данного алгоритма для различных архитектур и показывает разницу между ними. Могу пояснить мою проделанную работу, а именно каковы результаты и почему они таковы. Спасибо.
Для выяснений криптостойкости прошу не читать мои попытки объяснения в комментариях, а обращаться к автору алгоритма, благодарю.
Вы можете узнать всю необходимую информацию оттуда, а именно почему он (или его вариация M-QES) является более защищенным в отличие от Hill Cipher и какие методы использовались для улучшения этой защиты по сравнению с Hill Cipher.
Один из вариантов таков, что все статьи этого автора по QES неверны, а правы вы, тогда приношу свои извинения.
Данная статья в первую очередь является обзорной и показывает возможности применения данного алгоритма для различных архитектур и показывает разницу между ними. Могу пояснить мою проделанную работу, а именно каковы результаты и почему они таковы. Спасибо.
Для выяснений криптостойкости прошу не читать мои попытки объяснения в комментариях, а обращаться к автору алгоритма, благодарю.
Я надеюсь что вы нашли в статьях свои ответы, пожалуйста дайте ссылки на ваши ответы, а именно:
1) «Делается очень просто, N пар «вход-выход», записывается N уравнений с ячейками матрицы в качестве неизвестных, и линейно решается по модулю 2.»
2) «Мастер матрицу — почему же нельзя, все можно, арифметика на кольце mod 256 — практически такая-же. Деление только отличается (кстати имнно по этому у меня сомнения, что вы сможете расшифровать шифрованное обратно, если вы храните числа по модулю 256 :-) )»
Желательно учитывая что это не mod 256, а mod 2^n
1) «Делается очень просто, N пар «вход-выход», записывается N уравнений с ячейками матрицы в качестве неизвестных, и линейно решается по модулю 2.»
2) «Мастер матрицу — почему же нельзя, все можно, арифметика на кольце mod 256 — практически такая-же. Деление только отличается (кстати имнно по этому у меня сомнения, что вы сможете расшифровать шифрованное обратно, если вы храните числа по модулю 256 :-) )»
Желательно учитывая что это не mod 256, а mod 2^n
Я честно говоря не понял, что вам не понятно. Я вроде все и так описал достаточно подробно. Вот более детально, если что: dl.dropboxusercontent.com/u/25074445/MasterMatrix.pdf — из-за формул вынес в отдельную pdf-ку.
Благодарю, сегодня буду пробовать.
Хотел бы уточнить несколько моментов.
Вы написали «При этом это будет работать, даже если изначально работа была не с отдельными битами, а с числами некоторой разрядности и операции были по модулю некоторому, например по модулю 2^n»
Допустим у меня есть миллион сообщений, исходных и зашифрованных одним и тем же ключом, соответственно теперь нам нужно количество бит элемента вектора…
1) как мне узнать количество бит вектора?
2) принципиально ли это, т.е. если исходные вектора например были по 192 бита, а я беру по 24 бита, то все будет ок?
3) будут ли какие-то изменения в зависимости от того целочисленный это тип данных или вещественный?
4) как мне узнать если данные были зашифрованы не с самого начала и важно ли это?
5) что мне делать если использовалось, допустим, 15 разных матриц в какой-то последовательности, как мне узнать какая матрица шифровала какой вектор или это вообще не нужно?
Очень жду ответа на все вопросы.
Вы написали «При этом это будет работать, даже если изначально работа была не с отдельными битами, а с числами некоторой разрядности и операции были по модулю некоторому, например по модулю 2^n»
Допустим у меня есть миллион сообщений, исходных и зашифрованных одним и тем же ключом, соответственно теперь нам нужно количество бит элемента вектора…
1) как мне узнать количество бит вектора?
2) принципиально ли это, т.е. если исходные вектора например были по 192 бита, а я беру по 24 бита, то все будет ок?
3) будут ли какие-то изменения в зависимости от того целочисленный это тип данных или вещественный?
4) как мне узнать если данные были зашифрованы не с самого начала и важно ли это?
5) что мне делать если использовалось, допустим, 15 разных матриц в какой-то последовательности, как мне узнать какая матрица шифровала какой вектор или это вообще не нужно?
Очень жду ответа на все вопросы.
1) — это зависит от размера блока, которым вы оперировали. Если вы берете по три 8-ми битных числа и кодируете в три 8-ми битных числа — то следовательно размер блока у вас 24 бита. Точнее ответить не смогу, не заглядывая в вашу реализацию непосредственно.
2) Не понял вопроса, не могу ответить без более точных технических данных о том, как на битовом уровне, вы кодируете / декодируете.
3) Вы еще в float храните? :) Вообще ответ такой-же как в 2), но в целом — преобразование во float — может ввести немного нелинейности, если не знать что это float, но если знать — то можно сконвертировать в fix point например, и дальше — как обычно.
4) Вы немного меняете задачу. Я вам говорил о наличии у вас пар открытый / шифрованный текст, по которым можно восстановить ключь. Что значит «не с самого начала» я не понимаю, т.к. не понимаю, что вы тут хотите сделать с этими «данными зашифрованными не самого начала».
5) У вас одна матрица — бинарная NxN, а что у алгоритма внутри — не имеет значения. Хоть 100000 матриц.
2) Не понял вопроса, не могу ответить без более точных технических данных о том, как на битовом уровне, вы кодируете / декодируете.
3) Вы еще в float храните? :) Вообще ответ такой-же как в 2), но в целом — преобразование во float — может ввести немного нелинейности, если не знать что это float, но если знать — то можно сконвертировать в fix point например, и дальше — как обычно.
4) Вы немного меняете задачу. Я вам говорил о наличии у вас пар открытый / шифрованный текст, по которым можно восстановить ключь. Что значит «не с самого начала» я не понимаю, т.к. не понимаю, что вы тут хотите сделать с этими «данными зашифрованными не самого начала».
5) У вас одна матрица — бинарная NxN, а что у алгоритма внутри — не имеет значения. Хоть 100000 матриц.
1) Я вас спросил как узнать, вы мне отвечаете, спросите у себя… хмм…
2) Технических данных? все необходимые технические данные по работе qes имеются в статье, что именно вас здесь не устраивает?
3) Я не храню во флоат, я задал вам вопрос как это изменит
4) хммм, я не меняю задачу, я показываю вам реальные варианты, у вас есть файлы, которые, допустим зашифрованы не с 1 бита, а с N, как узнать это?
5) У меня одна матрица? хмм, не понял ответа.
Перефразирую все вышесказанное, я предлагаю вам доказать ваши слова и предоставить на ваше усмотрение сколько угодно файлов, зашифрованных одними и теми же матрицами и одним и тем же алгоритмом, вы сможете за какой-нибудь реальный промежуток времени найти мастер матрицу и показать что все так просто как вы и говорите или это просто слова?
Я понимаю что вы скорее всего скажете что у вас есть куда более интересные и важные дела, а на такую ерунду нет времени…
Я бы и сам попробовал реализовать все что вы предложили, но к сожалению не получил от вас хороших ответов в предыдущем посте.
2) Технических данных? все необходимые технические данные по работе qes имеются в статье, что именно вас здесь не устраивает?
3) Я не храню во флоат, я задал вам вопрос как это изменит
4) хммм, я не меняю задачу, я показываю вам реальные варианты, у вас есть файлы, которые, допустим зашифрованы не с 1 бита, а с N, как узнать это?
5) У меня одна матрица? хмм, не понял ответа.
Перефразирую все вышесказанное, я предлагаю вам доказать ваши слова и предоставить на ваше усмотрение сколько угодно файлов, зашифрованных одними и теми же матрицами и одним и тем же алгоритмом, вы сможете за какой-нибудь реальный промежуток времени найти мастер матрицу и показать что все так просто как вы и говорите или это просто слова?
Я понимаю что вы скорее всего скажете что у вас есть куда более интересные и важные дела, а на такую ерунду нет времени…
Я бы и сам попробовал реализовать все что вы предложили, но к сожалению не получил от вас хороших ответов в предыдущем посте.
1, 2 — вы не предоставили технических данных, как непосредственно кодируется все, и какими блоками вы оперируете.
Вообще, если вы предоставите сам код, кодирующий / декодирующий, набор файлов (оригинал + шифрованное), то я берусь попробовать восстановить ключи (которых вы мне не сообщите).
Если исходники предоставить не можете — нужна грамотная техническая, подробная, спецификация, на все форматы. Того, что вы описали — недостаточно.
Конечно, в общем случае — можно все проанализировать и без подобных деталей, но сейчас задача стоит сломать шифрование, а не угодать формат файла.
P.S. только заниматься я этим буду после 24-ого числа, — 24 числа у меня супруга и дочка уезжают на каникулы на историческую родину, и я буду предоставлен сам себе на полтора месяца, так что по 1-2 часа в день — могу уделять. До 24-ого — вряд-ли смогу даже глянуть.
Вообще, если вы предоставите сам код, кодирующий / декодирующий, набор файлов (оригинал + шифрованное), то я берусь попробовать восстановить ключи (которых вы мне не сообщите).
Если исходники предоставить не можете — нужна грамотная техническая, подробная, спецификация, на все форматы. Того, что вы описали — недостаточно.
Конечно, в общем случае — можно все проанализировать и без подобных деталей, но сейчас задача стоит сломать шифрование, а не угодать формат файла.
P.S. только заниматься я этим буду после 24-ого числа, — 24 числа у меня супруга и дочка уезжают на каникулы на историческую родину, и я буду предоставлен сам себе на полтора месяца, так что по 1-2 часа в день — могу уделять. До 24-ого — вряд-ли смогу даже глянуть.
Отлично, попытаюсь объяснить более подробно что написано выше
«Для шифрования данных необходимо выполнить обычное умножение матриц, например: B' = P(q) * B, где B — данные которые необходимо зашифровать, P(q) — матрица поворота, B' — зашифрованные данные.»
Это основная часть алгоритма, вы мне уже много раз писали что вы понимаете что здесь идет обычное умножение на матрицу и что у этого умножения есть огромная проблема в виде линейных корреляций.
Как видно из википедии у нас имеется матрица поворота 3х3, мы берем данные в виде векторов 3*N байт и умножаем их на эту матрицу, получаем зашифрованные данные.
Вот собственно и весь алгоритм, что конкретно здесь не понятно?
Есть пример кода выше OpenCL/C++, он тоже непонятен?
«Для шифрования данных необходимо выполнить обычное умножение матриц, например: B' = P(q) * B, где B — данные которые необходимо зашифровать, P(q) — матрица поворота, B' — зашифрованные данные.»
Это основная часть алгоритма, вы мне уже много раз писали что вы понимаете что здесь идет обычное умножение на матрицу и что у этого умножения есть огромная проблема в виде линейных корреляций.
Как видно из википедии у нас имеется матрица поворота 3х3, мы берем данные в виде векторов 3*N байт и умножаем их на эту матрицу, получаем зашифрованные данные.
Вот собственно и весь алгоритм, что конкретно здесь не понятно?
Есть пример кода выше OpenCL/C++, он тоже непонятен?
Вы предоставили код 1 раунда шифрования. Какая связь между ним, и тем, что собственно будет в файлах — совершенно не ясно, т.к. не ясно, как именно вы будете реализовывать много-раундовость, какой режим шифрования (CBC, ECB, CTR) используете (если используете), как храните IV и какие заголовки у файла.
На все эти вопросы — нужны точные ответы, с точностью до бита.
Так что — я обозначил условия, на которых я согласен взяться за анализ: либо полные исходники (они все равно не представляют никакой коммерческой ценности, поверьте), либо детальная техническая спецификация форматов и алгоритмов.
На все эти вопросы — нужны точные ответы, с точностью до бита.
Так что — я обозначил условия, на которых я согласен взяться за анализ: либо полные исходники (они все равно не представляют никакой коммерческой ценности, поверьте), либо детальная техническая спецификация форматов и алгоритмов.
На мой взгляд совершенно ясно, arrD — исходный файл, любой, допустим формата .bmp как на картинке в начале, остальное — 9 элементов матрицы поворота.
Как можно догадаться из кода режим шифрования — ЕСВ.
Много-раундовость, у вас есть этот исходный код, представьте что я подаю исходный .bmp файл в это ядро (файл будет передаваться через массив arrD), на выходе будет зашифрованный файл.
В следующем раунде я подаю этот зашифрованный файл на вход этого же ядра, при этом могу поменять элементы матрицы и т.д. до N итераций шифрования.
Полные исходники представлены в этой статье, передается файл, передаются элементы матрицы, выполняется умножение, есть ли еще вопросы?
Один момент, в данном коде используется uchar, в спецификации qes в статьях указано, что количество бит в векторе это выбранная создателем величина, т.е. здесь вы видите что используется массив данных uchar, с таким же успехом этот массив может быть другого типа данных, например int, long long и т.п.
Т.е. вариации этого кода только таковы что, например uchar заменится на int или long long или float или double, произвольно выбрано мной.
Как я понял «При этом это будет работать, даже если изначально работа была не с отдельными битами, а с числами некоторой разрядности и операции были по модулю некоторому, например по модулю 2^n» это не сильно меняет задачу, т.к. как вы сказали все это будет работать.
Как можно догадаться из кода режим шифрования — ЕСВ.
Много-раундовость, у вас есть этот исходный код, представьте что я подаю исходный .bmp файл в это ядро (файл будет передаваться через массив arrD), на выходе будет зашифрованный файл.
В следующем раунде я подаю этот зашифрованный файл на вход этого же ядра, при этом могу поменять элементы матрицы и т.д. до N итераций шифрования.
Полные исходники представлены в этой статье, передается файл, передаются элементы матрицы, выполняется умножение, есть ли еще вопросы?
Один момент, в данном коде используется uchar, в спецификации qes в статьях указано, что количество бит в векторе это выбранная создателем величина, т.е. здесь вы видите что используется массив данных uchar, с таким же успехом этот массив может быть другого типа данных, например int, long long и т.п.
Т.е. вариации этого кода только таковы что, например uchar заменится на int или long long или float или double, произвольно выбрано мной.
Как я понял «При этом это будет работать, даже если изначально работа была не с отдельными битами, а с числами некоторой разрядности и операции были по модулю некоторому, например по модулю 2^n» это не сильно меняет задачу, т.к. как вы сказали все это будет работать.
Ок, давайте свои пары шифрованных/не шифрованных файлов, точнее как:
Вы выберете ключ (любой набор матриц), этим ключем зашифруйте один файл в пару сотен кб, и пришлите мне и оригинал и шифрованный файл, потом зашифруйте второй файл и пришлите мне только шифрованный.
Моя задача будет — восстановить второй файл, не зная исходного ключа.
Вы выберете ключ (любой набор матриц), этим ключем зашифруйте один файл в пару сотен кб, и пришлите мне и оригинал и шифрованный файл, потом зашифруйте второй файл и пришлите мне только шифрованный.
Моя задача будет — восстановить второй файл, не зная исходного ключа.
Хорошо, сегодня заменю в коде тип uchar на любой другой и вам скину 3 файла
вы только проверьте, что оно у вас, после этой замены, все так-же дешифруется нормально ;)
ЗЫ, вот небольшая наброска, как это собственно все будет работать:
pastebin.com/fNhPKFgf (код ужасный по стилю, конечно, в реальной жизни я так не напишу, но тут я торопился просто)
поскольку я знаю заранее, что там матрицы 3x3, я не буду опускатся до битового уровня — лишняя головная боль :)
А так, пример демонстрирует, как можно восстановить исходный ключ по 3м парам сообщений.
Правда есть ограничение на эти 3 пары — детерменант матрицы составленной из нешифрованных сообщений не должен быть нулевой, т.е. между векторами исходных сообщений не должно быть линейной зависимости. Что впрочем на случайных данных — практически всегда выполняется, а если где и не выполняется — можно просто взять другой датасет.
pastebin.com/fNhPKFgf (код ужасный по стилю, конечно, в реальной жизни я так не напишу, но тут я торопился просто)
поскольку я знаю заранее, что там матрицы 3x3, я не буду опускатся до битового уровня — лишняя головная боль :)
А так, пример демонстрирует, как можно восстановить исходный ключ по 3м парам сообщений.
Правда есть ограничение на эти 3 пары — детерменант матрицы составленной из нешифрованных сообщений не должен быть нулевой, т.е. между векторами исходных сообщений не должно быть линейной зависимости. Что впрочем на случайных данных — практически всегда выполняется, а если где и не выполняется — можно просто взять другой датасет.
Так же сообщите детали формата, на и что вы заменили uchar, что бы я решал криптографическую задачу, а не задачу угадывания формата.
Ждать — после 24-ого, я вам уже писал.
Ждать — после 24-ого, я вам уже писал.
Речи о том, что я вам предоставлю то, на что я заменил uchar не было потому, что вы написали:
«При этом это будет работать, даже если изначально работа была не с отдельными битами, а с числами некоторой разрядности и операции были по модулю некоторому, например по модулю 2^n»
К тому же мы рассматриваем условно реальный случай KPCA, давайте не будет упрощать задачу, благодарю.
Какие именно детали формата вас интересуют?
«При этом это будет работать, даже если изначально работа была не с отдельными битами, а с числами некоторой разрядности и операции были по модулю некоторому, например по модулю 2^n»
К тому же мы рассматриваем условно реальный случай KPCA, давайте не будет упрощать задачу, благодарю.
Какие именно детали формата вас интересуют?
Речь идет о том, что формат заранее известен. Как минимум размер блока. Это очевидное любому криптографу предположение, т.к. криптография занимается анализом заранее известных алгоритмов, а не «я тут накодил, что имеено не скажу, вы сами догадайтесь». Security by obscurity — это не безопасность.
Так что минимум размер блока в битах в студию.
Так что минимум размер блока в битах в студию.
Давайте посмотрим то что вы написали:
«Вы выберете ключ (любой набор матриц), этим ключем зашифруйте один файл в пару сотен кб, и пришлите мне и оригинал и шифрованный файл, потом зашифруйте второй файл и пришлите мне только шифрованный.
Моя задача будет — восстановить второй файл, не зная исходного ключа.»
1) Никаких требований по тому какой размер блока вы не писали.
2) Никаких требований по тому, что я предоставлю вам то, на что я заменю uchar тоже не было.
3) Вы написали что можно решить задачу в «общем случае», что я и хочу увидеть, алгоритм ведь простой, обычное умножение на матрицу как сказал oleg1977.
Тем не менее я вам помогу.
Размер блока может быть равен 24*N, где N может изменяться от 1 до 8 с шагом в 1.
Прошу заметить что при условно реальном случае KPCA вам никто предоставлять размер блока не будет.
«Вы выберете ключ (любой набор матриц), этим ключем зашифруйте один файл в пару сотен кб, и пришлите мне и оригинал и шифрованный файл, потом зашифруйте второй файл и пришлите мне только шифрованный.
Моя задача будет — восстановить второй файл, не зная исходного ключа.»
1) Никаких требований по тому какой размер блока вы не писали.
2) Никаких требований по тому, что я предоставлю вам то, на что я заменю uchar тоже не было.
3) Вы написали что можно решить задачу в «общем случае», что я и хочу увидеть, алгоритм ведь простой, обычное умножение на матрицу как сказал oleg1977.
Тем не менее я вам помогу.
Размер блока может быть равен 24*N, где N может изменяться от 1 до 8 с шагом в 1.
Прошу заметить что при условно реальном случае KPCA вам никто предоставлять размер блока не будет.
Давайте посмотрим то, что я вам написал:
<<Вообще, если вы предоставите сам код, кодирующий / декодирующий, набор файлов (оригинал + шифрованное), то я берусь попробовать восстановить ключи (которых вы мне не сообщите).
Если исходники предоставить не можете — нужна грамотная техническая, подробная, спецификация, на все форматы. Того, что вы описали — недостаточно.
Конечно, в общем случае — можно все проанализировать и без подобных деталей, но сейчас задача стоит сломать шифрование, а не угодать формат файла. >>
После чего мы договорились о формате файла — «как вы исходниках, что для ядра OpenCL», мы согласились на эти правила игры. Однако вы решили их поменять, после того, как пари было уже заключено.
Повторюсь: без предоставления мне детальной технической информации об алгоритме, я не собираюсь тратить свое время на то, что-бы заниматься угадыванием формата. Криптоанализ не занимается решением подобных вопросов. Этим занимаются хакеры, которые в два счета стащат у вас все исходники, если кому-то будет интересен ваш «алгоритм» ;)
Вообще, конечно можно проанализировать все это и в совсем общем случае, ни зная об алгоритме вообще ничего, используя различные инструменты криптоанализа, однако изначально задача об этом не шла, т.к. повторю свои слова еще раз:
<<Конечно, в общем случае — можно все проанализировать и без подобных деталей, но сейчас задача стоит сломать шифрование, а не угодать формат файла. >>
Так что я возвращаюсь к своим исходным условиям: либо исходники, либо детальное описание формата.
> Прошу заметить что при условно реальном случае KPCA вам никто предоставлять размер блока не будет.
потому что он заранее известен, т.к. известен используемый алгоритм, который, в отличии от вашей поделки, описал до мельчайших деталей, а не только размер блока.
<<Вообще, если вы предоставите сам код, кодирующий / декодирующий, набор файлов (оригинал + шифрованное), то я берусь попробовать восстановить ключи (которых вы мне не сообщите).
Если исходники предоставить не можете — нужна грамотная техническая, подробная, спецификация, на все форматы. Того, что вы описали — недостаточно.
Конечно, в общем случае — можно все проанализировать и без подобных деталей, но сейчас задача стоит сломать шифрование, а не угодать формат файла. >>
После чего мы договорились о формате файла — «как вы исходниках, что для ядра OpenCL», мы согласились на эти правила игры. Однако вы решили их поменять, после того, как пари было уже заключено.
Повторюсь: без предоставления мне детальной технической информации об алгоритме, я не собираюсь тратить свое время на то, что-бы заниматься угадыванием формата. Криптоанализ не занимается решением подобных вопросов. Этим занимаются хакеры, которые в два счета стащат у вас все исходники, если кому-то будет интересен ваш «алгоритм» ;)
Вообще, конечно можно проанализировать все это и в совсем общем случае, ни зная об алгоритме вообще ничего, используя различные инструменты криптоанализа, однако изначально задача об этом не шла, т.к. повторю свои слова еще раз:
<<Конечно, в общем случае — можно все проанализировать и без подобных деталей, но сейчас задача стоит сломать шифрование, а не угодать формат файла. >>
Так что я возвращаюсь к своим исходным условиям: либо исходники, либо детальное описание формата.
> Прошу заметить что при условно реальном случае KPCA вам никто предоставлять размер блока не будет.
потому что он заранее известен, т.к. известен используемый алгоритм, который, в отличии от вашей поделки, описал до мельчайших деталей, а не только размер блока.
Я вас не пойму, вам вроде было вчера всего достаточно, вы написали что задача решается в общем случае без всяких проблем, что видно теперь?
Я никаких правил игры не менял, давайте посмотрим что написано мной:
«Т.е. вариации этого кода только таковы что, например uchar заменится на int или long long или float или double, произвольно выбрано мной.»
Что после этого написано вами:
"Ок, давайте свои пары шифрованных/не шифрованных файлов, точнее как:
Вы выберете ключ (любой набор матриц), этим ключем зашифруйте один файл в пару сотен кб, и пришлите мне и оригинал и шифрованный файл, потом зашифруйте второй файл и пришлите мне только шифрованный.
Моя задача будет — восстановить второй файл, не зная исходного ключа."
Я также возвращаюсь к тому что вы раньше согласились найти супер матрицу и к тому, что исходники у вас имеются!!! И к тому что я написал что Я могу заменить uchar на что угодно и вы на это согласились.
Моя реализация алгоритма основана на статьях, в которых написано что размер блока равен 24*N бит ПО ВЫБОРУ, если не можете взломать, прошу признать это и закончить на этом.
Я никаких правил игры не менял, давайте посмотрим что написано мной:
«Т.е. вариации этого кода только таковы что, например uchar заменится на int или long long или float или double, произвольно выбрано мной.»
Что после этого написано вами:
"Ок, давайте свои пары шифрованных/не шифрованных файлов, точнее как:
Вы выберете ключ (любой набор матриц), этим ключем зашифруйте один файл в пару сотен кб, и пришлите мне и оригинал и шифрованный файл, потом зашифруйте второй файл и пришлите мне только шифрованный.
Моя задача будет — восстановить второй файл, не зная исходного ключа."
Я также возвращаюсь к тому что вы раньше согласились найти супер матрицу и к тому, что исходники у вас имеются!!! И к тому что я написал что Я могу заменить uchar на что угодно и вы на это согласились.
Моя реализация алгоритма основана на статьях, в которых написано что размер блока равен 24*N бит ПО ВЫБОРУ, если не можете взломать, прошу признать это и закончить на этом.
ладно, не буду с вами в полемику вступать. Однако я вас спрашивал про детальный формат файла, вы сказали — «как тот kernel», однако из исходных файлов я вижу что это не так — вы указали, что нет никаких заголовков, а они есть.
Не буду спорить, соглашусь на ваши условия, но предполагаю что речь идет о целочисленной арифметике, т.е. что вы не используете float/double-ов. Как я уже писал выше, подобные вещи могут внести нелинейность, но если заранее знать, что оно там есть — от нее можно избавится. Посколько вы не указали ничего такого, и речь о линейности — предполагаем что float-ов не используется, чисто целочисленная арифметика. (Опять-же, в реальном мире детали крипто-алгоритма всегда достоверно известны заранее, никто не пытается строить безопасность основываясь на том, что кто-то не знает деталей реализации — подобные попытки были в прошлом, и показали себя как наименее защищенные системы).
Что про заголовок — впрочем их исходных файлов и так понятно, докуда он.
Не буду спорить, соглашусь на ваши условия, но предполагаю что речь идет о целочисленной арифметике, т.е. что вы не используете float/double-ов. Как я уже писал выше, подобные вещи могут внести нелинейность, но если заранее знать, что оно там есть — от нее можно избавится. Посколько вы не указали ничего такого, и речь о линейности — предполагаем что float-ов не используется, чисто целочисленная арифметика. (Опять-же, в реальном мире детали крипто-алгоритма всегда достоверно известны заранее, никто не пытается строить безопасность основываясь на том, что кто-то не знает деталей реализации — подобные попытки были в прошлом, и показали себя как наименее защищенные системы).
Что про заголовок — впрочем их исходных файлов и так понятно, докуда он.
Хорошо, дабы вам не усложнять задачу более скажу, что там осталась целочисленная арифметика.
Я не сообщаю вам размер блока потому, что в статьях, как я уже в который раз повторяюсь он равен 24*N и указано, что он выбирается пользователем.
При КРСА, а мы его и рассматриваем сейчас, размер блока вам условно никто давать не должен.
Я не сообщаю вам размер блока потому, что в статьях, как я уже в который раз повторяюсь он равен 24*N и указано, что он выбирается пользователем.
При КРСА, а мы его и рассматриваем сейчас, размер блока вам условно никто давать не должен.
Раз уж вы отказываетесь привести подробное техническое описание формата, как я вас просил, буду выуживать по деталям.
Перед тем, как я начал тратить время, ответте на вот эти вопросы, пожалуйста:
1) В каком виде сериализуются N-битные целые числа? Сохраняются ли они как Big Endian, Little Endian, или как-то еще?
2) В случае когда например N=7, т.е. алгоритм работает с группами из трех чисел, каждое по 56 бит, — можете поточнее описать, как эти 56-ти битные числа, в каком формате, сохраняются в файл?
P.S. Я так-же надеюсь вы не мухлевали, и как и обговорено было, просто N раз прогнали один и тот-же алгоритм, каждый раз с новым ключем. Т.е. не примешивая никаких других операций, вроде XOR-ов, применения следующей итерации с небольшим смещением, итп.
Перед тем, как я начал тратить время, ответте на вот эти вопросы, пожалуйста:
1) В каком виде сериализуются N-битные целые числа? Сохраняются ли они как Big Endian, Little Endian, или как-то еще?
2) В случае когда например N=7, т.е. алгоритм работает с группами из трех чисел, каждое по 56 бит, — можете поточнее описать, как эти 56-ти битные числа, в каком формате, сохраняются в файл?
P.S. Я так-же надеюсь вы не мухлевали, и как и обговорено было, просто N раз прогнали один и тот-же алгоритм, каждый раз с новым ключем. Т.е. не примешивая никаких других операций, вроде XOR-ов, применения следующей итерации с небольшим смещением, итп.
1) Чтение файла и запись в файл назад идет через Qt, QDataStream, setByteOrder(QDataStream::BigEndian), можете посмотреть как реализовано
2) Специализированных типов данных я не использовал, по этому поводу можете не беспокоиться, хотя сделать их можно и работать они будут.
P.S. Да, никаких других операций примешано не было, ни XOR, ни применения следующей итерации ни с каким смещением и т.п.
Всё что было изменено по сравнению с предыдущим кодом, так это замена uchar на другой целочисленный формат, т.к. мне хотелось увидеть решение в общем случае.
Так же передаются данные, так же передаются матрицы, так же умножается. Все это выполняется N раз.
2) Специализированных типов данных я не использовал, по этому поводу можете не беспокоиться, хотя сделать их можно и работать они будут.
P.S. Да, никаких других операций примешано не было, ни XOR, ни применения следующей итерации ни с каким смещением и т.п.
Всё что было изменено по сравнению с предыдущим кодом, так это замена uchar на другой целочисленный формат, т.к. мне хотелось увидеть решение в общем случае.
Так же передаются данные, так же передаются матрицы, так же умножается. Все это выполняется N раз.
ЭЭЭ, т.е. вы сами не знаете, как оно в итоге сериализуется, а я должен угадывать и/или ковыряться в исходниках библиотеки, насчитывающей не один десяток МБ исходников на C++????
2) — каким образом тогда вы работаете с, например, 56-битными числами? Или в формуле 24*N, N не может быть равным 7-ми?
Без подобной информации что-либо делать мне — безсмысленно. Как я сказал — я согласен решать задачу крипто-анализа, а не угадывания вашего формата файла.
2) — каким образом тогда вы работаете с, например, 56-битными числами? Или в формуле 24*N, N не может быть равным 7-ми?
Без подобной информации что-либо делать мне — безсмысленно. Как я сказал — я согласен решать задачу крипто-анализа, а не угадывания вашего формата файла.
1) Я же написал что Big Endian, этого недостаточно?
2) Я с ними не работаю, достаточно стандартных типов данных, может быть равно 7, теоретически может быть равно и больше, я не проверял, поэтому утверждать не буду.
Что-то еще?
2) Я с ними не работаю, достаточно стандартных типов данных, может быть равно 7, теоретически может быть равно и больше, я не проверял, поэтому утверждать не буду.
Что-то еще?
1) Вы написали «Чтение файла и запись в файл назад идет через Qt,… можете посмотреть как реализовано»,
а не то, что оно однозначно там в Big Endian
2) Каким образом вы пишите 56-битные числа на диск, при N==7??? Вы можете внятно ответить на этот вопрос? Я понимаю, что в случае N=7, скорее всего работа идет с 64-битным числом, которое обрезается операцией &MASK. Но как вы его потом записываете на диск, вы же сохраняете только 7 байт из 8-ми. Вот опишите этот момент подробно.
а не то, что оно однозначно там в Big Endian
2) Каким образом вы пишите 56-битные числа на диск, при N==7??? Вы можете внятно ответить на этот вопрос? Я понимаю, что в случае N=7, скорее всего работа идет с 64-битным числом, которое обрезается операцией &MASK. Но как вы его потом записываете на диск, вы же сохраняете только 7 байт из 8-ми. Вот опишите этот момент подробно.
1) Я написал «setByteOrder(QDataStream::BigEndian), можете посмотреть как реализовано», то что вы это не заметили это уже другое дело
2) Я уже во второй раз говорю, используются только стандартные типы данных, зачем мне вам описывать то, чего нет?
2) Я уже во второй раз говорю, используются только стандартные типы данных, зачем мне вам описывать то, чего нет?
2) при N=7, как будет происходить запись стандартных типов в файл?
2) Предлагаю вам включить воображение, как хотите так и записывайте, главно чтоб правильно работало.
Так же можете поискать все это в Google, как работать с нестандартными типами данных.
Если нет представления об этом, то один из вариантов — посмотреть как выполняется сохранение в файл в длинной арифметике.
Так же можете поискать все это в Google, как работать с нестандартными типами данных.
Если нет представления об этом, то один из вариантов — посмотреть как выполняется сохранение в файл в длинной арифметике.
Вы издеваетесь??? Откуда я знаю что значит в вашем понимании «чтоб правильно работало», если я не знаю, в каком виде вы сериализуете например 56-ти битные числа в файл??
Существует более одного способа сериализовать подобное. И я не собираюсь угадывать формат, как я вам писал в самом начале.
Существует более одного способа сериализовать подобное. И я не собираюсь угадывать формат, как я вам писал в самом начале.
Так так, погодите, вы требуете от меня описать то, что я не использую?? Спросите меня тогда массу Земли с точностью до грамма
Пишу в третий раз, используются только стандартные типы данных.
Т.е. вы подтверждаете что не можете получить ключ если я вам не предоставлю тип данных? Ну и соответственно размер блока.
А я думал что вы можете получить ключ без типа данных…
Вы же писали:
«При этом это будет работать, даже если изначально работа была не с отдельными битами, а с
числами некоторой разрядности и операции были по модулю некоторому, например по
модулю 2^n, — просто в получившихся формулах «автоматически» выведутся логические
битовые формулы для операций сложения чисел более высоких разрядностей на основани их
битового представления.»
Я это и хотел увидеть, видимо не увижу( Или все-таки увижу?
Пишу в третий раз, используются только стандартные типы данных.
Т.е. вы подтверждаете что не можете получить ключ если я вам не предоставлю тип данных? Ну и соответственно размер блока.
А я думал что вы можете получить ключ без типа данных…
Вы же писали:
«При этом это будет работать, даже если изначально работа была не с отдельными битами, а с
числами некоторой разрядности и операции были по модулю некоторому, например по
модулю 2^n, — просто в получившихся формулах «автоматически» выведутся логические
битовые формулы для операций сложения чисел более высоких разрядностей на основани их
битового представления.»
Я это и хотел увидеть, видимо не увижу( Или все-таки увижу?
Во первых, есть разница между «можно» и я могу. Профессиональные криптографы справятся с этой задачей на раз, а я лишь собирался показать, что ваш алгоритм легко может быть взломан в частном случае, когда известно что у него внутри (впрочем криптогоафы никогда в серьез не занимаются случаями, когда реализация не известна).
Бонально мне лень реализовывать такие вещи, как например подсчет детерминанта матрицы произвольной размерности — я не вижу смысла тратить столько времени на то, что бы доказать не пойми кому простые азбучные истины, изучаемые на первых страницах любого учебника по криптоанализу.
А частный случай — пожалуйста, берусь.
Бонально мне лень реализовывать такие вещи, как например подсчет детерминанта матрицы произвольной размерности — я не вижу смысла тратить столько времени на то, что бы доказать не пойми кому простые азбучные истины, изучаемые на первых страницах любого учебника по криптоанализу.
А частный случай — пожалуйста, берусь.
Хорошо, я понял, вам лень, давайте уж хоть частный случай взломаем, буду рад хоть это увидеть.
Надеюсь это не займет месяц, тип данных — unsigned short.
Надеюсь это не займет месяц, тип данных — unsigned short.
Не займет.
Мастер-матрица, дешифрующая файл (т.е. это уже обратная матрица):
u_int16_t matrix[9] = { 17753, 49212, 16816, 56260, 37849, 28576, 27472, 60448, 24961 };
Сам файл дешифрованный:
dl.dropboxusercontent.com/u/25074445/ohwell.bmp
Мастер-матрица, дешифрующая файл (т.е. это уже обратная матрица):
u_int16_t matrix[9] = { 17753, 49212, 16816, 56260, 37849, 28576, 27472, 60448, 24961 };
Сам файл дешифрованный:
dl.dropboxusercontent.com/u/25074445/ohwell.bmp
P.S. Вообще, решений системы уравний, из-за неоднозначности деления на кольце, больше чем одно, так что эта матрица — не единственная скорее всего.
Поздравляю, вы были правы, оказывается алгоритм японца и гроша не стоит скажите насколько сильно изменит задачу решение в общем виде при незнании типа данных?
А у него в статье написано: «QES in insuring the highest level of security is reported» Вот так вот доверять статьям профессоров.
Вы использовали тот код, который выложили в начале или другой?
А у него в статье написано: «QES in insuring the highest level of security is reported» Вот так вот доверять статьям профессоров.
Вы использовали тот код, который выложили в начале или другой?
В общем виде — подход будет совсем другой, работать нужно с отдельными битами, соответственно даже для uchar вместо 9 неизвестных будет 24*24=576 (правда бинарных — каждая будет либо 1 либо 0), и соответственно нужна система из 576 уравнений. Это все решаемо, но кодить и отлаживать — тот ещё гемор. Про подсчет детерминанта я уже писал — пожалуй самая невеселая часть.
Код я использовал практически тот же, что и выложил, с небольшой модификацией: деление на кольце по модулю часто имеет более одного результата, но далеко не все они решают исходную систему уравнений, так что я добавил перебор среди возможных решений, что бы оно находило те значения, которые «подходят». При этом перебрать долго не приходится: если я вижу, что вариантов слишком много, я просто перехожу к следующему блоку. Число вариантов варьировалось от 64 до 16000^3, так что я выбирал только те данные, где 64 или аналогично возможных решений, перебирается это мгновенно.
Возможно если бы вы использовали 64х битные типы — мне пришлось бы подождать пару часов, пока среди миллионов возможных решений найдётся нужное :) но надо сказать, что сама переборная сложность тут не велика, т.к. по сути тут не система из 9 уравнений, а три независимых системы по 3, соответственно перебирать нужно не девятую степень а третью. В случае решения в общем виде, кстати, такой проблемы быть не должно, там детерминант будет либо 0 (вырожденная система не имеющая решения), либо 1, а деление на 1 — всегда однозначная операция :)
Код я использовал практически тот же, что и выложил, с небольшой модификацией: деление на кольце по модулю часто имеет более одного результата, но далеко не все они решают исходную систему уравнений, так что я добавил перебор среди возможных решений, что бы оно находило те значения, которые «подходят». При этом перебрать долго не приходится: если я вижу, что вариантов слишком много, я просто перехожу к следующему блоку. Число вариантов варьировалось от 64 до 16000^3, так что я выбирал только те данные, где 64 или аналогично возможных решений, перебирается это мгновенно.
Возможно если бы вы использовали 64х битные типы — мне пришлось бы подождать пару часов, пока среди миллионов возможных решений найдётся нужное :) но надо сказать, что сама переборная сложность тут не велика, т.к. по сути тут не система из 9 уравнений, а три независимых системы по 3, соответственно перебирать нужно не девятую степень а третью. В случае решения в общем виде, кстати, такой проблемы быть не должно, там детерминант будет либо 0 (вырожденная система не имеющая решения), либо 1, а деление на 1 — всегда однозначная операция :)
Спасибо, очень интересно, выложите пожалуйста код если можете и еще пару вопросов.
Какова зависимость между типами данных при поиске матрицы? Перефразирую более понятно: допустим используеться uchar и unisigned short, количество бит в два раза больше, допустим если для uchar матрица будет находиться в течение 5 минут, то для unsigned short сколько? 10 минут? а для 64 бит?
В первую очередь интересно то, что если время растет нелинейно, то можно использовать большие числа, т.е. более 64 бит.
Есть еще другой вариант — матрица поворота 8*8 на основе октонионов, суть та же, насколько это будет лучше если вообще будет лучше?
Какова зависимость между типами данных при поиске матрицы? Перефразирую более понятно: допустим используеться uchar и unisigned short, количество бит в два раза больше, допустим если для uchar матрица будет находиться в течение 5 минут, то для unsigned short сколько? 10 минут? а для 64 бит?
В первую очередь интересно то, что если время растет нелинейно, то можно использовать большие числа, т.е. более 64 бит.
Есть еще другой вариант — матрица поворота 8*8 на основе октонионов, суть та же, насколько это будет лучше если вообще будет лучше?
Код решения:
dl.dropboxusercontent.com/u/25074445/code/solve.cpp
И декодирующая утилитка:
dl.dropboxusercontent.com/u/25074445/code/decode.cpp
Тут стоит откомментировать, что похоже у систем уравнений существует более чем одно решение, удовлетворяющее всем условиям, и по хорошему нужно брать, искать все решения для нескольких из систем (на разных блоках исходных данных) и находить потом пересечение между множествами решений что-бы найти «самую универсальную мастер матрицу». Мне все это было влом делать, мой код печатает первое попавшееся решение, но проходится последовательно по блокам из 9-ти 2х байтных ushort-ов, и потом я глазками смотрел — каких решений больше всего, то предположительно и самое-самое, — угодал с первой попытки :) (Как я сказал, деление довольно медленное, так что я не стал дожидатся даже окончания обработки файлов).
Так что что-бы сделать «универсальную ломалку» — нужно код еще дорабатывать, но у меня такой задачи не было.
По поводу деления на кольце, сейчас оно сделано очень тупо:
Такой подход — довольно медленный, но работает для 16-битных чисел. Для 64-битных чисел — я припас, на всякий случай, уже быстрый вариант — функция ring_div (делит a на b по модулю 2^nbits), — использует расширеный алгоритм Евклида, но находит только одно из возможных решений. Впрочем если есть одно, то все остальные можно найти довольно быстро, добавляя к предыдущему результату 2^nbits и потом вычитая несколько раз b (т.е. то, на что делим), пока снова не получится число влезающее в nbits бита, и потом продолжаем вычитать, пока оно не станет отрицательным. Но т.к. оно оказалось 16-ти битным — решил не усложнять себе жизнь. (Как работает алгоритм евклида — я могу рассказать на пальцах, но как работает та функция — объяснить не смогу — я нашел готовый код в инете, могу сказать — работает она мгновенно, по сравнению с тем, что у меня для 16-ти бит).
Да, отсюда-же можно и оценить, сколько числел в итоге получается у операции деления — по разнице между наименьшим числом вида b*N превышающим 2^nbits и 2^nbits, — если эта разница очень маленькая — чисел будет много, точнее говоря чисел будет примерно 2^nbits / (b*N — 2^nbits), — так что можно сразу отсекать неудачные системы уравнений и рассматривать только те, где решений меньше чем заданное количество. (И да, я там использовал тип __int128_t, — это расширение gcc, не уверен что этот тип есть на других платформах, но для решения 16-ти битного случая — не думаю что он нужен).
Вообще, по поводу решений этих систем — у меня нет уверенности, что я делаю это самым оптимальным образом, возможно есть какой-то математический трюк, позволяющий моментально найти нужную, отсеив все побочные решения. Так что не уверен, что расширение разрябности до 64 или даже 128 бит реально может помочь. Равно как и использование матриц вращения больших размерностей. (Но вообще — я не криптограф по образованию, у меня относительно поверхностные знания криптографии, — я думаю профессиональные криптоаналитики смогли бы ответить куда развернутей, но — их время ужасно дорого ;) )
А что касается доверять профессорам — так я уже писал, в мире криптографии нельзя доверять одному человеку, каким бы авторитетом он не был. Доверять можно только тем случаям, когда код или алгоритмы были выверены сотнями исследователей и разработчиков (как например с AES), и даже в подобных случаях — порой находятся такие уязвимости, которые ломают всю безопасность на корню (как например 2 раза случилось с OpenSSL за последние месяцы).
dl.dropboxusercontent.com/u/25074445/code/solve.cpp
И декодирующая утилитка:
dl.dropboxusercontent.com/u/25074445/code/decode.cpp
Тут стоит откомментировать, что похоже у систем уравнений существует более чем одно решение, удовлетворяющее всем условиям, и по хорошему нужно брать, искать все решения для нескольких из систем (на разных блоках исходных данных) и находить потом пересечение между множествами решений что-бы найти «самую универсальную мастер матрицу». Мне все это было влом делать, мой код печатает первое попавшееся решение, но проходится последовательно по блокам из 9-ти 2х байтных ushort-ов, и потом я глазками смотрел — каких решений больше всего, то предположительно и самое-самое, — угодал с первой попытки :) (Как я сказал, деление довольно медленное, так что я не стал дожидатся даже окончания обработки файлов).
Так что что-бы сделать «универсальную ломалку» — нужно код еще дорабатывать, но у меня такой задачи не было.
По поводу деления на кольце, сейчас оно сделано очень тупо:
for (int i=0; i<TMAX; i++)
{
if ( ((det0+TMAX*i) % det) == 0)
{
T result = (det0+TMAX*i) / det;
....
Такой подход — довольно медленный, но работает для 16-битных чисел. Для 64-битных чисел — я припас, на всякий случай, уже быстрый вариант — функция ring_div (делит a на b по модулю 2^nbits), — использует расширеный алгоритм Евклида, но находит только одно из возможных решений. Впрочем если есть одно, то все остальные можно найти довольно быстро, добавляя к предыдущему результату 2^nbits и потом вычитая несколько раз b (т.е. то, на что делим), пока снова не получится число влезающее в nbits бита, и потом продолжаем вычитать, пока оно не станет отрицательным. Но т.к. оно оказалось 16-ти битным — решил не усложнять себе жизнь. (Как работает алгоритм евклида — я могу рассказать на пальцах, но как работает та функция — объяснить не смогу — я нашел готовый код в инете, могу сказать — работает она мгновенно, по сравнению с тем, что у меня для 16-ти бит).
Да, отсюда-же можно и оценить, сколько числел в итоге получается у операции деления — по разнице между наименьшим числом вида b*N превышающим 2^nbits и 2^nbits, — если эта разница очень маленькая — чисел будет много, точнее говоря чисел будет примерно 2^nbits / (b*N — 2^nbits), — так что можно сразу отсекать неудачные системы уравнений и рассматривать только те, где решений меньше чем заданное количество. (И да, я там использовал тип __int128_t, — это расширение gcc, не уверен что этот тип есть на других платформах, но для решения 16-ти битного случая — не думаю что он нужен).
Вообще, по поводу решений этих систем — у меня нет уверенности, что я делаю это самым оптимальным образом, возможно есть какой-то математический трюк, позволяющий моментально найти нужную, отсеив все побочные решения. Так что не уверен, что расширение разрябности до 64 или даже 128 бит реально может помочь. Равно как и использование матриц вращения больших размерностей. (Но вообще — я не криптограф по образованию, у меня относительно поверхностные знания криптографии, — я думаю профессиональные криптоаналитики смогли бы ответить куда развернутей, но — их время ужасно дорого ;) )
А что касается доверять профессорам — так я уже писал, в мире криптографии нельзя доверять одному человеку, каким бы авторитетом он не был. Доверять можно только тем случаям, когда код или алгоритмы были выверены сотнями исследователей и разработчиков (как например с AES), и даже в подобных случаях — порой находятся такие уязвимости, которые ломают всю безопасность на корню (как например 2 раза случилось с OpenSSL за последние месяцы).
ЗЗЫ — а вообще, самый главный урок, которому учат профессиональные криптографы: никогда не изобретайте криптографию самостоятельно. С вероятностью 99.9999999% будут сделаны ошибки, ломающие всю защиту. (При этом для профессоров уважаемых эта вероятность будет все равно на уровне 99.9%).
По вашему выходит, что если взять любой шифр и использовать его с разными ключами n раз, то криптостойкость алгоритма возрастет в n раз. А все стараются, выдумывают новые алгоритмы.
Если вы говорите о шифре, как я догодываюсь, о блочном, то ответьте для начала на вопросы: какова длина ключа, можно ли ваш шифр как любой блочный использовать в режимах ECB, CBC, CFB, OFB, CTR, CCM?
Прочитайте статьи habrahabr.ru/post/181372/ и habrahabr.ru/post/186416/.
Если, как вы пишите ниже, вас не интересует криптография, а интересует вычислительная сторона вопроса, назовите статью «Умножение на матрицу соответствующую кватерниону на FPGA, XeonPhi, GPU».
Если вы говорите о шифре, как я догодываюсь, о блочном, то ответьте для начала на вопросы: какова длина ключа, можно ли ваш шифр как любой блочный использовать в режимах ECB, CBC, CFB, OFB, CTR, CCM?
Прочитайте статьи habrahabr.ru/post/181372/ и habrahabr.ru/post/186416/.
Если, как вы пишите ниже, вас не интересует криптография, а интересует вычислительная сторона вопроса, назовите статью «Умножение на матрицу соответствующую кватерниону на FPGA, XeonPhi, GPU».
К сожалению вы не понимаете, так выходит не по моему, а по статьям создателя алгоритма, попрошу за вопросами обращаться к нему.
Прошу за ответами на ваши вопросы обращаться к автору и смотреть его статьи.
Прочитал статьи, ваша взяла, пусть я буду некомпетентен, видимо как и создатель алгоритма, спасибо.
Меня не интересует доказывать вам криптостойкость алгоритма, это не мой алгоритм и я не буду доказывать то, что он самый лучший среди всех. Автор назвал ваше умножение на матрицу как Quaternion Encryption Scheme, претензии по названии отправлять к нему, благодарю.
Прошу за ответами на ваши вопросы обращаться к автору и смотреть его статьи.
Прочитал статьи, ваша взяла, пусть я буду некомпетентен, видимо как и создатель алгоритма, спасибо.
Меня не интересует доказывать вам криптостойкость алгоритма, это не мой алгоритм и я не буду доказывать то, что он самый лучший среди всех. Автор назвал ваше умножение на матрицу как Quaternion Encryption Scheme, претензии по названии отправлять к нему, благодарю.
Перед прочтением всех комментариев рекомендую прочитать
habrahabr.ru/post/226779/#comment_7699309
Это сэкономит вам немного времени, спасибо.
habrahabr.ru/post/226779/#comment_7699309
Это сэкономит вам немного времени, спасибо.
Извините, если кажусь наивным, но правильно ли я понимаю, что в этой статье вы сравниваете производительность перемножения двух матриц на сопроцессоре Xeon Phi за три тысячи баксов с всего лишь 61 ядром (оно?) с Теслой на ~2500 ядер (вроде она)?
Операцию перемножения матриц можно неплохо распараллелить, и на больших матрицах должен победить тот, у кого ядер больше.
С другим оборудованием, я никогда не сталкивался, равно как и с перечисленными выше. Но раз, он обработал все итерации за одинаковое количество времени. Я нагуглил тут какую-то страничку, где говорится, что там есть парочка сотен тысяч каких-то логических модулей (простите, но я по-ламерки думаю в «CUDA» ядрах).
То, что я вынес из статьи — это то, что все дорогие штуки, у которых много ядер обрабатывают хорошо распараллеливающийся код эффективнее, чем те, у кого ядер мало.
Энергопотребление здесь не решающий фактор.
Операцию перемножения матриц можно неплохо распараллелить, и на больших матрицах должен победить тот, у кого ядер больше.
С другим оборудованием, я никогда не сталкивался, равно как и с перечисленными выше. Но раз, он обработал все итерации за одинаковое количество времени. Я нагуглил тут какую-то страничку, где говорится, что там есть парочка сотен тысяч каких-то логических модулей (простите, но я по-ламерки думаю в «CUDA» ядрах).
То, что я вынес из статьи — это то, что все дорогие штуки, у которых много ядер обрабатывают хорошо распараллеливающийся код эффективнее, чем те, у кого ядер мало.
Энергопотребление здесь не решающий фактор.
upd: хотя вглядевшись в график, я могу усомниться, почему тесла при меньших ядрах обработала ваш код быстрее. Может быть разное число мегагерц, или где-нибудь мы просели по скорости передачи данных, или особенностями «FPGA»… Тут надо копать глубже, чтобы ответить на этот вопрос, очень мало информации.
Да, эти две версии, + FPGA на ~235000 логических элементов, они являются гораздо более простыми элементами, чем ядра видеокарты, подробно расписано как раз по вашей ссылке.
Совершенно верно, побеждает тот и у кого ядер больше и у кого конвейер лучше, но хотелось бы виделить некоторые пункты:
1) «К сожалению эти результаты далеко не самые лучшие, т.к. при программировании использовалась технология OpenMP и возможность автоматической оптимизации компилятора Intel. При программировании на более низком уровне, т.е. например intrinsic команд, результаты могут улучшиться в несколько раз.»
Я лично видел как в других проектах при использовании intrinsic, производительность возрастала в 2-4 раз по сравнению с обычным OpenMP, таким образом цифры графика у XeonPhi теоретически можно разделить в 2 — 4 раза.
К тому же пиковая производительность double у данных устройств ~1.2 TFlops, согласно intel.com и ссылке на Tesla, точной информации по fpga не имеется.
2) По поводу «ядер больше». Отдельным моментом хотелось бы указать что на FPGA создается всего 13 ядер.
Т.е. результаты таковы: FPGA — 13, XeonPhi — 61 (244 threads), Tesla — 2496.
Если брать в счет всего 1 итерацию, то все эти вычислители легко выигрывает обычный Core i5, но при 25 итерациях время шифрования у Core i5 увеличивается приблизительно в 25 раз, в то время как у этих вычислителей нет.
3) У FPGA при 13 ядрах почти не изменяется результат при 1, 5, 9, 15, 25 итерациях благодаря почти полной конвейеризации.
На первый взгляд не совсем понятно как это достигается если вы не знаете что такое FPGA, но представить это можно так, что FPGA из 235000 своих логических элементов создает 13 специализированных ядер именно для решения данной задачи.
При этом для 1 итерации используется около 50% всех логических элементов, а для 25 итераций около 80%.
Этот результат не является идеальным, но он выполнен с помощью OpenCL, не нужно почти никаких модификаций кода, если у вас уже есть код для GPU.
Если же вам нужна еще большая производительность, то добро пожаловать в мир Verilog и т.п. языков.
Энергопотребление является решающим фактором если вам нужно что-то шифровать или выполнять другие задачи постоянно, т.к. количество потребляемой энергии у FPGA приблизительно в 2 раза ниже чем у Tesla и в 3 раза ниже чем у XeonPhi.
Из очевидных минусов именно этой платы DE5-net можно назвать ее стоимость, а именно около 8000$.
Совершенно верно, побеждает тот и у кого ядер больше и у кого конвейер лучше, но хотелось бы виделить некоторые пункты:
1) «К сожалению эти результаты далеко не самые лучшие, т.к. при программировании использовалась технология OpenMP и возможность автоматической оптимизации компилятора Intel. При программировании на более низком уровне, т.е. например intrinsic команд, результаты могут улучшиться в несколько раз.»
Я лично видел как в других проектах при использовании intrinsic, производительность возрастала в 2-4 раз по сравнению с обычным OpenMP, таким образом цифры графика у XeonPhi теоретически можно разделить в 2 — 4 раза.
К тому же пиковая производительность double у данных устройств ~1.2 TFlops, согласно intel.com и ссылке на Tesla, точной информации по fpga не имеется.
2) По поводу «ядер больше». Отдельным моментом хотелось бы указать что на FPGA создается всего 13 ядер.
Т.е. результаты таковы: FPGA — 13, XeonPhi — 61 (244 threads), Tesla — 2496.
Если брать в счет всего 1 итерацию, то все эти вычислители легко выигрывает обычный Core i5, но при 25 итерациях время шифрования у Core i5 увеличивается приблизительно в 25 раз, в то время как у этих вычислителей нет.
3) У FPGA при 13 ядрах почти не изменяется результат при 1, 5, 9, 15, 25 итерациях благодаря почти полной конвейеризации.
На первый взгляд не совсем понятно как это достигается если вы не знаете что такое FPGA, но представить это можно так, что FPGA из 235000 своих логических элементов создает 13 специализированных ядер именно для решения данной задачи.
При этом для 1 итерации используется около 50% всех логических элементов, а для 25 итераций около 80%.
Этот результат не является идеальным, но он выполнен с помощью OpenCL, не нужно почти никаких модификаций кода, если у вас уже есть код для GPU.
Если же вам нужна еще большая производительность, то добро пожаловать в мир Verilog и т.п. языков.
Энергопотребление является решающим фактором если вам нужно что-то шифровать или выполнять другие задачи постоянно, т.к. количество потребляемой энергии у FPGA приблизительно в 2 раза ниже чем у Tesla и в 3 раза ниже чем у XeonPhi.
Из очевидных минусов именно этой платы DE5-net можно назвать ее стоимость, а именно около 8000$.
Авторы (T. Nagase et al) в своих статьях о криптостойкости предложенной ими схемы «шифрования» ничего не сообщают.
Предложенный авторами метод key schedule слаб, т.к. N раундов, которые сводятся к одному раунду с другим ключом — это просто абзац, о чем выше коллеги уже намекнули. Тем более, если можно тривиально найти ключ по входным и выходным данным в алгоритме с одним раундом. В используемых на практике алгоритмах шифрования таких изъянов нет.
Предложенный авторами метод key schedule слаб, т.к. N раундов, которые сводятся к одному раунду с другим ключом — это просто абзац, о чем выше коллеги уже намекнули. Тем более, если можно тривиально найти ключ по входным и выходным данным в алгоритме с одним раундом. В используемых на практике алгоритмах шифрования таких изъянов нет.
Уважаемый, могу ли я попросить вас найти ключ тривиально?
Выше уже привели пример кода, который именно это и делает.
Я хотел бы вас поправить, выше приведен пример кода, который именно это и должен делать, то что он это делает это на данный момент еще не доказано, попробуйте использовать его для 3 файлов, которые я предоставил, добудьте ключ и предоставьте 4 расшифрованный файл, тогда это будет доказано.
Могли бы вы это сделать или на этом стоит закончить?
Могли бы вы это сделать или на этом стоит закончить?
Участвовать в этом развлечении имеет смысл только так:
1) Участник повторяет Вашу и Nagase сотоварищи работу на OpenCL (Я готов повторить, если мозг за пять лет после написания курсовой на нем не высох окончательно)
2) Участник публикует исходники, если считает, что понял условия конкурса.
3) Вы компилируете исходники участника и шифруете исходное изображение «flag.bmp» Вашим исходным ключом.
4) Если результат не совпадает с «flagE.bmp», участник снова уточняет у Вас детали формата, количество раундов алгоритма и т.д. и goto этап 1
5) Если результат совпадает с «flagE.bmp», то начинается собственно криптоанализ.
6) Участник получает/не получает результат.
1) Участник повторяет Вашу и Nagase сотоварищи работу на OpenCL (Я готов повторить, если мозг за пять лет после написания курсовой на нем не высох окончательно)
2) Участник публикует исходники, если считает, что понял условия конкурса.
3) Вы компилируете исходники участника и шифруете исходное изображение «flag.bmp» Вашим исходным ключом.
4) Если результат не совпадает с «flagE.bmp», участник снова уточняет у Вас детали формата, количество раундов алгоритма и т.д. и goto этап 1
5) Если результат совпадает с «flagE.bmp», то начинается собственно криптоанализ.
6) Участник получает/не получает результат.
Хотелось бы уточнить некоторые пункты, а именно 1, 3 и 4.
1) У меня нет смысла уточнять количество итераций шифрования, т.к. я вам не должен говорить это, все что у вас есть это эти 3 файла.
2) Вы можете сделать проект на основе OpenCL файла, я могу взять ваш проект, зашифровать вашим проектом файл и дешифровать какой-либо файл, указание полного совпадение с flagE покажет вам то, какая размерность у блока, а этого я вам сообщать тоже не должен.
Таким образом выполнение ваших пунктов говорит о том, что у вас появляется дополнительная информация для взлома алгоритма, которой при КРСА для данного алгоритма у вас быть не должно, поэтому я не могу согласиться на ваши условия и надеюсь что вы все-таки понимаете почему.
1) У меня нет смысла уточнять количество итераций шифрования, т.к. я вам не должен говорить это, все что у вас есть это эти 3 файла.
2) Вы можете сделать проект на основе OpenCL файла, я могу взять ваш проект, зашифровать вашим проектом файл и дешифровать какой-либо файл, указание полного совпадение с flagE покажет вам то, какая размерность у блока, а этого я вам сообщать тоже не должен.
Таким образом выполнение ваших пунктов говорит о том, что у вас появляется дополнительная информация для взлома алгоритма, которой при КРСА для данного алгоритма у вас быть не должно, поэтому я не могу согласиться на ваши условия и надеюсь что вы все-таки понимаете почему.
Я так понимаю вы решили на этом закончить, неужели алгоритм не настолько тривиален как вы сказали? или метод key schedule не слаб?
Простите, не мог знать, что Вы ждали скорого ответа. Поясню, о чем я:
1) Атаковать just for fun неизвестную реализацию криптосистемы в одиночку никто в здравом уме не согласится. В реальности такие задачи решаются многими людьми. Или криптосистема открыта, или никто за нее не возьмется просто так.
2) Принцип Керкгоффса уже полтораста лет как гласит, что стойкость криптосистемы не должна основываться на ее неизвестности. Вы можете добавить к ключу еще стопятьсот параметров, чья энтропия помноженная на длину превышает размер исходного «ключа». Вот только и они сами тогда тоже будут ключом. А криптосистема должна быть практически применимой. Значит, ключ должен легко генерироваться, распространяться и т.д.
3) Если бы Вы действительно хотели бы доказать хотя бы себе сначала стойкость Вашей криптосистемы, Вы бы УЖЕ проделали описанные шаги до написания данного поста. И этой дискуссии сейчас бы не было. Потому что так положено — в процессе создания криптосистемы параллельно проводится доказательство ее эфективности/применимости, проводится ее криптоанализ и приводятся практические оценки ее стойкости и эффективности атак. Так делают все, чьи криптосистемы доживают до массового внедрения.
4) Иначе, нет ни единой причины полагать, что на исходную картинку не наложена гамма из пережатого стомегабайтного скана Вашего кота, севшего на сканер. Чтобы никто и никогда конкурс не выиграл, даже NSA.
1) Атаковать just for fun неизвестную реализацию криптосистемы в одиночку никто в здравом уме не согласится. В реальности такие задачи решаются многими людьми. Или криптосистема открыта, или никто за нее не возьмется просто так.
2) Принцип Керкгоффса уже полтораста лет как гласит, что стойкость криптосистемы не должна основываться на ее неизвестности. Вы можете добавить к ключу еще стопятьсот параметров, чья энтропия помноженная на длину превышает размер исходного «ключа». Вот только и они сами тогда тоже будут ключом. А криптосистема должна быть практически применимой. Значит, ключ должен легко генерироваться, распространяться и т.д.
3) Если бы Вы действительно хотели бы доказать хотя бы себе сначала стойкость Вашей криптосистемы, Вы бы УЖЕ проделали описанные шаги до написания данного поста. И этой дискуссии сейчас бы не было. Потому что так положено — в процессе создания криптосистемы параллельно проводится доказательство ее эфективности/применимости, проводится ее криптоанализ и приводятся практические оценки ее стойкости и эффективности атак. Так делают все, чьи криптосистемы доживают до массового внедрения.
4) Иначе, нет ни единой причины полагать, что на исходную картинку не наложена гамма из пережатого стомегабайтного скана Вашего кота, севшего на сканер. Чтобы никто и никогда конкурс не выиграл, даже NSA.
1) В чем же именно неизвестность реализации? В том что есть варианты размеров блоков и все возможные варианты вам известны, вы это называете неизвестностью? Или то, что я согласился проверить ваш проект на основе этого OpenCL файла и показать вам что он работает, в этом неизвестность?
2) Ключ легко генерируется, судя по вашему первому сообщению, вы прочитали все статьи автора и наверно других авторов и должны прекрасно понимать каков ключ, если нет, то получается что ваше первое сообщение не соответствует действительности.
3) Я не хочу доказывать стойкость криптосистемы, это доказывал автор, мне это не нужно, это не мой алгоритм, сколько еще раз мне написать чтобы вы это поняли? Автором, насколько я понимаю, проводились эти этапы, описанные в 3 пункте, по данным вопросам обращайтесь к нему.
4) У вас замечательные шутки, но не меняя тему там ничего не наложено, обычное умножение на матрицу.
Что я понял из ваших и своих сообщений.
1) Вы сообщили что алгоритм очень просто взломать, т.к. здесь обычное умножение на матрицу.
2) Я предложил вам доказать это
3) Вы мне сообщаете кучу условий, после реализации которых вы согласны это делать, не совсем адекватных условий (см. пункты выше, устал повторяться)
Я делаю вывод что вы не можете взломать алгоритм, про который вы сказали что в нем можно тривиально найти ключ, к чему вы вообще написали ваше первое сообщение?
2) Ключ легко генерируется, судя по вашему первому сообщению, вы прочитали все статьи автора и наверно других авторов и должны прекрасно понимать каков ключ, если нет, то получается что ваше первое сообщение не соответствует действительности.
3) Я не хочу доказывать стойкость криптосистемы, это доказывал автор, мне это не нужно, это не мой алгоритм, сколько еще раз мне написать чтобы вы это поняли? Автором, насколько я понимаю, проводились эти этапы, описанные в 3 пункте, по данным вопросам обращайтесь к нему.
4) У вас замечательные шутки, но не меняя тему там ничего не наложено, обычное умножение на матрицу.
Что я понял из ваших и своих сообщений.
1) Вы сообщили что алгоритм очень просто взломать, т.к. здесь обычное умножение на матрицу.
2) Я предложил вам доказать это
3) Вы мне сообщаете кучу условий, после реализации которых вы согласны это делать, не совсем адекватных условий (см. пункты выше, устал повторяться)
Я делаю вывод что вы не можете взломать алгоритм, про который вы сказали что в нем можно тривиально найти ключ, к чему вы вообще написали ваше первое сообщение?
Здесь так много недопонимания, что в два слова не расплести.
1) На Ваших условиях едва ли кто будет пытаться сломать Вашу реализацию данного алгоритма. Т.к. в основе исходной криптосистемы лежит довольно странный, мягко говоря, подход. И у авторов после первого раунда в работе шифртекст от картинки почти не изменился. И синус всего лишь превратился в слегка зашумленный синус. У применяющихся на практике криптосистем число раундов только снижает криптостойкость на порядки, но не полностью, не позволяет извлекать полезную информацию из шифртекста невооруженным глазом!
2) Нельзя оправдывать стойкость криптосистем конкурсами. Вообще. Никогда. www.schneier.com/crypto-gram-9812.html#contests
1) На Ваших условиях едва ли кто будет пытаться сломать Вашу реализацию данного алгоритма. Т.к. в основе исходной криптосистемы лежит довольно странный, мягко говоря, подход. И у авторов после первого раунда в работе шифртекст от картинки почти не изменился. И синус всего лишь превратился в слегка зашумленный синус. У применяющихся на практике криптосистем число раундов только снижает криптостойкость на порядки, но не полностью, не позволяет извлекать полезную информацию из шифртекста невооруженным глазом!
2) Нельзя оправдывать стойкость криптосистем конкурсами. Вообще. Никогда. www.schneier.com/crypto-gram-9812.html#contests
1) Действительно, здесь много непонимания т.к. я не вижу чем мои условия являются сверхъестественными? Неужели умножение вектора на матрицу является чем-то чрезвычайно сложным для понимания? Неужели нет статей подробно описывающих алгоритм? Неужели нет примера кода здесь?
2) Конкурсы? Это не конкурс определения криптостойкости, поищите статьи автора и других где они описывают криптостойкость этого алгоритма, я прошу вас лишь подтвердить ваши слова из вашего первого сообщения, если вы считаете что все довольно просто, то почему так сложно это вам доказать или вы так и дальше будете продолжать разговор о том что алгоритм некриптостойкий, «тривиальный», в таком случае это не имеет никакого смысла
Буду благодарен если вы поймете, что указав на что-то (в данном случае на слабость алгоритма) будьте добры это доказать, я не говорю что вы не правы, может быть автор алгоритма и статей по нему не прав, а вы знаете это лучше, но без ваших доказательств все ваши сообщения не имеют никакого смысла.
2) Конкурсы? Это не конкурс определения криптостойкости, поищите статьи автора и других где они описывают криптостойкость этого алгоритма, я прошу вас лишь подтвердить ваши слова из вашего первого сообщения, если вы считаете что все довольно просто, то почему так сложно это вам доказать или вы так и дальше будете продолжать разговор о том что алгоритм некриптостойкий, «тривиальный», в таком случае это не имеет никакого смысла
Буду благодарен если вы поймете, что указав на что-то (в данном случае на слабость алгоритма) будьте добры это доказать, я не говорю что вы не правы, может быть автор алгоритма и статей по нему не прав, а вы знаете это лучше, но без ваших доказательств все ваши сообщения не имеют никакого смысла.
Я готов реализовать схему из статьи «New Encryption System Architecture for Image Transmission» и затем провести на нее атаку, с публикацией всех исходников, тестовых ключей, шифртекстов под тестовыми ключами и т.д.
Я не вижу смысла при обсуждении данной темы скрывать хоть что-то, кроме конкурсного ключа.
Иначе любые слова (а тем более попытки решения) будут пустой тратой времени.
Я не вижу смысла при обсуждении данной темы скрывать хоть что-то, кроме конкурсного ключа.
Иначе любые слова (а тем более попытки решения) будут пустой тратой времени.
В таком случае прошу вас, реализовывайте и проводите атаку, мне будет очень интересно прочитать ваши результаты.
Я повторюсь уже в который раз, но все же повторюсь еще раз, я не скрываю информацию, я лишь говорю о том, что в данном случае рассматривается KPCA для данного алгоритма, а это говорит о том, что у вас в наличии должна иметься только информация такого вида как зашифрованный файл и этот же расшифрованный файл, более ничего. (и например еще один зашифрованный файл, чтобы вы могли его дешифровать)
Если вы рассматриваете не KPCA, а что-то ваше собственное, где вам выдадут информацию о размере блока и о количестве итераций шифрования, то это совсем другая ситуация, можете сразу и попросить у тех кто вам это все даст и сам ключ шифрования, тогда никаких атак вообще производить не надо, всё уже готовое, останется только использовать и всё.
Я повторюсь уже в который раз, но все же повторюсь еще раз, я не скрываю информацию, я лишь говорю о том, что в данном случае рассматривается KPCA для данного алгоритма, а это говорит о том, что у вас в наличии должна иметься только информация такого вида как зашифрованный файл и этот же расшифрованный файл, более ничего. (и например еще один зашифрованный файл, чтобы вы могли его дешифровать)
Если вы рассматриваете не KPCA, а что-то ваше собственное, где вам выдадут информацию о размере блока и о количестве итераций шифрования, то это совсем другая ситуация, можете сразу и попросить у тех кто вам это все даст и сам ключ шифрования, тогда никаких атак вообще производить не надо, всё уже готовое, останется только использовать и всё.
Sign up to leave a comment.
Quaternion Encryption Scheme (QES) на FPGA, XeonPhi, GPU