|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
maytonЦитата авторАрхивирование с бесконечным коэффициентом сжатия невозможно в общем случае, но в частных - легко, в том числе и в случае корней и иррациональных чисел. Поэтому последовательность знаков в иррациональном числе имеет смысл изучать. И мой камент был к ней. Тогда я не понял, какова связь. Можно записать число 11? Можно взять корень? Можно получить бесконечную последовательность? Коэффициент сжатия 2 к бесконечности не очевиден? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.03.2019, 17:31 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
BarloneЕсть более быстрые способы генерации случайной последовательности. Поделитесь? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.03.2019, 17:32 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
maytonМы берем зашифрованное сообщение и применяем к нему известный (уже) генератор до тех пор пока регулярные структуры в нем не проявятся. То есть решаем перебором. Но ведь чисел, из которых можно взять корень, очень много. Если брать числа хотя бы в районе от 2 64 и до 2 64 +2 64 , то перебор займёт уже очень приличное время. Но 64 - это далеко не самое маленькое число, которое я могу придумать. Да, и в каждом сеансе я меняю сеансовый ключ, то есть беру пару новых чисел. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.03.2019, 17:35 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
Dima TРазмышлял тут про скорость аппаратного AES Пусть грубо 2ГБ в секунду. Память может отдавать данные много быстрее, то есть имеем ожидание из-за вычислений. 256-битный xor выполняется, примерно за пару тактов. Ну пусть будет 3 для гарантии, хотя весьма вероятно, что за один такт. Пусть система о 3 гигагерцах. Тогда имеем 32 байта за наносекунду. Пусть xor выполняется два раза (для двух коней), тогда имеем 16 байт за наносекунду или 16ГБ в секунду. При этом второе (третье, четвёртое, ...) ядро вычисляет две последовательности. Для вычисления память не нужна (почти). Вычисление итеративное, из предыдущих данных получаются новые. Вычисление довольно простое. Если два-три ядра успеют вычислять со скоростью генерации 16 ГБ в секунду, то получаем теоретический предел 16 ГБ. Если не успеют - предел меньше. Но по сравнению с 2 ГБ/с есть запас. Делим 16 на 4 загружаемых ядра - всё равно будет двойной запас. И работает без требования о наличии железных команд, считающих AES. Не в плане кого-то убеждать, но альтернатива интересная. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.03.2019, 17:47 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
alex55555Да, и в каждом сеансе я меняю сеансовый ключ, то есть беру пару новых чисел. Подумал, понял, что не знаю, можно или нет статистически обнаружить отклонение от известного распределения при наличии конкретного шаблона в сообщении. Поэтому из-за незнания придётся усложнить алгоритм перепутыванием байт в сообщении по закону, который меняется на каждом сеансе. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.03.2019, 17:51 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
Dima TВсе хорошо, но что делать там где проц не поддерживает AES ? Это не только ARMов касается. Интел поддержку AES включил только в 2008 и то не на всех процах. Под рукой нашлись два ноута где нет AES, процы: i3-2310M и AMD A8-3510MX. PS В вики немного врут, на i3-7100U есть AES. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.03.2019, 17:56 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
Dima TmaytonНе собралось. Поправил, проверяй. Спасибо. Вечером повторю. Кстати на днях ко мне заедет 6-ядерный Ryzen. Можно будет погонять на нем карточный трассировщик луча. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.03.2019, 18:22 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
alex55555maytonМы берем зашифрованное сообщение и применяем к нему известный (уже) генератор до тех пор пока регулярные структуры в нем не проявятся. То есть решаем перебором. Но ведь чисел, из которых можно взять корень, очень много. Если брать числа хотя бы в районе от 2 64 и до 2 64 +2 64 , то перебор займёт уже очень приличное время. Но 64 - это далеко не самое маленькое число, которое я могу придумать. Да, и в каждом сеансе я меняю сеансовый ключ, то есть беру пару новых чисел. В чем заключается твоя идея? Вместо ключа длиной 256 бит который генерируется обычно секюрными генераторами, или хешом от парольной фразы, ты предлагаешь заведомо узкую по области значений и сурьективную функцию которая пространство ключей сужает от 256 до 64 бит. Зачем это? Что мы на этом экономим? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.03.2019, 20:19 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
Мысли вслух, может кто что подскажет: там где AES не поддерживается, то перейти на cbc xor, но тут две проблемы: 1. Определить что AES аппаратно не поддерживается, не гуглил, но это вроде как можно определить что поддеживает проц перед использованием. 2. Переключиться на xor если одна из сторон не может использовать аппаратный AES. Тут выравнивание по 16 байт заставляет шифровать все 1472 байта (максимум для UDP). В конец пакета добавлено два байта 0xA55A, по которым можно проверить корректность расшифровки, поэтому видится только что получатель на первый пакет либо сообщает отправителю что не в состоянии расшифровать (нет поддержки AES), либо не расшифровав с AES расшифровывает с XOR. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.03.2019, 20:39 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
Dima TМысли вслух, может кто что подскажет: там где AES не поддерживается, то перейти на cbc xor, но тут две проблемы: 1. Определить что AES аппаратно не поддерживается, не гуглил, но это вроде как можно определить что поддеживает проц перед использованием. 2. Переключиться на xor если одна из сторон не может использовать аппаратный AES. Тут выравнивание по 16 байт заставляет шифровать все 1472 байта (максимум для UDP). В конец пакета добавлено два байта 0xA55A, по которым можно проверить корректность расшифровки, поэтому видится только что получатель на первый пакет либо сообщает отправителю что не в состоянии расшифровать (нет поддержки AES), либо не расшифровав с AES расшифровывает с XOR. Технически. Тебе проще собирать и поддерживать 2 бинарника. - с аппаратной поддержкой AES для модных процессоров. - с программной эмуляцией того-же AES для старых жлобских Пенитиумов и Ардуино. Выбор сделать сразу на фазе инсталляции. Усложнять протокол добавлением выбора - ябы не стал. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.03.2019, 20:47 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
maytonDima TМысли вслух, может кто что подскажет: там где AES не поддерживается, то перейти на cbc xor, но тут две проблемы: 1. Определить что AES аппаратно не поддерживается, не гуглил, но это вроде как можно определить что поддеживает проц перед использованием. 2. Переключиться на xor если одна из сторон не может использовать аппаратный AES. Тут выравнивание по 16 байт заставляет шифровать все 1472 байта (максимум для UDP). В конец пакета добавлено два байта 0xA55A, по которым можно проверить корректность расшифровки, поэтому видится только что получатель на первый пакет либо сообщает отправителю что не в состоянии расшифровать (нет поддержки AES), либо не расшифровав с AES расшифровывает с XOR. Технически. Тебе проще собирать и поддерживать 2 бинарника. - с аппаратной поддержкой AES для модных процессоров. - с программной эмуляцией того-же AES для старых жлобских Пенитиумов и Ардуино. Выбор сделать сразу на фазе инсталляции. Усложнять протокол добавлением выбора - ябы не стал. Два бинарника не вариант, я не знаю где он будет запущен. Исходим из того что где-то запустили отправителя, где-то получателя, и они должны найти общий язык общения. Да, вариант программной реализации AES я умолчал, погуглю тоже, но и так понятно что это будет тормоз на слабом железе. Я за скорость, и ради скорости готов пожертвовать криптостойкостью. Как вариант можно предусмотреть сборку бинарника не поддерживающего слабое xor шифрование. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.03.2019, 21:01 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
Вот тут пишут про детектор команд AES new instructions: https://stackoverflow.com/questions/38798818/within-my-c-program-is-there-a-way-to-check-if-the-cpu-has-aes-ni Можно в рантайме проверять. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.03.2019, 21:06 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
maytonЗачем это? Что мы на этом экономим? Получаем скорость. Если AES реализовали в железе, то уж вычисление "длинного" корня там и подавно легко добавить, тогда скорость будет в разы больше. При этом ключ будет равен длине пакета. А число, из которого берётся корень, есть лишь способ сжатия информации о ключе. В начале сеанса шлём число, а не всю последовательность для шифрования. Число может быть маленьким, в разы меньше 256 бит, ибо перебором и 64 бита будут месяцами на мега-кластере считать. Но это не готовое предложение, это из разряда "мысли вслух". Потому что полноценно обосновывать это всё мне времени жалко. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.03.2019, 21:50 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
alex55555maytonЗачем это? Что мы на этом экономим? Получаем скорость. Если AES реализовали в железе, то уж вычисление "длинного" корня там и подавно легко добавить, тогда скорость будет в разы больше. Почему ты вообще в тему втащил "корень" ? Как его считать? Методом Ньютона? Метод Ньютона потребует массы арифметики над длинным (нет не длинным а бесконечно растущим числом). И почему ты решил что твой метод дешевле чем просто генерация криптобезопасного случайного ключа? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.03.2019, 21:58 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
Dima T1. Определить что AES аппаратно не поддерживается, не гуглил, но это вроде как можно определить что поддеживает проц перед использованием. авторBefore an application attempts to use AESNI instructionsor PCLMULQDQ, the application should follow the steps illustrated in Section 11.6.2, “Checking for SSE/SSE2 Support.” Next, use the additional step provided below: Check that the processor supports AESNI (if CPUID.01H:ECX.AESNI[bit 25] = 1); check that the processor supports PCLMULQDQ (if CPUID.01H:ECX.PCLMULQDQ[bit 1] = 1). ... |
|||
:
Нравится:
Не нравится:
|
|||
29.03.2019, 22:00 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
maytonПочему ты вообще в тему втащил "корень" ? Потому что был вопрос про шифрование. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.03.2019, 22:00 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
Dima TmaytonНе собралось. Поправил, проверяй. Хехе. На жлобском i3. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2019, 01:36 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
Только заметил, я с выводом немного накосячил: 1. не "4096 blocks of 500000 bytes each" а 500000 блоков по 4096 байт 2. В линуксе время вывелось в мкс, но скорость правильно посчиталась. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2019, 07:40 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
maytonХехе. На жлобском i3. Добавлю в общую таблицу Алгоритмi7-6700Ki7-3770Ki5-660mayton i3CBC xor1784 ms 1094 Mb/s2298 ms 849 Mb/s3429 ms 569 Mb/s3674 ms 531 Mb/sRC42689 ms 726 Mb/s4794 ms 407 Mb/s4897 ms 398 Mb/s10483 ms 186 Mb/sAES-128311 ms 6280 Mb/s648 ms 3014 Mb/s1102 ms 1772 Mb/s1072 ms 1820 Mb/sAES-128 + CBC1390 ms 1405 Mb/s2709 ms 720 Mb/s2488 ms 785 Mb/s5079 ms 384 Mb/s Странно что добавление CBC так сильно замедляет. На некоторых процах становится AES+CBC даже медленнее чем CBC xor. Хотя код не сильно меняется. Просто AES Код: plaintext 1. 2. 3. 4. 5. 6.
AES+CBC Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9.
Добавились две простые операции: XOR двух блоков и копирование блока. По сравнению с aes128_enc() это легкие операции, но скорость почему-то падает в разы. aes128_enc() Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
Асм мельком глянул, серьезной разницы в коде нет. Единственное подозрение что предсказатель в проце распараллеливает просто AES, предугадывая какой блок будет обсчитываться следующим, а после добавления CBC параллелить невозможно. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2019, 08:02 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
Добавил дешифрование AES с CBC Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Просто AES Код: plaintext 1. 2. 3. 4. 5. 6.
Затестил скорость и она такая же как у просто AES На всякий случай добавил тест скорости дешифрования AES, она не отличается от шифрования. ОперацияСкоростьAES.encrypt()6009 Mb/sAES.decrypt()5847 Mb/sAES.cbc_encrypt()1380 Mb/sAES.cbc_decrypt()5991 Mb/s PS Потестил в линуксе - тоже тормозит cbc_encrypt(). И в линуксе почему-то почти вдвое медленнее чем в виндовсе, хотя обе виртуалки на одном хосте. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2019, 10:06 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
Нашел классический исходник AES, т.е. без спец.команд проца. Затестил шифрование им. В 100 раз медленнее. На слабеньком i3-2310M скорость 21 Мб/сек. Думаю ARM вообще захлебнется. Вобщем не вариант использовать AES там где нет его поддержки процом. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2019, 12:55 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
Посмотри утилита OpenSSL имеет встроенные бенчмарки. Возможно есть симметричка попроще чем AES по мегафлопам но посильнее чем "Хорь". ... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2019, 14:11 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
Типа такого. AES против DES. Насколько я понимаю каждый тест ограничен в 3 секунды. И меряется количество блоков которые удалось успеть отработать с учотом вариативной длины блока. При этом насколько я понял это не блок шифрования а блок одной операции OpenSSL. Например внизу указана скорость DES для 16к блока. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29.
... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2019, 14:32 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
Dima TСтранно что добавление CBC так сильно замедляет. Ничего странного. ECB аппаратно распараллеливается, СВС этого не может в принципе. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2019, 14:38 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovDima TСтранно что добавление CBC так сильно замедляет. Ничего странного. ECB аппаратно распараллеливается, СВС этого не может в принципе. Что-то я затупил. Понял почему расшифровка не тормозит - она параллелится. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2019, 15:24 |
|
|
start [/forum/topic.php?fid=16&msg=39793805&tid=1339965]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
161ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
75ms |
get tp. blocked users: |
2ms |
others: | 246ms |
total: | 527ms |
0 / 0 |