>>> a=0.1+0.2
>>> a
0.30000000000000004
>>> for i in range(32):
... a = a / 2.0
...
>>> a
6.98491930961609e-11
>>> for i in range(32):
... a = a * 2.0
...
>>> a == (0.1 + 0.2)
True
>>> for i in range(64):
... a = a / 2.0
...
>>> a
1.626303258728257e-20
>>> for i in range(64):
... a = a * 2.0
...
>>> a == 0.1 + 0.2
True
Например, что RSA не используется как блочный алгоритм.
Поэтому в библиотеке не встроено разбиение сообщения на блоки.
/*
* Ебанная хуня, пишу костыли, т.к. разрабы либы ПИД*РАСЫ
* Либа должна сама текст на куски разбивать, а она нах*й посылает и пишет Лимит для RSA превышен.
*/
_getSmallBlock: function (message, limit, callback) {
var length = message.length,
count = Math.ceil(length / limit),
textBlock = "";
for (var i = 0; i < count; i++) {
var from = i * limit,
to = from + limit,
part = message.substring(from, to);
textBlock += callback(part) || "";
}
return textBlock;
},
А что если собеседник будет использовать модифицированную версию плагина, которая не слушает команды и не удалаяет ключи?
Что если собеседник записывает ключи из плагина?
> всегда можно вывести человека в лес
Я говорю о чисто технических слабостях алгоритма и протоколов.
Прочитав исходный код, я понял, что у автора нет понимания свойств RSA.
Мне надоело показывать, что каждое утверждение в комменте является некорректным, или бессмыссленным.
> это не имение математического доказательства его «устойчивости».
Ни один алгоритм шифрования не имеет доказательства его устойчивости. Есть алгоритмы, которые оприваются на NP-полные задачи. Есть другие алгоритмы, для которых еще не известны атаки. Ни для одних, ни для других доказательства «устойчивости» нет.
> Что именно вы считаете «неполноценным в корне»?
Попытки техническими средствами ограничить круг действий, которые может совершить пользователь с цифровым контентом.
Например: защита от копирования, «активация» софта, бессмысленное требование подключения к серверу или выключение фич.
> Теория доказывает, что приведенный выше мной пример полностью устойчив
Что это нам теория говорит об ограничении функциональности через «установку прав в начале программы»?
Это две разные функции, теория неприменима.
Например, функция P1(«Нарисуй круг»)=(рисует круг) и P2(«Нарисуй круг»)=(купите про версию фотошопа)
> получить доступ к скрытой функциональности, если вы используете обфускацию неразличимости, невозможно.
Что это нам теория говорит об «скрытой функциональности»? Ничего.
>Шифр AES — это ни что иное как security by obscurity
Нет. Все знают алгоритм AES. Конечный пользователь знает секретный ключ. Единственное ограничение — третьи лица не знают секретный ключ.
«White box encryption» предлагает такое решение, при котором конечному пользователю дают софт, который может расшифровать AES, но при этом пользователь не может выдрать ключ из софта, потому что программа запутанная.
>Но вместо этого вы можете в начале программы задать права доступа (permissions), закодировать их прямо в код
Это называется «DRM» и эта идея неполноценна в корне.
>Представьте программу, которая берет например sha1 хэш от входа, использует его как ключ для расшифровки остальной части кода.
Это ортогонально обфускации. Я могу узнать, что одна часть программы расшифровывает другую, и окажусь в том же положении, если бы программа не была обфусцирована. Как только я получаю вход, я могу расшифровать вторую частьпрограммы и продолжить деобфускацию.
>А как же whitebox имплементации шифров?
Их пытаются изобрести для DRM, это задача, сломанная по определению.
Вообще, что спорить — дайте программу, которая расшифровывает данные из stdin, использует известный алгоритм шифрования, а я попытаюсь выдрать из нее ключ.
Я ставлю на что, это неосуществимо в общем случае.
>Обфускация программ — это прорывная
Нет. Что-то я не вижу статей о супер-обфускаторах, которые никто не может обратить.
>самая горячая сегодня
Нет. Наверное, это первая статья об обфускацию на хабре за 2015 год.
>область криптографии
Нет. В криптрографии не занимаются security through obscurity.
>формально: если имеются две разные программы, но с абсолютно идентичными функциональностями
В реальном мире не бывает двух программ с абсолютно идентичной функциональностью, если это не одна и та же программа.
Единственная работающая цель обфускации — давать головную боль тому, кто пытается разобраться с внутренностями программы.
Все остальные цели или не достигаются, или некорректны.
Имея большой запас терпения, можно разобраться в любой обфусцированной программе и выписать алгоритм.
Но то что здесь изобретается и есть *блочное шифрование*. :)
Поэтому в библиотеке не встроено разбиение сообщения на блоки.
А что если собеседник будет использовать модифицированную версию плагина, которая не слушает команды и не удалаяет ключи?
Что если собеседник записывает ключи из плагина?
> всегда можно вывести человека в лес
Я говорю о чисто технических слабостях алгоритма и протоколов.
Прочитав исходный код, я понял, что у автора нет понимания свойств RSA.
Вконтакт может передавать сообщения на сервер до того как сообщение будет зашифровано, и приватность идет лесом.
yourdatafitsinram.com
> это не имение математического доказательства его «устойчивости».
Ни один алгоритм шифрования не имеет доказательства его устойчивости. Есть алгоритмы, которые оприваются на NP-полные задачи. Есть другие алгоритмы, для которых еще не известны атаки. Ни для одних, ни для других доказательства «устойчивости» нет.
> Что именно вы считаете «неполноценным в корне»?
Попытки техническими средствами ограничить круг действий, которые может совершить пользователь с цифровым контентом.
Например: защита от копирования, «активация» софта, бессмысленное требование подключения к серверу или выключение фич.
> Теория доказывает, что приведенный выше мной пример полностью устойчив
Что это нам теория говорит об ограничении функциональности через «установку прав в начале программы»?
Это две разные функции, теория неприменима.
Например, функция P1(«Нарисуй круг»)=(рисует круг) и P2(«Нарисуй круг»)=(купите про версию фотошопа)
> получить доступ к скрытой функциональности, если вы используете обфускацию неразличимости, невозможно.
Что это нам теория говорит об «скрытой функциональности»? Ничего.
Нет. Все знают алгоритм AES. Конечный пользователь знает секретный ключ. Единственное ограничение — третьи лица не знают секретный ключ.
«White box encryption» предлагает такое решение, при котором конечному пользователю дают софт, который может расшифровать AES, но при этом пользователь не может выдрать ключ из софта, потому что программа запутанная.
>Но вместо этого вы можете в начале программы задать права доступа (permissions), закодировать их прямо в код
Это называется «DRM» и эта идея неполноценна в корне.
Это ортогонально обфускации. Я могу узнать, что одна часть программы расшифровывает другую, и окажусь в том же положении, если бы программа не была обфусцирована. Как только я получаю вход, я могу расшифровать вторую частьпрограммы и продолжить деобфускацию.
>А как же whitebox имплементации шифров?
Их пытаются изобрести для DRM, это задача, сломанная по определению.
Вообще, что спорить — дайте программу, которая расшифровывает данные из stdin, использует известный алгоритм шифрования, а я попытаюсь выдрать из нее ключ.
Я ставлю на что, это неосуществимо в общем случае.
Например то, что нет схем DRM, которая имплементирована целиком в софте, которую еще не обошли.
Нет. Что-то я не вижу статей о супер-обфускаторах, которые никто не может обратить.
>самая горячая сегодня
Нет. Наверное, это первая статья об обфускацию на хабре за 2015 год.
>область криптографии
Нет. В криптрографии не занимаются security through obscurity.
>формально: если имеются две разные программы, но с абсолютно идентичными функциональностями
В реальном мире не бывает двух программ с абсолютно идентичной функциональностью, если это не одна и та же программа.
Единственная работающая цель обфускации — давать головную боль тому, кто пытается разобраться с внутренностями программы.
Все остальные цели или не достигаются, или некорректны.
Имея большой запас терпения, можно разобраться в любой обфусцированной программе и выписать алгоритм.
«Последовательности маркова» как-то цепляет глаза.
facebook.github.io/react/docs/reconciliation.html