С - Смекалочка

[michaelkoloboff]

Когда ты не знаешь что такое XOR, но слышал, что такая функция есть для биг-инт:
1. преобразуешь массив байт в строку;
2. преобразуешь строку в биг-инт;
3-4. то же самое со вторым массивом;
5. применяешь функцию для ксорки к этим двум биг-инт;
6. результат преобразуешь в строку;
7. строку преобразуешь в массив;
8. Profit!

Comments

[vit_r]

Китайцы?

[michaelkoloboff]

Ты знал!

[vit_r]

Я видел!

[sobriquet9]

Криптографические библиотеки на C++ зачастую передают туда-сюда 256- и 512-битные числа в виде std::string, по 8 бит в символе. Выглядит слегка по-деревенски, зато не надо зависеть от какой-нибудь библиотеки, реализующий весь BigInt.

[michaelkoloboff]

"Формально правильно, а по сути издевательство" В.И.Ленин
Массивы можно перексорить напрямую без ничего. Без преобразований "массив-строка-бигинт-сторонняя либа-строка-массив".

[wererat]

Так это смотря на каком процессоре. Например, во многих RISC чтобы "перексорить напрямую без ничего" надо же быть уверенным, что твои массивы выровняны по 32-бит в памяти, и что размер их кратен четырём байтам. Так что твой китаец, возможно, не так уж и неправ...

[michaelkoloboff]

А строки не должны быть равной длины? Перевод в строки и потом в биг-инт не избавляет от необходимости проверок.

[wererat]

А у тебя ещё и массивы произвольного, возможно неравного размера? Как же ты хотел их "ксорить напрямую" тогда?

[michaelkoloboff]

У меня два одинаковых массива. Не знаю зачем ты начал искать сложности.

[wererat]

Я начал?

А строки не должны быть равной длины? Перевод в строки и потом в биг-инт не избавляет от необходимости проверок.

[sobriquet9]

Это если ксорить 32-битными словами. А если ксорить по одному байту за раз, то не надо ничего выравнивать.

[wererat]

Так это смотря на каком процессоре.

Вам очень непросто будет найти RISC ядро с байтовыми операциями ,) а большинство современных контроллеров (об одном из которых Майк и говорит, насколько я понело) относятся как раз к этой категории...

[michaelkoloboff]

Я говорю о том где перексорить побайтово слишком просто для некоторых :)
Поста бы не было, если бы ксорка не была примитивной операцией, которую можно применить прямо на массиве.

[wererat]

Для тебя просто, а человек, быть может, уже обжигался на чём-нить типа ARM Cortex, вот и делает пословно... а ты такой сразу: фу, кетайса!

[michaelkoloboff]

У нас тут смешанные чувства. Во-первых, это красиво. Но вопрос нахуя остается.

[wererat]

Ну, его так научили, естественно. Почему его так научили, не знаю, но есть вот подозрение. Например, если написать типа (char*)a[i] = (char*)b[i]^(char*)c[i] для чего-нибудь типа Am29k, то компилятор выдаст такой чудовищный фарш, что лучше уж эксплицитно преобразовать в 32 бита, наверное.

[sobriquet9]

Любой язык программирования выше ассемблера позволяет мне обращаться к любому байту из массива индивидуально и не думать о том, как там что выравнено в памяти. Сколько дополнительных операций для этого вставит компилятор для данного процессора мне всё равно. Я могу даже не знать, для какого процессора пишу.

Если не всё равно и производительность важна, тогда придётся думать. Но что-то я не могу себе представить приложение, которое упирается в скорость ксора.

[wererat]

Телеком.

[sobriquet9]

В каком месте? Никто ж не делает шифрование ксором. Есть стандартные алгоритмы шифрования, реализованные в железе или библиотекой вроде NaCl или Crypto++, написанной и оптимизированной под конкретное железо.

[wererat]

Гм. Интересно, зачем бы тогда в nacl функция crypto_stream_xor()? Воообще-то, все делают шифрование именно ксором, без ксора можно сделать разве что режим ECB (в блочных шифрах), а он самый неустойчивый из возможных.

Потом мало ли, для обфускации, например, можно применить. Майк вот зачем-то же его делает? ,)

И кстати, "оптимизирована под конкретное железо" это наверное libsodium, а не nacl? Или я отстал от жизни? Раньше "солянка" была оптимизирована только под x86.

[sobriquet9]

А откуда вы возьмете параметр k (с чем ксорить)? Его обычно генерируют блочным шифром вроде AES или Salsa20. Большая часть времени уходит именно на блочный шифр, а не на ксор.

Могут быть и другие применения, например, для коррекции ошибок. Но и там вряд ли можно упереться в скорость ксора, наверняка есть намного более долгие операции.

[wererat]

That's true, но из того, что есть более затратные операции, не следует же, что надо (или хотя бы допустимо) замедлять менее затратные? Латенси такая штука, тут миллисекунда, там миллисекунда, а задержка всё накапливается..

[sobriquet9]

Речь не про замедлять специально. Речь про то, на ускорение чего тратить время дорогостоящих профессионалов. Если можно быстро и дёшево сделать что-то, работающее миллисекунду или дорого и медленно сделать что-то, работающее 100 микросекунд, то вряд ли есть смысл связываться. Человек не может отличить миллисекунды от микросекунд.

[wererat]

Да, но задержки (например, в канале) накапливаются. А впрочем, ладно, делайте как хотите ,))

[michaelkoloboff]

Понимаешь, мы живем в такое чудесное время, что три уровня шифрования требуется чтобы зажечь лампочку (двухядерным процом с М4). А людям почему-то не нравится задержка между щелкнули включателем и появлением света.

[wererat]

Фырк! =)

[michaelkoloboff]

Я не шучу. Каждое сообщение "вкл(выкл) лампочку" шифруется 3 раза: само сообщение, уровень приложения, уровень сети. По факту бо'льшую часть времени нода занимается (рас)шифрованием, а не полезной работой.

[wererat]

Да я, вообще-то, сразу поверил. Ничего невероятного по современным меркам в таком способе включения лампочек нет...

Слушай, а заради совместимости с чем именно тебе такие наказания?

[michaelkoloboff]

Лезешь в кузов - придется быть груздем. На эти лампочки есть стандарт, надо соответствовать. Нам как раз непонятно другое - почему они там RSA не с(до)делали? Ибо примерно 98% от него они реализовали, осталась сущая мелочь.

[wererat]

Где "там"?

А вообще-то, разве нельзя взять OpenSSL, и не мучиться с кетайским погромизмом?

[michaelkoloboff]

Ну как сказать, если простой ксор пишется сложным способом, то как пишутся сложные вещи? Думаю как-то так мы теряем телефонию: это охуенно здорово, что мы нынче можем бесплатно позвонить за море, но с качеством связи до сих пор проблемы (даже кажется, что несколько лет назад было лучше), не смотря на гигигерцы многоядерных процов и гигабиты оптоволокна, опутавшего планету.

[sobriquet9]

Я думаю что как раз сложные вещи пишутся лучше, потому что их пишут нормальные программисты, а не копипастеры со StackOverflow/Copilot/ChatGPT. Если через колено написать что-нибудь критически важное, оно ж не взлетит.

Телефонию удерживает обратная совместимость. Отсюда и оцифровка на восьми килогерцах и восьми битах. FaceTime, WhatsApp и даже Signal передают уже не только звук нормального качества, но и видео тоже.

[anonim_legion]

Когда я вместо домашнего телефона начал беседовать по мобильному, в 2005 году где-то, меня поразило плохое качество звука.

[sobriquet9]

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