Андрей: У меня получилось "найти" эту функцию. Матрицы действительно есть. 32x32.
Может быть найти - это сильно сказано. Я не большой специалист в математике. Уверен, что эти функция где-то уже описана.
В общем то вот сама функция (на Java):
public static int arcFn(int a, int[] matrix) {
int retVal = 0;
for (int i = 0; i < matrix.length; i++) {
retVal ^= Operations.rotateRight(a, i) & matrix[i];
}
return retVal;
}
jcmvbkbc: Названия функций я брал с Вики. В RFC они обозначены по-другому:
BSIG0(x) = ROTR^2(x) XOR ROTR^13(x) XOR ROTR^22(x)
BSIG1(x) = ROTR^6(x) XOR ROTR^11(x) XOR ROTR^25(x)
SSIG0(x) = ROTR^7(x) XOR ROTR^18(x) XOR SHR^3(x)
SSIG1(x) = ROTR^17(x) XOR ROTR^19(x) XOR SHR^10(x)
Ну а отношение к sha256 они имеют прямое. Они же участвуют в расчете значения хеша.
И про перебор. Параметр у этих функций 32-х битный. И результат тоже. Значит на на поиск одного значения требуется максимум 2^32 итераций.
Есть другой вариант - хранение заранее рассчитанных результатов в отдельном массиве и потом выборка из него. Но массив получится размером 2^32 * 4 байт. А это 15 гигабайт. Хранение такого массива - это большая роскошь. Ну по крайней мере на мой взгляд.
Потому, что все, кому я это утверждал, говорят, что это не возможно. Иначе не было бы sha256.
И если нужны доказательства, дайте любое количество результатов этих функций, и я дам обратные значения. Посчитать это не сложно. Но сложно доказать, что это не выборка из базы готовых значений. Вот для этого нужно доказательство. А алгоритм мне показывать не хочется. Потому, что несколько человек уверяют меня, что это не возможно.
У меня есть функция, которая удовлетворяет всем условиям. И не перебором. Значит все эти функции обратимые. Но мне надо это доказать научным языком, а не просто "вот посмотрите, это так, и ни как по другому".
Σ0 и Σ1 это и есть E0 и Е1. Могу точно сказать, они обратимы. Есть расчеты, но нет доказательств. А нужны именно доказательства.
И расчеты не перебором, а имеется функция, x=F(E0(x))
Но там два rol и один shr. То-есть после двух rol значение не исчезает, а в shr тоже все биты известны. Может быть есть все таки надежда, что обратимость имеется?
Хорошо. На примере S0
Есть функция Y=S0(X),
Так вот, хотелось бы знать, есть ли такая функция для S0, чтобы X=F(Y),
А вот про S0, это советую поглядеть в описание SHA256
15432: Нет. Нагло рвутся все соединения. Приходится строить цепочку заново.
а если соединение не разорвалось, то при попытке установить новое, сервер возвращает ошибку и все таки его рвёт. А если последний присоединенный сервер порвал соединение, вся цепочка тут-же разлетается. Возможно, это какое-то свойство бесплатных SOCKS, но факт остается фактом.
Теперь у меня мысль, не переделать ли все на HTTP(S) прокси? Поэтому интересует, как ведут себя они в данном случае?
В общем пока сам все не реализовал - не разобрался. Вы были абсолютно правы. Все работает точно так же, как и в случае с HTTPS.
Но есть один нюанс, который все портит. Если во время построения цепочки, один из следующих серверов не предоставил соединения, то рвется вся цепочка. Есть ли такое же поведение в случае с HTTPS?
С HTTPS проще. там всего один канал. А в SOCKS5 на запрос CONNECT, сервер возвращает адрес и порт, куда надо соединиться, для получения канала до указанного адреса. То есть у него несколько каналов, один для управления, и несколько - для соединений. Если немного не так объяснил, то вот выдержка из RFC:
CONNECT
В ответ на CONNECT, BND.PORT содержит номер порта, который сервер назначает для соединения с указанным хостом, а BND.ADDR содержит связанный IP-адрес. Выданный BND.ADDR зачастую отличается от IP-адреса, который клиент использует для доступа к SOCKS-северу, так как такие сервера часто имеют несколько IP-адресов. Ожидается, что сервер будет использовать DST.ADDR и DST.PORT и адрес клиента при обработке запроса CONNECT.
Александр Карабанов: Выключен. Сам, собственноручно отключил в реестре. И на линуксе тоже.
Заметил еще одно: если запускаю пинг на любой адрес из сети 10.10.10.0/24, которого не существует, то картина та-же самая.
Три арпа бродкастом и потом все пакеты на 10.10.10.254. В дампах я никаких ICMP Redirect найти не могу. Самое инстересно, что в семерке и в ХР все работает как надо. Это только в десятке. И похоже случилось после одного из очередных обновлений. Раньше такой болезни не замечали.
Александр Карабанов: Не покажу весь дамп, так как выкусывать интересующий трафик мне лениво. Но в общих чертах скажу что пока выяснил. По порядку:
1. А локальной ARP таблице нет записи про адрес 192.168.0.1.
2. Я запускаю ping 192.168.0.1 -t.
Результат:
---------------
Обмен пакетами с 192.168.0.1 по с 32 байтами данных:
Ответ от 192.168.0.254: Заданный узел недоступен.
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.
---------------
3. Когда пришел ответ "Ответ от 192.168.0.254: Заданный узел недоступен.", на роутере я вижу:
7.257429 XX:XX:XX:XX:XX:XX -> ARP 62 Who has 192.168.0.1? Tell 10.10.10.1
Ответа на этот запрос я не получаю. То-есть как и должно быть. И так три раза.
4. Когда появляется ответ: "Превышен интервал ожидания для запроса.", у меня в ARP таблице появляется запись "192.168.0.1 00-00-00-00-00-00 недопустимый". И после этого, мой Windows начинает слать эти пакеты на роутер:
8.270074 10.10.10.1 -> 192.168.0.1 ICMP 76 Echo (ping) request id=0x0001, seq=44/11264, ttl=128