Сплю и вижу, как в почтовые ящики студенческого общежития приходит 500 конвертов учащимся IT специальностей со штрафами за скачивание полного собрания сочинений Таненбаума…
В начальной фазе инициализации сколько захотите, столько и будет стойкость: никто не запрещает использовать AES и для ключей длины 32 биты. В этом случае нам уже не интересно есть ли дальше уязвимости. Интерес в том не вносит ли алгоритм генерации гаммы других уязвимостей, о чем собственно и говорит тест next-bit.
Тут довольно тонкий момент есть: 76352843 можно уместить и в 32-битное число, и в 128-битное и в 512-битное. Так вот в случае Пи это число бесконечно битное, просто старшие разряды нули. Или числа после некоего предела в последовательности Пи отбрасываются?
У 76352843 уместится и в 32-битный int, что по сути ничего не меняет. Вы вслепую ссылаетесь на теорему Шеннона про идеальные шифры. Просто тогда и гамму надо как-то передавать по еще одному секретному каналу.
В том же RC4 когда ваш браузер безопасно соединяется вас же не смущает, что генерируется очень большая гамма из маленького начального ключа? Допустим, всего 128 бит?
Когда вы получили эту последовательность у вас нет гарантии, что данная последовательность не повторяется «чуть» раньше или «чуть» позже: до данной позиции у вас еще примерно столько же, сколько и порядковый номер, последовательностей длины миллион. Об этом я и говорю выше: вы не сможете просто так угадать этот номер, ведь данная последовательность будет встречаться бесконечное множество раз в Пи.
Возможно, я непонятно объясняю… =(
Если вы перехватили часть последовательности гаммы(потока бит числа Пи в данном случае), то это не дает вам возможность найти следующие биты. Данное условие направлено было исходя из того, что алгоритм генерации — конечный автомат и по N отсчетам (n1,n2...nN) можно найти текущее состояние генератора. В случае же числа Пи сколько угодно отсчетов можете взять и это не поможет: существует бесконечно много отсчетов вида (n1,n2...nN,l1,l2....lL), т.е. включающих в себя выбранный.
Другими словами скомпрометированный кусок может продолжаться бесконечным числом способов.
Хэш генерируется довольно просто тут:
1) Ключ берется методом NativeBridge.getInstagramString("a4d1b77bbb1a4a5ca695ad72c84b77e5"); в кодировке UTF-8. Видимо какой-нибудь native функцией судя из названия, хотя мало ли
2) Алгоритм аутентификации сообщений — HMAC с SHA-256, причем надо заметить интересно они ищут алгоритм по названию… :)
3) Входными данными для MAC является входной параметр String paramString из generateSignature
4) Далее хэш преобразуется в BigInteger, хотя зря на мой взгляд: String.format принимает и byte[] в том числе
5) На выход идет String с hex записью полученного хэша.
Понимаете, лучше, когда у разработчика есть возможность быстро реализовать какую-то возможно ненужную фичу, чем он потратит уйму времени на возможно нужную.
Если раньше в области дизайна что-то не работало, то современная молодежь вполне может использовать это по default'у. И никакие законы дизайна тут не помогут, как мне кажется.
Поэтому я вижу смысл предоставить разработчику быструю возможность создания таких элементов. А выбирать что конкретно нравится пользователю — задача, очевидно, пользователя.
В том же RC4 когда ваш браузер безопасно соединяется вас же не смущает, что генерируется очень большая гамма из маленького начального ключа? Допустим, всего 128 бит?
Возможно, я непонятно объясняю… =(
pS. вот бы для всех шифров так анализ происходил: для начала найдем секретный ключ. не важно каким путем.
Другими словами скомпрометированный кусок может продолжаться бесконечным числом способов.
1) Ключ берется методом
NativeBridge.getInstagramString("a4d1b77bbb1a4a5ca695ad72c84b77e5");в кодировке UTF-8. Видимо какой-нибудь native функцией судя из названия, хотя мало ли2) Алгоритм аутентификации сообщений — HMAC с SHA-256, причем надо заметить интересно они ищут алгоритм по названию… :)
3) Входными данными для MAC является входной параметр
String paramStringизgenerateSignature4) Далее хэш преобразуется в BigInteger, хотя зря на мой взгляд: String.format принимает и byte[] в том числе
5) На выход идет String с hex записью полученного хэша.
возможно ненужнуюфичу, чем он потратит уйму временина возможно нужную.Если раньше в области дизайна что-то не работало, то современная молодежь вполне может использовать это по default'у. И никакие законы дизайна тут не помогут, как мне кажется.
Поэтому я вижу смысл предоставить разработчику быструю возможность создания таких элементов. А выбирать что конкретно нравится пользователю — задача, очевидно, пользователя.