Как правильно настроить параметры Argon2 в Go, чтобы потреблять меньше памяти?

Question

Argon2 по замыслу требует памяти. В полуофициальной Go реализации при использовании IDKey рекомендуются следующие параметры:

key := argon2.IDKey([]byte("some password"), salt, 1, 64*1024, 4, 32)

, где 1 - это параметр время и 64*1024 - это параметр memory . Это означает, что при хешировании значения библиотека создаст буфер размером 64 МБ. В сценарии ios, где одновременно может выполняться множество процедур хеширования, это создает большую нагрузку на память хоста.

В случаях, когда это слишком большое потребление памяти, рекомендуется уменьшить параметр памяти и увеличивают коэффициент времени:

Проект RF C рекомендует [2] time = 1, а memory = 64 * 1024 - разумное число. Если использование такого объема памяти (64 МБ) невозможно в некоторых контекстах, тогда параметр времени может быть увеличен для компенсации.

Итак, предполагая, что я хотел бы ограничить потребление памяти до 16 МБ (1/4 рекомендуемых 64 МБ) , мне все еще неясно, как я должен регулировать параметр time: это должно быть умножено на 4 , чтобы произведение памяти и времени оставалось неизменным? Или есть какой-то другой лог c за соотношением времени и памяти в игре?

Answer 1

Проект RF C рекомендует [2] time = 1, а memory = 64 * 1024 - разумное число. Если использование этого объема памяти (64 МБ) невозможно в некоторых контекстах, тогда параметр времени может быть увеличен для компенсации. В этом контексте он пытается сказать: чтобы достичь такой же сложности хеширования, как 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 здесь означает длину результата ha sh, но параметр time может означать «как много раз результат хеширования необходимо повторно обработать sh -ed, пока я не получу конечный результат ».

Таким образом, эти 2 параметра не зависят друг от друга. Они просто контролируют, сколько «экономии затрат на перебор за счет компромисса времени и памяти» вы хотите достичь

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.

Ознакомьтесь с самим API Argon2. Я собираюсь сделать небольшую ссылку и использовать документацию argon2-cffi . Похоже, что интерфейс go использует C -FFI (интерфейс внешней функции) под капотом , поэтому прототип должен быть таким же.

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/N для N ядер. По-видимому, вы должны по существу установить для параллелизма значение cpu count .