How to Generate AES key from Miner Address

[porcuquine]

Description

This is a follow-up issue spawned from discussion in comments here: https://github.com/filecoin-project/go-filecoin/pull/469. See comment by @phritz labeled BLOCKING.

The issue:

The string we pass as miner address when creating a prover needs to be used as an AES key.

From crypto/aes:

// NewCipher creates and returns a new cipher.Block.
// The key argument should be the AES key,
// either 16, 24, or 32 bytes to select
// AES-128, AES-192, or AES-256.
func NewCipher(key []byte) (cipher.Block, error) {
    k := len(key)
    switch k {
    default:
        return nil, KeySizeError(k)
    case 16, 24, 32:
        break
    }
    return newCipher(key)
}

How (specifically) should the value passed be derived?

NOTE: address specification is in flux, so it may not make sense to attempt to resolve this issue until it stabilizes.

That said, details here (#276) suggest that if underlying address data remains similar, ~we should eventually be able to take the 20-byte hash-part of the address and base32 encode it (with a base32 implementation which always yields 32-byte output for 20-byte input, unlike what addresses currently use -- the source of the linked bug).~ [EDIT: no point in stretching out 20 bytes of pseudo-randomness to 32 -- which is effectively just alphabet-shaped padding.]

Those with specialized knowledge and/or strong opinions should discuss here so we can implement the right thing when the time comes.

Acceptance criteria

Risks + pitfalls

Where to begin

[dignifiedquire]

This should be independent of our address format, as there could be different encodings or even ID vs hash of pubkey addresses.

My suggestion would be

• given an address that contains a hash of the pubkey:
  • extract the hash of the pubkey
  • hash it to the correct length
• given an address that contains only an ID
  • find the address matching the id
  • extract the hash of the pubkey
  • hash it to the correct length

Hashing an input to something larger, has the drawback that we reduce the input randomness, so ideally we would instead hash the pubkey to the size that we actually want.

I am not sure however if we can retrieve the pubkey in all cases need, but I do think we can, and if so that would be a preferrable solution.

[dignifiedquire]

@whyrusleeping can I get some input on my suggestion please?

[whyrusleeping]

Sounds good to me, just use the hash of the public key. should work in all cases that i am aware of

[laser]

@dignifiedquire

hash it to the correct length

What is the correct length? Which hashing function shall we use? BLAKE2b?

[dignifiedquire]

• the correct length is either 16, 24 or 32 bytes depending on the AES version you are trying to use
• to achieve that you should be able to use Blake2b, which has adjustable digest size, instead of simply truncating

[phritz]

@clkunzang to look at this

[porcuquine]

cc: @nicola

Detail: AES is no longer a consideration.

Without going into gratuitous detail here, the safe way to handle this is for the Filecoin Node to pass a maximum of 254 significant bits to FPS (Filecoin Proving Subsystem). This underlying fact allows for a variety of possible answers to the question at hand. Whichever one we select will need to be specified carefully, since there ways to get it wrong. I don't want this comment to be the canonical specification, though – so I will break further discussion out in #493.