Nik*_*kos 3 hash cryptography hash-function hashtable cryptographic-hash-function
我正在学习有关哈希表，哈希地图等我刚刚实施了哈希表在C，与操作：insert(HTable, key)，delete(HTable, key)，initialize(HTable)和search(HTable, key)。
我想问一件事。由于在（适当的）哈希表中，计算出的哈希索引可能非常大，这是否意味着消耗的空间会像INT_MAX（当然仍然是 O(n)）或更多？我的意思是给定我们想要存储在哈希表中的输入元素（即插入它），insert() 函数将调用哈希函数，然后该函数将计算要进入的元素的哈希索引。因此它将使用哈希函数来找到这个索引。
当我们使用哈希函数对元素进行操作时，哈希索引可能会变得非常大。使用适当的，例如加密哈希函数，这个索引可能会变得很大（他们使用 300 位的素数 - Diffie Hellman 公钥密码学等），对吧？我知道在普通的散列函数（例如初学者用来学习的琐碎函数）中，我们应用 mod 操作以使元素适合散列表的边界，但这样做，也许我们限制了散列函数的潜力？
因此，要将元素唯一地映射到哈希表，我们必须使用一个巨大的哈希表。这些加密哈希表是如何实现的？它们必须是完全安全的，对吧？甚至“cryptographichashfunction”上的 Stack Overflow 标签也表示，极不可能找到将映射到同一元素的两个输入（因此冲突的可能性很小）。这不需要将一个巨大的数组存储在内存（或磁盘）中吗？因此，内存消耗将是巨大的。
当然，时间复杂度不是问题。我们只是看到哈希表/数组的起始地址加上索引，然后去内存中的那个地方获取值（O（1） - 哈希表的搜索原理）。
我在某处错了吗？有什么我想念的吗？我希望我说清楚了。总而言之，我想对此进行确认。一个好的散列函数是否需要一个巨大的数组（散列表）以及如此大量的内存才能正确实现？这么多空间是合理的，还是有什么我不太明白的地方？谢谢。
通常，加密哈希值不用于哈希表。而是使用快速散列。该散列值中只有尽可能多的位可用于调整表的大小。如果多个键值映射到同一个索引，那么这些值存储在一个单独的结构中，可能还有额外的信息可以在两者之间进行选择。
不需要哈希输出是唯一的；散列函数输出会太大，所需的表肯定不适合内存。除此之外，加密哈希通常很慢。
加密散列函数通常是从对称块密码中也使用的操作构建的。这意味着在大量轮次中使用混合和按位运算符。通常不使用用于例如 RSA 的模块化算法。
总而言之，最主要的是生成的索引不需要是唯一的。通常，如果一个散列导致多个值，它们将存储在一个列表或集合中，键可以通过值进行比较。