Комментарии 13
«Это увеличивает его переносимость». Чем это увеличивает переносимость? Что вы имели этим ввиду? Может я не так понял.
По мне так натив куда переносимее. Crypto++ вон хоть под iOs компиль хоть под что.
По мне так натив куда переносимее. Crypto++ вон хоть под iOs компиль хоть под что.
НЛО прилетело и опубликовало эту надпись здесь
Не соглашусь, что нативный код более переносимый. java-приложение одинаково работает везде, где есть jre. А для того, чтобы пересобрать нативное приложение под другую платформу порой приходится затратить много усилий.
… чему, в каком-то смысле, эта статья доказательство
Ну если в таком ключе говорить о переносимости, то можно и согласиться.
Я же имел ввиду переносимость в более широком смысле, в смысле о самой возможности переноса на другие платформы… а тут если нет этого jre, то ты хоть тресни — не будет работать. scummvm.org/ смеется над переносимостью jar.
А насчет много усилий… Приведенное в этой статье — много усилий? Эти усилия настолько мелочны в сравнении с профитом от этих усилий, что ими можно и пренебречь.
Я же имел ввиду переносимость в более широком смысле, в смысле о самой возможности переноса на другие платформы… а тут если нет этого jre, то ты хоть тресни — не будет работать. scummvm.org/ смеется над переносимостью jar.
А насчет много усилий… Приведенное в этой статье — много усилий? Эти усилия настолько мелочны в сравнении с профитом от этих усилий, что ими можно и пренебречь.
Вот мне интересно, у вас действительно шифрование узкое место…
Потому что, сейчас выглядит, как будто Вы сделали ненужную работу, усложнили дальнейшую разроботку и поддержку и получили всего навсего 2 ускорение для арм-процесовров
Такое впичетление что нужно было просто показать где на интел процесорах можно получитьнебольшое большое приемущество по сравнению с соперниками
Потому что, сейчас выглядит, как будто Вы сделали ненужную работу, усложнили дальнейшую разроботку и поддержку и получили всего навсего 2 ускорение для арм-процесовров
Такое впичетление что нужно было просто показать где на интел процесорах можно получить
В первую очередь я хотел посмотреть, насколько сложно портирование библиотеки под Android и сколько можно получить дополнительного быстродействия при этом. Полученное двукратное ускорение в некоторых случаях будет серьезным доводом для того, чтобы усложнить разработку.
Что там Кнут говорил про преждевременную оптимизацию? :) Редко в каких приложениях криптография будет бутылочным горлышком. Особенно под мобильные платформы.
Кстати, тестировали вы AES, который и так очень быстр, к тому же создавался с расчем того, что будет выполняться на generic-процессорах.
А проверьте реализацию RSA или эллиптических кривых.
Кстати, тестировали вы AES, который и так очень быстр, к тому же создавался с расчем того, что будет выполняться на generic-процессорах.
А проверьте реализацию RSA или эллиптических кривых.
К примеру для vpn и ssl соединений, или какого либо крипто контейнера шифрование необходимо. Дело ещё и в эффективности — чем производительнее код — тем меньше будет потрачено энергии, и тем больше времени останется на выполнение других задач, так что в условиях достаточно жёсткого ограничения в производительности железа, и запаса энергии — 2х кратный выигрыш это очень даже хорошо. Отработка же механизма портирования достаточно сложной библиотеки полезна сама по себе.
Честно говоря не видел ни одного Android девайса, где VPN или криптоконтейнер реализован на Java. Так же как и SSL, впрочем.
SSL обычно реализуется силами openssl где есть эфективные реализации всех криптоалгоримтов.
Криптоконтейнеры вообще делают на уровне ядра. Где опять же есть Kernel Crypto API и очень часто — поддержка аппаратной криптографии.
VPN же делается силами либо OpenVPN либо IPSec опять же на уровне ядра.
Так что остаётся только какая-то сильно прикладная app-specific криптография, типа проверки валидности лицензионных ключей…
SSL обычно реализуется силами openssl где есть эфективные реализации всех криптоалгоримтов.
Криптоконтейнеры вообще делают на уровне ядра. Где опять же есть Kernel Crypto API и очень часто — поддержка аппаратной криптографии.
VPN же делается силами либо OpenVPN либо IPSec опять же на уровне ядра.
Так что остаётся только какая-то сильно прикладная app-specific криптография, типа проверки валидности лицензионных ключей…
У меня вот узкое место. Вполне реальная ситуация — получения доступа к зашифрованной базе. Чтобы всё сделать как надо, применяем pbkdf2 — раундов под 10000 как у iphone 5. генерация ключа шифрования и проверки почти две секунды. То есть пользователю надо ждать две секунды пока что-то там посчитается. Разница в 3,5 раза сделает работу приложения гораздо более приятной. Только в моём случае не андройд, где возможен нативный код, а сильверлайт и wp7 где такой возможности нет. по тестам на большом компьютере проигрыш как раз 3,5 раза. Если предположить, что пропорции сохранятся как в этом посте, то переписывание sha2 в нейтив на wp7 привело бы к ещё большей выгоде.
Ну pbkdf2 как раз для того и придумывали, что бы ключи вычислялись медленно :)
У меня есть пара вопросов:
— зачем 10 000 раундов? Если верить википедии, то 4096 рауднов SHA1 приводят к тому, что можно сгенерить всего 70 ключей в секунду на Intel Core2. Мне кажется, этого более чем достаточно.
— Честно говоря не работал с силверлайт на wp7, но помню что в большом .NET Framework есть очень хороший и удобный CryptoAPI с бекендами в нативном коде. Для WP7 такого не сущесвует?
У меня есть пара вопросов:
— зачем 10 000 раундов? Если верить википедии, то 4096 рауднов SHA1 приводят к тому, что можно сгенерить всего 70 ключей в секунду на Intel Core2. Мне кажется, этого более чем достаточно.
— Честно говоря не работал с силверлайт на wp7, но помню что в большом .NET Framework есть очень хороший и удобный CryptoAPI с бекендами в нативном коде. Для WP7 такого не сущесвует?
— затем что на iphone5 10000 раундов и ниже уже не очень хорошо. В RIM тоже видимо думали — зачем много и поставили вообще 1 ;) Elcomsoft их удачно брутфорсили по этому поводу. Я не в курсе о реализации про которую говорится в википедии, но у меня с sha256 на Core 2 quad при 10000 раундов те же 80 ключей в секунду (все вектора проходят проверку) и это без каких либо особых оптимизиций. А это всё же обычный десктопный процессор, причём старый.
— Всё было бы вполне прилично, если бы было так. Разница на PC между c и c# — 3,5 раза (в один поток). И профайлер VS показывает 95% времени в TransformBlock — Так что сомнительно что CryptoAPI в .NET нативный хоть в каком-то виде.
Конечно можно забить и уменьшить раунды до 4000 или даже 2000, но лишние ресурсы всё равно будут тратиться на вычисления и вообще компромиссы в безопасности выходят зачастую боком.
— Всё было бы вполне прилично, если бы было так. Разница на PC между c и c# — 3,5 раза (в один поток). И профайлер VS показывает 95% времени в TransformBlock — Так что сомнительно что CryptoAPI в .NET нативный хоть в каком-то виде.
Конечно можно забить и уменьшить раунды до 4000 или даже 2000, но лишние ресурсы всё равно будут тратиться на вычисления и вообще компромиссы в безопасности выходят зачастую боком.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ускорение криптоопераций или опыт портирования под Android