proposal: x/crypto/argon2: add API variants to support a buffer pool

[networkimprov]

argon2.Key() & .IDKey() appear to thrash memory by allocating a (typically) large buffer and using it once.
https://github.com/golang/crypto/blob/master/argon2/argon2.go#L157

This might not scale well where every login on a high-traffic site calls this API to check a password.

Could API variants be added which take a config struct that optionally contains a buffer, so we can use a buffer pool?

@aead @mark-rushakoff @bradfitz

[aead]

In general, that sounds like a legit request to me. The argon2 doc contains a recommendation for such scenarios - however, it is not always possible to follow this advice.

Unfortunately, we cannot just use an argon2-internal global buffer pool - similar to
ioutil.Discard - since we have to allocate a memory-cost dependent buffer. One option may be a function that returns a "derive-function":

New(time, memory uint32, threads uint8) func(password []byte, salt []byte, keyLen uint32) []byte

that returns a closure with e.g. a sync.Pool. The returned closure may be typed
(e.g. type DeriveFunc func([]byte, []byte, uint32) []byte).

Calling code would use this as following:

f := argon2.New(1, 64 * 1024, 4)
key1 := f(password, salt, 32)
key2 := f(password2, salt2, 32)

/cc @FiloSottile

[networkimprov]

I'd want to manage the buffer pool in my code. Roughly:

config := argon2.New(time, memory, threads)
mypool.Put(config.MakeBlockset())
...
go func() { // login handler
   buf := mypool.Get().(argon2.Blockset) // type Blockset []block
   key := config.Key(password, salt, keylen, buf)  
}()

[aead]

I'd want to manage the buffer pool in my code

@networkimprov Any specific reason for that - since that sounds like a significantly more complex API?!

[networkimprov]

Well your argon2.New() is essentially 2 methods; I've added one more, plus a named type. And generally x.New() returns an object.

There are many ways one might manage a buffer pool, not just sync.Pool; we can't lock in one scheme. Also some apps would need to expand or shrink the pool.

[aead]

Well your argon2.New() is essentially 2 methods; I've added one more, plus a named type. And generally x.New() returns an object.

There is now a Config type (or whatever argon2.New returns) which itself has an API (MakeBlockset) plus the Blockset and block (which we either need to export as Block or we change the underlying implementation to use []byte/[128]byte directly). Further, we require that users pass a valid / properly sized Blockset as buffer.

There are many ways one might manage a buffer pool, not just sync.Pool; we can't lock in one scheme.

I don't see why this should be an issue. For instance ioutil.Discard does that.

Also some apps would need to expand or shrink the pool.

Applications that require this behavior can still achieve this by calling argon2.New again after invoking f (f = argon2.New(...)) more than n times or after t seconds.

[networkimprov]

ioutil.Discard must look like any io.Writer; that it uses a sync.Pool is an implementation detail for an object fulfilling io.Writer. Our topic doesn't have a predefined contract.

Re shrink/expand pool "by calling argon2.New again after invoking f ... more than n times or after t seconds." That creates another sync.Pool. Now I have busy & idle f() widgets; how do I pick an idle one?

EDIT: f() can crash with OOM, unless New() allocates all pool buffers, causing a quantum leap in RAM use.

I want to see where I allocate memory and where I can block. And many apps already have a pool of resources which get allocated to connections. A package like this provides a toolkit, not an engine.

In my model, we can drop type Blockset:

config := argon2.New(time, memory, threads)
mypool.Put(config.MakeBuffer())
...
go func() { // login handler
   buf := mypool.Get() // type interface{}
   key := config.Key(password, salt, keylen, buf) // won't panic with OOM
   mypool.Put(buf)
}()

[aead]

ioutil.Discard must look like any io.Writer; that it uses a sync.Pool is an implementation detail for an object fulfilling io.Writer. Our topic doesn't have a predefined contract.

Sorry, but I'm not able to understand the relations here. Why is it not acceptable to implement (a potential) argon2.New function with sync.Pool while e.g. an ioutil.Discard implementation is fine?

Re shrink/expand pool "by calling argon2.New again after invoking f ... more than n times or after t seconds." That creates another sync.Pool. Now I have busy & idle f() widgets; how do I pick an idle one?

The sync.Pool will expand automatically to the max. number of concurrent calls of f since each invocation of f will request a new buffer from the pool (pool.Get(...)) and put it back in the pool once the argon2 hash has been computed:

func New(time, memory uint32, threads uint8) func([]byte, []byte, uint32) []byte {
   // setup sync.Pool
   return func(password, salt []byte, keyLen uint32) []byte {
      b := pool.Get().(*[]block)
      defer pool.Put(b)
     // compute argon2 hash using b
   }
}

When re-assigning f = argon2.New(...) you start with an empty pool again and the previous pool will be collected eventually by the GC. Do you request more fine-grain control over when/how memory is allocated?

I want to see where I allocate memory and where I can block. And many apps already have a pool of resources which get allocated to connections. A package like this provides a toolkit, not an engine.

Maybe I misunderstood the proposal but AFAICS your initial request was about a (potential) performance problem (w.r.t. memory allocation). For example a request handler that hashes a password - The fact that Argon2 is a memory-hard function eventually becomes a performance problem when that request handler becomes a "hot" path. (High-traffic)
Therefore, I inferred that your seeking for a way to reduce the number of memory allocation operations caused by the argon2 package - i.e. by pooling the allocated buffers. Are you additionally requesting an API that not just reduces the number of memory allocations but also allows calling code to control when memory is allocated and how it get pooled?!

The implementation you've showed does not contain a solution for a fundamental problem:

config := argon2.New(time, memory, threads)
mypool.Put(config.MakeBuffer())
...
go func() { // login handler
   buf := mypool.Get() // type interface{}
   key := config.Key(password, salt, keylen, buf) // won't panic with OOM
   mypool.Put(buf)
}()

Let's assume mypool.Get() cannot return the buffer you put into the pool before (via mypool.Put(config.MakeBuffer())) because there are 2 concurrent login handler calls. What does mypool.Get() do in this case? Block?! Return a new buffer - of which size?!

A implementation that uses sync.Pool would need to do the following:

config := argon2.New(time, memory, threads)
mypool := sync.Pool{
   New: func() interface{} {
       return config.MakeBuffer()
   },
}
mypool.Put(config.MakeBuffer())
...
go func() { // login handler
    buf := mypool.Get() // type interface{}
    key := config.Key(password, salt, keylen, buf)
    mypool.Put(buf)
}()

That looks unreasonable more complex to me than the following code - since I'm not able to see why it is necessary to tightly control the allocations to (significantly) reduce the GC preasure:

f := argon2.New(time, memory, threads)
go func() { // login handler
    key :=f(password, salt, keylen)
}()

Also, you cannot avoid the a potential OOM panic in the general case (i.e. sync.Pool) since you don't know whether the pool returns an element from the pool or allocates a new one using its New function.

[FiloSottile]

Is there a benchmark showing that the allocation is significant next to the password hashing work?

If yes, why can't we use a global sync.Pool? It gets drained in two GC cycles, and most applications will use a consistent buffer size (and if not they will tend to grow to the max size, which is fine?).

[aead]

If yes, why can't we use a global sync.Pool? It gets drained in two GC cycles, and most applications will use a consistent buffer size (and if not they will tend to grow to the max size, which is fine?).

Basically my point. However, a global sync.Pool does not work since you may allocate a 64 MiB buffer for one password and a 128 MiB buffer for another one. There is no way (AFAICS) to tell the sync.Pool.New function to allocate different buffers nor to get a buffer of a specific size from the pool.

[balasanjay]

Couldn't we just have an array of 32 pools internally, one for each power of two and use the appropriate one transparently?

(Conceptually, that is. I think we can have even fewer since people are unlikely to need 1 byte buffers, or 4 gig buffers)