Рейтинг:1

Может ли существовать инъективная функция, которая отображает большой набор целых чисел в меньший набор, будучи «осведомленной о столкновениях»

флаг in

Рассмотрим два набора:

«Большой набор» содержит все целые числа между $0$ и $2^{160}$ ровно один раз.

«Малый набор» содержит все целые числа между $0$ и $2^{32}$ ровно один раз.

Учитывая, что количество элементов в «большом наборе» больше, чем в «малом наборе», не может быть инъективной функции. $f(n_b) = n_s$ сопоставление любого ввода, являющегося членом «большого набора» $n_b$ к выходу, который является членом «небольшого набора» $n_s$. Если эта функция $ф$ существовало, это был бы ответ на вопросы.

По практическим соображениям мы предполагаем, что все еще может существовать конструкция/алгоритм с практической функцией $f_p$ где результаты всех входов в $f_p(n_b)$ являются членами «малого множества» и каждый $n_b$ указывает на отчетливое $n_s$.

Из-за отсутствия понимания криптографических концепций я назову это свойство «осведомленным о коллизиях». Например. реализовать эту конструкцию, предполагая емкость хранилища размером $2^{256}$ (256-битное целое без знака), есть ли функция $f_p$ или алгоритм, который для любого $n_b$ либо возвращает «столкновение» («с учетом столкновений»), либо отдельный член $n_s$?

флаг cn
Мне очень непонятно, что вы ищете. Чем то, что вы описываете во втором абзаце, отличается от инъективной функции?
флаг cn
Что означает «обратное столкновение»?
user10030 avatar
флаг in
Я ищу функцию, в которой карта (домен)> карта (домен кода), но каждое число, которое я принимаю в качестве входных данных для функции из домена, сопоставляется с отдельным номером в домене кода. Насколько я понимаю, это возможно только в том случае, если карта (домен) >= карта (кодовый домен). Итак, поскольку это невозможно, могу ли я иметь функцию, которая разрешает такое сопоставление, но, например. «ошибки», если коллизия обнаружена впервые.
флаг cn
Это невозможно, да. Но какое именно поведение вы хотите? Функция либо возвращает значение из домена, либо символ ошибки?
user10030 avatar
флаг in
Вот что мне практически нужно: время от времени я получаю случайное число из uint160 (это учетная запись/адрес Ethereum), и мне нужна функция, которая отчетливо сопоставляет каждый адрес с определенным слотом списка длиной 2 ^ 32.Скажем, я уже выделил 100 адресов, теперь адрес № 101 становится длинным, и его слот такой же, как, например. # 91, тогда я хочу знать, что теперь есть коллизия для слотов, # 101 не должен перезаписывать # 91. Однако я не могу просто сохранить все ранее сохраненные адреса. У меня есть только слот для хранения размером, например. uin256.
флаг cn
Без каких-либо дополнительных требований функция определяется как «Если $x\leq2^{32}$, вернуть $x$, иначе вернуть $\bot$». кажется, удовлетворяет ваши требования из вопроса. Но я уверен, что у вас есть дополнительные требования, которые вы почему-то отказываетесь указывать.
user10030 avatar
флаг in
Это не отказ. Это скорее неспособность правильно выразить себя. Я постараюсь указать больше. Спасибо за помощь до сих пор. Продолжение: если бы мы использовали «if $x
fgrieu avatar
флаг ng
Как насчет усеченного хэша? В нашем случае это работает до № 101 включительно с менее чем 1 шансом на 850 тысяч обратного.
флаг cn
Следующая заведомо неверная попытка выяснить, что вы на самом деле ищете: присваивать индексы последовательно. Поддерживайте 33-битный счетчик n, инициализированный нулем. Каждый раз, когда вы видите ввод, если $n
user10030 avatar
флаг in
@fgrieu Интересно. Что мне нравится в этом, так это то, что он постепенно и равномерно заполняет пространство кодового домена 2 ^ 32. Проблема, которую я вижу, однако, заключается в том, что с учетом хеш-функции: я хочу сохранить баланс эфира по отношению к ней. Например. Я хочу сказать, что $n_b$ например. 0xabc... — $n_s$ владеет 1 эфиром. Однако по мере того, как балансы становятся больше, в какой-то момент — подобно тому, как это происходит с биткойн-майнингом — может стать экономически выгодным запустить алгоритм грубой силы, например. найти коллизию для $n_s$ для аккаунта $n_b$, который в настоящее время имеет большой баланс.
user10030 avatar
флаг in
Привет, @Maeher. Учитывая счетчик, который увеличивается с каждым вводом и имеет емкость на 1 бит больше, чем число MAX в кодовом домене, проблема заключается в том, что для любого числа в домене я хочу назначить ему ровно одно число в кодовом домене даже при повторных вставках. Я работаю в области информатики, поэтому я бы назвал такую ​​функцию «детерминированной». Учитывая конкретный ввод, он всегда производит один и тот же вывод. Насколько я понимаю, если бы мы использовали увеличивающийся счетчик, если бы мы неоднократно вставляли один и тот же ввод несколько раз, мы каждый раз получали бы разные результаты кодомена (увеличение, например, на +1).
флаг cn
Вы можете попробовать использовать усеченный хэш и поддерживать приблизительную структуру данных набора (например, фильтр Блума) израсходованных индексов. Но вполне вероятно, что это окажется слишком большим.
Рейтинг:2
флаг cn

Как насчет:- $$ n_s = \mathcal{H}(n_b) \& (2^{32} - 1) $$ куда $n_b \в N_b$, и т.д? $\mathcal{Н}$ может быть хеш-функцией по вашему выбору. Поскольку это крипто-сайт, я предлагаю SHA-256. $\&$ означает побитовое И, но может быть заменено правым или левым сдвигом соответствующего количества битов (128 в случае SHA-256). Возможно, слишком медленно (?)

Криптографические хэш-функции сюръективный, что означает, что их выходы иногда сталкиваются. Эта частота столкновений значительно увеличится, если вы урежете $\mathcal{Н}$ до 32 бит. Тем более будет эффект от принцип голубиной дыры. Итак, вы установили $N_b$ заполнение равномерно распределенными числами, давая $n_b \до n_s$ с домена на кодомен.


Не знаю насчет Ethereum, но 160 подозрительно похоже на результат SHA-1. Если это так, просто усеките учетную запись/адрес до 32 бит, поскольку они уже распределены равномерно.

флаг ma
«Криптографические хэш-функции сюръективны» — я так не думаю. Сюръективность означает, что для каждого возможного хеш-значения существует некоторое сообщение, которое его генерирует. Вы не можете доказать, что криптографическая хэш-функция не имеет «слепых зон».
user10030 avatar
флаг in
Привет, @paul-uszak. Я прокомментировал в своем первоначальном ответе, почему я считаю, что усечение не является оптимальным решением. Относительно uint160 и SHA-1: в Ethereum учетная запись создается из открытого ключа ECDSA, затем хэшируется с помощью Keccak-256 до 32-байтного вывода, а затем, что удивительно, усекается, используя только последние 20 байтов. Наконец, он имеет префикс 0x. Подробнее: https://ethereum.stackexchange.com/a/3619/47031
Paul Uszak avatar
флаг cn
@user10030 user10030 Итак, у вас есть ответ :-) Сократите до четырех байтов, и вот оно, как в моем постскриптуме.
user10030 avatar
флаг in
Хотя я ценю существование вашего решения, я считаю, что это не то, что мне в конечном итоге понадобится. В случае, если я усекаю до 4 байтов, я начинаю давать своим пользователям стимул добывать $n_b$s, что приводит к тому же $n_s$. Конечно, для адресов $n_b$, содержащих небольшое количество денежных средств, это может не быть реальной проблемой или экономически обоснованной атакой: но в целом я хотел бы избежать проблем такого типа. Коллизий либо не может быть, либо они могут быть, и я сразу же узнаю о них, поскольку я могу оглянуться на все другие входные и выходные данные операции хеширования.
Paul Uszak avatar
флаг cn
@user10030 user10030 Абсолютно будут коллизии из-за принципа голубятни. Лучшая ставка $2^{-32}$ за аккаунт. Затем он будет бессимптомно увеличиваться до 1 по мере заполнения домена кода.
Рейтинг:1
флаг ph

Если я понимаю требования, то, о чем вы просите, не является «функцией» в соответствии с обычным определением. Похоже, вы хотите немного $f$ что при заданной последовательности входных данных ${x_i}$ вернет либо детерминированное значение $y_i$ или символ ошибки, если он уже вернулся $y_i$. Но предположим $x_k$ это первый ввод, возвращающий ошибку. Что должно произойти, если вы позвоните $f$ с последовательностью, начинающейся с $x_k$? Я думаю, вы бы хотели, чтобы он не возвращал ошибку, поэтому значение $f(x_k)$ не является четко определенным.

Чтобы разрешить это математически, нужно изменить определение $f$ принять последовательность. Но на практике это, вероятно, означает, что ваша система записывает все входные данные, которые были вызваны. И вы обнаружите, что если вы это сделаете, вы можете просто вернуться $0,...,n-1$ для первых отдельных входов и ошибок для всего последующего.

user10030 avatar
флаг in
Да, на практике быть «осведомленным о столкновениях», вероятно, означало бы передавать последовательность в $f$. На самом деле, передача последовательности не будет проблемой, если это не приведет к увеличению памяти для каждой новой операции хеширования. Мне интересно, есть ли, например. способ, при котором ранее переданное значение может быть разложено на множители или сжато, чтобы они не занимали много памяти, и где стало бы практичным всегда передавать все прошлые значения и новое, чтобы сделать функцию «учитывающей коллизии», как в «он возвращает символ ошибки, если он встречает вывод более чем в первый раз».

Ответить или комментировать

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