Сложно поспорить с этим утверждением, но я еще в исходном сообщении хотел написать, что "Предлагаю обсуждать не целесообразность решения, а теорию" (потому что у самого есть вопросы к этому решению, но интересна именно теория). То есть, подобные запросы в принципе не будут работать за тысячные доли секунды?
Александр Карабанов: А ничем не лучше. Скорее, хуже, хотя в плане производительности вряд ли удастся выявить какую-либо разницу. Необходимость вызвана исключительно задумкой реализации, в которой необходимо выполнять шифрование как в php, так и через консоль, при этом получая одинаковый результат. На самом деле, уже найдено несколько альтернативных решений, но хочется именно данный вариант, потому что считаю его самым оптимальным, да и сил уже много потрачено + хочется матчасть изучить в деталях, а то документация не особо помогла.
Правда, я не разобрался со случаем, когда длина шифруемой строки кратна 8 символам, но даже если бы и разобрался, это все равно не решило бы моей проблемы.
PHP гарантированно использует ту же самую библиотеку mcrypt, которая вызывается из консоли, но результаты по-прежнему у меня не совпадают - значит вопрос только в том, какие параметры передаются через порт php в саму либу.
То, что openssl и mcrypt выдают разные результаты - этому я объяснение нашел:
After some research, it appears that MCrypt pads the input with zero bytes, while OpenSSL uses PKCS#7 padding, which explains the non-identical output.
Но я совершенно не могу найти объяснения тому, что одна и та же утилита через разные порты выдает разные результаты. Ведь php всего лишь синтаксическая надстройка над тем же самым libmcrypt, который выдает результат в консоли.
Я нашел еще одну подсказку, но не смог применить ее для получения положительного результата:
We managed to get the same results by removing the manual padding on the PHP side
В openssl есть опция -nopad, которая, возможно, имелась в виду в цитате выше, но в mcrypt я не вижу, как можно это настроить.
Я сакцентировал внимание на этом моменте, потому что сам думал об этом. В любом случае, это не решение описанной проблемы. Я лишь сомневался на тему, что без переноса строки приходится дважды нажимать Ctrl+D. В общем, это нюанс, который я упомянул из каких-то сомнений, которые я не могу мотивировать, но на самом деле испробована была масса вариантов, как с переносами строки, так и без, и еще куча черт знает каких.
Думаю, решением этой задачи можно считать указание на ошибку в описанном выше решении - все что на уровне предположений, с большой долей вероятности мной уже испробовано. К тому же, уверен, описанный сценарий воспроизведется на любом окружении с очень большой вероятностью.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
