Ну считай что оно будет работать раз в 10 медленнее. Mozilla пилит некий asm.js, который всего лишь в 2 раза медленнее сишного кода, но не знаю как оно с другими браузерами совместимо

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

нет. Т.е. возможна конечно, но занимает на порядки больше времени. Вот нагуглил: http://pajhome.org.uk/crypt/md5/ Это(или что-то похожее) я как-то пытался юзать, но - не взлетело. Проблема в том, что JS выполняется на стороне клиента, а там, кроме этого JS и нет ничего. А вот когда машину клиента юзаешь как числодробилку, клиенты почему-то ОЧЕНЬ недовольны. Да и зачем это нужно? Если клиент параноик - то он сам ставит нужный софт, которому доверяет, а не какой-то левый неподписанный скрипт юзает. А если клиент из 95%, то что мешает ему передавать данные в открытом виде?

10 раз медленно... Раза в 3 максимум хотелось бы.

Проблема в том, что JS выполняется на стороне клиента, а там, кроме этого JS и нет ничего.

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

Да и зачем это нужно?

Жс очень просто использовать — не надо ничего устанавливать, код кроссплатформенный.

Если клиент параноик - то он сам ставит нужный софт, которому доверяет, а не какой-то левый неподписанный скрипт юзает. А если клиент из 95%, то что мешает ему передавать данные в открытом виде?

Скрипт можно и подписать, и отследивать изменения, вроде были такие аддоны, которые проверяют подпись скриптов. При наличии коммьюнити вокруг проекта можно быть уверенным, что бэкдор обнаружат. Клиент может быть и из 95%, но к 5% прислушиваться и если будут крики, что мол несекьюрно и сливают данные, то не захочет пользоваться.

Еще, например, может быть требование цифровой подписи отправляемых данных. Сейчас это делается джава-апплетом, в котором криптография реализована, но это требует наличия джавы.

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

для firefox nightly текущего можно вполне реализовать, терминах asm.js, что это будет работать максимум в 2 раза медленнее чем референсный алгоритм на сишке. так же ты можешь его из сишки\спп скомпилить в js с помощью ecmascripten в asm.js гугли это

Ок, понял. А что насчет хрома и ие (оффтопик, но вдруг кто знает)?

https://crypto.stanford.edu/sjcl/

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

P.S. На нереальную приватность только рассчитывать не нужно, ибо JS будет отдаваться с твоего сервера и до клиента может дойти «модифицированным» методом «человек посредине», ну а будет этот модифицированный вариант отдавать копии данных куда-то еще или как-нибудь по другому влиять на сообщения - это зависит от «модификации».

Ты уверен, что у тебя ограничения будут определяться скоростью работы JavaScript, а не обменом с сервером по сети, например?

Если JS будет работать в 10-100 раз медленнее С, то уверен.

P.S. На нереальную приватность только рассчитывать не нужно, ибо JS будет отдаваться с твоего сервера и до клиента может дойти «модифицированным» методом «человек посредине», ну а будет этот модифицированный вариант отдавать копии данных куда-то еще или как-нибудь по другому влиять на сообщения - это зависит от «модификации».

Для этого придумали цифровые подписи.

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

а на практике - байт код это специализированный ЯП, который предназначен для вполне определённых задач. И ты наверное знаешь, каких именно. Вот именно эти задачи байткод выполняет почти также быстро, как и код на C. Часто даже и быстрее (код на C может быть хуже оптимизирован под конкретный CPU, если например это win-приложение «для всего», или даже бинарный пакет для Linux. У байткода таких ограничений может и не быть, и он лучше использует возможности CPU).

Проблема только в том, что криптоалгоритмы НЕ являются «типичными». Они вообще плохо ложатся на современные CPU (и это не баг, а фича, именно на этом они и держаться - расшифровать можно любой шифр, проблема только одна: ВРЕМЯ). Неудивительно, что совершенно не предназначенный для этого JS так плохо работает, ведь C код работает с железом почти напрямую, а значит его можно оптимизировать под железо.

Жс очень просто использовать — не надо ничего устанавливать, код кроссплатформенный.

в данном случае - это проблема. Вот посмотри на этот код (ссылка на источник выше)

    /* Encode output as utf-8 */
    if(x <= 0x7F)
      output += String.fromCharCode(x);
    else if(x <= 0x7FF)
      output += String.fromCharCode(0xC0 | ((x >>> 6 ) & 0x1F),
                                    0x80 | ( x         & 0x3F));
    else if(x <= 0xFFFF)
      output += String.fromCharCode(0xE0 | ((x >>> 12) & 0x0F),
                                    0x80 | ((x >>> 6 ) & 0x3F),
                                    0x80 | ( x         & 0x3F));
    else if(x <= 0x1FFFFF)
      output += String.fromCharCode(0xF0 | ((x >>> 18) & 0x07),
                                    0x80 | ((x >>> 12) & 0x3F),
                                    0x80 | ((x >>> 6 ) & 0x3F),
                                    0x80 | ( x         & 0x3F));

Скрипт можно и подписать, и отследивать изменения, вроде были такие аддоны, которые проверяют подпись скриптов. При наличии коммьюнити вокруг проекта можно быть уверенным, что бэкдор обнаружат. Клиент может быть и из 95%, но к 5% прислушиваться и если будут крики, что мол несекьюрно и сливают данные, то не захочет пользоваться.

можно, а зачем, если можно использовать C код? И да, C код будет проще, и кроме того, он УЖЕ есть. Отлаженный, проверенный, и устоявший против Over9000 атак. Твой новый код в принципе может сломать любой школьник, если он там ошибку заметит, которую ты проушанил.

Конкретно сейчас у меня немного сумасшедшая идея запилить клиента BitMessage на жс

в принципе - годно. Если ТОЛЬКО ТЕКСТОВЫЙ. Только текст вытянет _любой_ компьютер общего назначения не старше 5и лет. Но что-то большее - даже не думай. Может лет через 5..10, когда(и если) в JS появятся нужные «батарейки».

На нереальную приватность только рассчитывать не нужно, ибо JS будет отдаваться с твоего сервера и до клиента может дойти «модифицированным» методом «человек посредине»

в принципе, JS можно подписать. Я правда не знаю, умеет-ли браузер проверять такую подпись.

хром тоже можно, ие 10+ вполне вероятно. Mega.com сейчас так же сделан - ничего, работает, шифрует все на клиенте - вполне ок. При том там даже без особой оптимизации сделано

ты имеешь ввиду отдачу статики по https?)

ты имеешь ввиду отдачу статики по https

вроде-бы других путей нет. Или я чего-то не знаю…

ну этого и достаточно. браузеры на сайтах по https проверяют что бы все файлы были подписаны сертификатом. а еще лучше для этого юзать spdy, который как https только быстрее + мультиплексирование (много паралельных запросов как 1 будут работать)

ну этого и достаточно

ну пусть ТС пилит. Хотя лично мне непонятна ЦА этого чатика. Да и смысла тоже не вижу - на десктоп я-бы лучше клиент на C поставил, а на мобиле за 2тр ИМХО не взлетит даже текст.

в принципе, JS можно подписать.

Сделать это нужно таким образом, чтобы человек в середине, который подменит скрипт, не смог создать правильную подпись. Ты же в курсе, что скрипт с подписями весь будет тянутся по сети? Или подписи будут доставляться по другому каналу?

mega.com

Mega.com сейчас так же сделан

У них были проблемы: http://fail0verflow.com/blog/2013/megafail.html

расшифровать можно любой шифр, проблема только одна: ВРЕМЯ

Не любой - http://en.wikipedia.org/wiki/One-time_pad

Мм, https?

Мм, https?

Какой дополнительный функционал даст шифрование на уровне JS, если данные и так бегают по HTTPS? Дай пример реальной задачи, где использование такого шифрования + HTTPS дает что-то полезное по сравнению с использованием только HTTPS.

Сделать это нужно таким образом, чтобы человек в середине, который подменит скрипт, не смог создать правильную подпись. Ты же в курсе, что скрипт с подписями весь будет тянутся по сети? Или подписи будут доставляться по другому каналу?

ессно по другому.

например при доступе по https (ssl/tls) используется открытый ключ, который уже имеется в браузере. Злоумышленнику придётся ломать либо мой сервер, либо комп клиента, либо центр сертификации. Атака посередине уже не прокатит.

Не любой

этот шифр нельзя взломать только при соблюдении некоторых условий. Самое неудобное - наличие одноразового случайного ключа у Алисы и Боба, причём при его отсутствии у всех злоумышленников. Как ты собрался решить проблему передачи этого ключа?

ну они сами дураки

Какой дополнительный функционал даст шифрование на уровне JS, если данные и так бегают по HTTPS?

https и не должно обеспечивать шифрование. Однако, можно обменяться открытыми ключами. Проблема в Алисе, если она ТП. Если не ТП, то Алиса может прочитать man gpg и не парится, но если таки ТП, то может использовать софт с доверенного сайта для шифрования.

этот шифр нельзя взломать только при соблюдении некоторых условий

Да я знаю

Как ты собрался решить проблему передачи этого ключа?

Зависит от задачи и ограничений. Часто передача непрактична.

Мне кажется, что на техническом ресурсе стоит осторожно применять кванторы общности. Поэтому и внес небольшое уточнение. Без обид.

Мне кажется, что на техническом ресурсе стоит осторожно применять кванторы общности. Поэтому и внес небольшое уточнение. Без обид.

мне кажется, твой случай - случай сферического коня в вакууме. IRL оно хоть и достижимо(в отличие от коня), но никому не нужно.

Если хочешь проверить свой способ IRL, выполни команду

time -p dd if=/dev/random of=/tmp/random bs=128 count=10

Потом расскажи, _где_ на практике такое можно применить?

Учти, что генератор ПСЧ (вроде /dev/urandom) для твоих целей НЕ годен(ибо вскрывается тривиально).

IRL оно хоть и достижимо(в отличие от коня),

прогресс

но никому не нужно.

Опять квантор общности.

Учти, что генератор ПСЧ (вроде /dev/urandom) для твоих целей НЕ годен(ибо вскрывается тривиально).

Это известно многим.

что-бы узнать, сколько секунд надо, что-бы получить жалкие 1280 байт ключа, для шифрования ничтожного килобайта. (у меня 20 сек понадобилось).

И? Все зависит от задачи и ресурсов.

Потом расскажи, _где_ на практике такое можно применить?

Шнайер в книге «Прикладная криптография» пишет: «Одноразовые блокноты используются и сегодня, главным образом для сверхсекретных каналов связи с низкой пропускной способностью»

я плакал. в 1000 раз медленнее не хочешь?

А какой в этом смысл?

Серьезная криптография, которая на си работает секунды

Интересно, какая криптография работает на си секунды..

Для этого придумали цифровые подписи.

А кто их будет проверять?

Интересно, какая криптография работает на си секунды..

Например подбор sha-256 хеша, удовлетворяющего некоторым параметрам.

Для этого придумали цифровые подписи.

А кто их будет проверять?

Аддон.

+1

Шнайер в книге «Прикладная криптография» пишет: «Одноразовые блокноты используются и сегодня, главным образом для сверхсекретных каналов связи с низкой пропускной способностью»

скорее «писал», лет так 40 назад. Проблема в том, что _реальная_ защищённость метода криптографии всегда _меньше_ теоретической. Проблема одноразового блокнота - в одноразовом блокноте, который БОЛЬШОЙ и который надо где-то хранить. Т.е. например у тебя есть сверхсекретная радиостанция, передающая код. Дык что-бы гарантированно передать сообщение в течении 24х часов, эта радиостанция должна КАЖДЫЙ день передавать НОВОЕ сообщение максимальной величины, дабы враг ничего не заподозрил. Т.е. на этой станции должен лежать HDD со ВСЕМИ кодами, хотя-бы на год вперёд. А лучше - бумажный блокнот, т.к. довольно сложно уничтожить на HDD часть информации, дешевле ручками, по старинке. Обеспечивать СЕКРЕТНОСТЬ такого блокнота будет ОЧЕНЬ сложно, враг всегда может его вскрыть под видом воров/сантехников/вписать_нужное.

Короче - стоимость вскрытия такого шифра вовсе не бесконечная, а наоборот - довольно таки малая. По сравнению с обычной криптографией.

ЗЫЖ ну а воены вполне могут иметь совсем иное мнение. Особенно в каких-то экзотических условиях. Да и цена их не слишком волнует.

Интересно, какая криптография работает на си секунды..

любая криптостойкая. Может и минуты, всё зависит от объёма информации и от длинны ключа.

А кто их будет проверять?

SSL/TLS может и сам браузер тупой Алисы проверить. Надо только Бобу сертификат получить.

Аддон.

А почему бы и крипту не запихать в аддон?

любая криптостойкая

Миллисекунды :]

SSL/TLS может и сам браузер тупой Алисы проверить. Надо только Бобу сертификат получить.

Предоставлять каким-то левым чувакам в любой момент времени скомуниздить твои ключи - какое то стремное развлечение

Аддон для параноиков, и они его могут написать сами или поискать существующий, при чём тут криптография? Требовать установить аддон, чтобы пользоваться сайтом? Звучит, мягко говоря, маразматично.

Зачем для пользования сайтом криптография отличная от TLS?

Миллисекунды :]

спешу тебя расстроить: то, что работает миллисекунды, брутфорсится на том же железе за минуты/часы. Т.е. не может считаться стойким. А проблема JS'а в том, что злоумышленник вовсе не обязан тоже на JS'е ломать.

Возьми к примеру простую задачу умножения двух больших чисел - умножить их можно быстро, но вот раскладывать произведение намного дольше. Вот только это будет не настолько «намного», как тебе хочется, если ты будешь множить JS'ом побайтно, а злоумышленник будет раскладывать на регистрах SSE2 по 128 бит.

SSL/TLS может и сам браузер тупой Алисы проверить. Надо только Бобу сертификат получить.

Предоставлять каким-то левым чувакам в любой момент времени скомуниздить твои ключи - какое то стремное развлечение

в мой профиль загляни, и найди там мой ключ. SSL/TLS работает точно также, разница лишь в том, что центр сертификации там не ЛОР, а другой сервер(который прописан в браузере Алисы). Ну и ещё разница в том, что для проверки моей подписи тебе надо осилить man gpg, а вот Алисе - не нужно, браузер сам автоматом проверяет.

Зачем для пользования сайтом криптография отличная от TLS?

ну во первых TLS ключик денег стоит, а значит ты его анонимно не получишь. Нужен свой сайт, в котором твои паспортные данные прописаны. Большинству Бобов такой расклад не понравится.

генератор ПСЧ (вроде /dev/urandom)

http://stackoverflow.com/questions/1868964/how-random-is-urandom
urandom в линуксах, внезапно, является довольно криптостойким (ибо использует алгоритм Ярроу), по крайней мере пока энтропийный пул не пуст.

Я вроде описал в первом посте, зачем. Например, чтобы отправлять вместе с запросом его цифровую подпись гостовским сертификатом. Или реализовывать произвольные криптографические алгоритмы, например хешировать пароль перед отправкой на сервер в форме логина.

urandom в линуксах, внезапно, является довольно криптостойким (ибо использует алгоритм Ярроу), по крайней мере пока энтропийный пул не пуст.

ты сам-то читал?

Last time I looked /dev/urandom on linux returned the same output as /dev/random as long as there is entropy in the pool because they both use the pool. The difference is that urandom will fall back on a plain rehashing algorithm when there is no stored entropy, while random will wait until new entropy has been added

в том-то и дело, что /dev/random зависнет, как только пул опустеет. А вот /dev/urandom будет давать значения дальше. Только вот эти значения будут вполне предсказуемы, и НЕ годные для одноразового блокнота (хотя вполне годные для всего остального, вроде метода монтекарло и т.д.)

PS: я проверил последовательность на предмет предсказуемости, простые методы ничего не дали. Это говорит лишь о том, что я вот так с ходу на коленки расшифровать не смогу. Однако никто не гарантирует, что враг не воспользуется каким-то специальным способом.

PPS: изначально мне говорили про _принципиально_ невзламываемый шифр, а ты мне тут про алгоритм Ярроу говоришь. Фактически - самая обычная ПСП, только зашифрованная. Проще прямо сообщение шифровать, а не ПСП, которой потом сообщение. Ещё и быстрее и надёжнее.

Шнайер в книге

скорее «писал», лет так 40 назад.

Взято отсюда: http://www.amazon.com/Applied-Cryptography-Protocols-Algorithms-Source/dp/047... правда у меня русский перевод Publication Date: October 18, 1996 Меньше 17 лет назад.

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

Учи матчасть - против какой атаки стойкость этого шифра абсолютна - там же описаны ограничения и возможности атакующего, все остальное домыслы.

Особенно порадовали вот эти фразы:

А лучше - бумажный блокнот ... дешевле ручками, по старинке

И сколько ты будешь свой «ничтожный килобайт» шифровать? А мегабайт? Откажемся от электричества - вернемся к свечам?

враг всегда может его вскрыть под видом воров/сантехников/вписать_нужное.

Если есть доступ к ключам - криптография не обеспечивает защиты, это очевидно.

Взято отсюда: http://www.amazon.com/Applied-Cryptography-Protocols-Algorithms-Source/dp/047... правда у меня русский перевод Publication Date: October 18, 1996 Меньше 17 лет назад.

я эту книжку где-то тогда и читал ☺

Учи матчасть - против какой атаки стойкость этого шифра абсолютна

учил. Против сферической атаки в сферическом вакууме. Когда в руках злоумышленника только формулы, и нет даже паяльника на 40Вт. ☺ А с паяльником будет не смешно, а больно ☹

И не говори мне, что любой шифр против РК бессилен, секретный ключ очень просто уничтожить, причём так, что потом невозможно восстановить. Даже с паяльником. Сохранять, прятать и охранять его тоже проще. А ещё он многоразовый, действует нужное количество времени, и допускает безопасную отправку своей публичной части.

И сколько ты будешь свой «ничтожный килобайт» шифровать? А мегабайт? Откажемся от электричества - вернемся к свечам?

дык проблема одноразового блокнота как раз в длине. 4096 бит достаточно только для шифрования 4096ит, да и то только в идеальном случае. Мало того, что тебе нужно МНОГО этого блокнота, дык тебе нужны ДВЕ абсолютно секретные копии.

Проблема также и в уничтожении - как Алисе уничтожать ненужное? Причём синхронно с Бобом. Причём со 100% гарантией?

Если есть доступ к ключам - криптография не обеспечивает защиты, это очевидно.

асимметричная решает эту проблему. там нужно охранять только ключ на принимающей стороне, это намного проще. К примеру, Алиса работает в тылу врага, и шлёт депеши Бобу в центр. Враг может сделать с Алисой что угодно, вот только расшифровать её послания не может даже она сама. Для неё и врага это белый шум. Кроме того, враг не может найти у Алисы блокнот, и этим её спалить. Публичный ключ может быть где угодно, например в профиле Боба на ЛОРе. Ну а блокнот у Алисы - прямое доказательство того, что она - крыса. Можно даже ничего не расшифровывать, враг Алисы и так знает свои тайны.

Потому, схема с одноразовым блокнотом, хоть и неуязвима в вакууме, но по жизни бесполезна. Особенно теперь, с флешками и SSD, которые толком стирать не умеют.

Возьми к примеру простую задачу умножения двух больших чисел - умножить их можно быстро, но вот раскладывать произведение намного дольше. Вот только это будет не настолько «намного», как тебе хочется

Ты имеешь ввиду RSA? Факторизация целых чисел? Если да, то ты в курсе какая там разница в сложности между умножением и факторизацией, если соблюдены правила подбора чисел? Или ты знаешь алгоритм быстрой факторизации? Если да, то поделись.

а злоумышленник будет раскладывать на регистрах SSE2 по 128 бит.

Ну а здесь ты в курсе какое ускорение дают SIMD инструкции?

А теперь сравни сложность алгоритма факторизации и ускорение SSE.

Ты имеешь ввиду RSA? Факторизация целых чисел? Если да, то ты в курсе какая там разница в сложности между умножением и факторизацией, если соблюдены правила подбора чисел?

знаю. большая. однако, я знаю, также и то, что скрипт на JS будет ОЧЕНЬ медленно работать.

Ну а здесь ты в курсе какое ускорение дают SIMD инструкции?

по сравнению с чем? с аккуратной реализацией на асме MMX? Для RSA раз так в 5 наверное. Но по сравнению с JS - в 500. А может и больше. Ну не заточен JS на такое, by design. А CPU - более универсален. Кроме того, у злоумышленника и вообще техника может быть помощнее, и подождать о часик может. А юзер JS скрипта даже секунду ждать не согласен.

А с паяльником будет не смешно

Только с паяльником будет именно что смешно, если не знать к кому применить или не иметь возможности дотянуться. Но это все словесная эквилибристика. Иногда в нее весело играть, но почти всегда пустая трата времени.

Ограничения подхода хорошо известны, нет смысла писать портянки текста. Но эти примеры не опровергают моих утверждений.

ЗЫЖ ну а воены вполне могут иметь совсем иное мнение. Особенно в каких-то экзотических условиях. Да и цена их не слишком волнует.

и

Потому, схема с одноразовым блокнотом, хоть и неуязвима в вакууме, но по жизни бесполезна

Ты противоречишь себе и я еще приводил слова эксперта в своей области, который утверждает что схема использовалась в жизни, и используется сейчас, и условия при которых есть смысл использовать.

знаю. большая. однако, я знаю, также и то, что скрипт на JS будет ОЧЕНЬ медленно работать.

Очень - это не подход, нужны цифры. Вот например (я не эксперт и могу ошибаться) - я встречал что лучший алгоритм факторизации - http://en.wikipedia.org/wiki/General_number_field_sieve, сложность там дана. Она больше полиномиальной.

по сравнению с чем? с аккуратной реализацией на асме MMX? Для RSA раз так в 5 наверное. Но по сравнению с JS - в 500

То есть линейное. Дальше продолжать?

Учитывая появление https://mega.co.nz/ со скоростью у js там уже вполне, http://fail0verflow.com/blog/2013/megafail.html CBC-MAC AES-128 SHA-256, все это считается вполне надежным (ну может АНБ знает как сломать)

А вот с реализацией, судя по вышеприведенному линку, есть проблемы.

спешу тебя расстроить: то, что работает миллисекунды, брутфорсится на том же железе за минуты/часы. Т.е. не может считаться стойким. А проблема JS'а в том, что злоумышленник вовсе не обязан тоже на JS'е ломать.

Во дела! Пойду поцонам расскажу, а то они не в курсе :D

Возьми к примеру простую задачу умножения двух больших чисел - умножить их можно быстро, но вот раскладывать произведение намного дольше. Вот только это будет не настолько «намного», как тебе хочется, если ты будешь множить JS'ом побайтно, а злоумышленник будет раскладывать на регистрах SSE2 по 128 бит.

По реке плывет бревно, а за ним еще одно. Ну и пусть себе плывет, видно там у них гнездо

в мой профиль загляни, и найди там мой ключ. SSL/TLS работает точно также, разница лишь в том, что центр сертификации там не ЛОР, а другой сервер(который прописан в браузере Алисы). Ну и ещё разница в том, что для проверки моей подписи тебе надо осилить man gpg, а вот Алисе - не нужно, браузер сам автоматом проверяет.

Не про то