Consider: reduce in-memory passing of signing key

[NiloCK]

minimizing time-in-memory for secrets is a security best practice (per diligence audit). Currently the key is passed into protocol method Crank, which is generally expected to be a fast in-memory operation but can potentially be slowed if, eg, channels accumulate many states.

Three approaches: (roughly increasing engineering effor)

1. replace Crank(secretKey *[]byte) with Crank(getKey func() *[]byte)

the existing Store method GetChannelSecretKey fits this type definition. Crank can then pull the key only when new state side effects are generated, and just-in-time.

2. do option 1, and also on the other end: crypto.SignEthereumMessage can be changed to recieve getKey func() *[]byte as well. This way just-in-timeliness is guaranteed, and for extra paranoia the key bytes can be manually written with zeros immediately after their use.

3. add a utility function to the store which recieves functions that want to use the secret key. Roughly:

type privacyFunc func(secretKey []byte) interface{}, err

Store {
   // other stuff
   getChannelSecretKey() *[]byte // made private
   ApplyKeyTo( f privacyFunc )
}

func (ms MockStore) ApplyKeyTo( f privacyFunc ) interface{} {
  var key []byte = ms.getChannelSecretKey()
  ret, err := f(key)
  for i, _ := range key {
    key[i] = 0
  }
  return ret, err
}

Benefit here is an enforcable single code location where secret key is loaded, and (maybe a benefit?) the key itself not crossing module boundaries.

Difficulties are:

• more abstract access to the secret key, possibly involving higher-order functions where we wish to pass data into the privacyFunc
• lack of type-safety. Presumably solved via generics in go 1.18 (upcoming version)