如何正确调整 Go 中的 Argon2 参数以减少内存消耗？

Question

Argon2在设计上是很耗内存的。在半官方的 Go 实现中，使用时建议使用以下参数IDKey：key := argon2.IDKey([]byte("some password"), salt, 1, 64*1024, 4, 32)其中1是时间参数，64*1024是内存参数。这意味着库在散列值时将创建一个 64MB 的缓冲区。在许多散列过程可能同时运行的情况下，这会对主机内存造成很大压力。在内存消耗过多的情况下，建议减少内存参数并增加时间因子：RFC 草案建议[2] time=1，memory=64*1024 是一个合理的数字。如果在某些情况下无法使用该内存量 (64 MB)，则可以增加时间参数以进行补偿。所以，假设我想将内存消耗限制为 16MB（推荐的 64MB 的 1/4），我仍然不清楚我应该如何调整time参数：这应该是4 倍，以便内存和时间保持不变？或者在时间和记忆的相关性背后还有其他一些逻辑在起作用吗？

Answer 1

RFC 草案建议[2] time=1，memory=64*1024 是一个合理的数字。如果在某些情况下无法使用该内存量 (64 MB)，则可以增加时间参数以进行补偿。

我认为这里的关键是“补偿”这个词，所以在这种情况下，它试图说：要实现与 相似的哈希复杂性IDKey([]byte("some password"), salt, 1, 64*1024, 4, 32)，你可以尝试IDKey([]byte("some password"), salt, 4, 16*1024, 4, 32)。
但是，如果您想降低散列结果的复杂性（并降低性能开销），您可以减小memory uint32忽略time参数的大小。

这应该是 4 倍，以便内存和时间的乘积保持不变？

我不这么认为，我相信memory这里的意思是结果哈希的长度，但time参数可能意味着“哈希结果需要重新哈希多少次，直到我得到最终结果”。

所以这两个参数是相互独立的。这些只是控制您想要实现多少“由于时间-内存权衡而节省的蛮力成本”

Answer 2

难度大致等于time_cost * memory_cost （并且可能/ parallelism）。所以如果你0.25x的内存成本，你应该4x时间成本。另请参阅此答案。

// The time parameter specifies the number of passes over the memory and the

// memory parameter specifies the size of the memory in KiB.

查看 Argon2 API 本身。我将稍微交叉引用并使用argon2-cffi 文档。貌似go接口在底层使用了C-FFI（外来函数接口） ，所以protoype应该是一样的。

Parameters

time_cost (int) – Defines the amount of computation realized and therefore the execution time, given in number of iterations.

memory_cost (int) – Defines the memory usage, given in kibibytes.

parallelism (int) – Defines the number of parallel threads (changes the resulting hash value).

hash_len (int) – Length of the hash in bytes.

salt_len (int) – Length of random salt to be generated for each password.

encoding (str) – The Argon2 C library expects bytes. So if hash() or verify() are passed an unicode string, it will be encoded using this encoding.

type (Type) – Argon2 type to use. Only change for interoperability with legacy systems.

事实上，如果我们查看 Go 文档：

// The draft RFC recommends[2] time=1, and memory=64*1024 is a sensible number.

// If using that amount of memory (64 MB) is not possible in some contexts then

// the time parameter can be increased to compensate.

//

// The time parameter specifies the number of passes over the memory and the

// memory parameter specifies the size of the memory in KiB. For example

// memory=64*1024 sets the memory cost to ~64 MB. The number of threads can be

// adjusted to the numbers of available CPUs. The cost parameters should be

// increased as memory latency and CPU parallelism increases. Remember to get a

// good random salt.

我不是 100% 清楚线程数的影响，但我相信它确实并行化了散列，并且像任何多线程作业一样，这减少了大约1/NN 个内核所花费的总时间。显然，您应该将并行度设置为 cpu count。