Interesting. I expected that you would decode `msg` here to check whether `decodedMsg == msg`. That was to show that these keys indeed work as intended. This implementation surprises me.

```suggestion assert.NoError(t, err) ```

Can't the if be replaced by its content? I hope `assert.NoError` checks whether an error is present itself, otherwise that function makes only limited sense. Correct me if this function categorically fails the test. ```suggestion assert.NoError(t, err) ```

I think an additional statement where you encode and then decode something should be added. This is just to show the integrity of the keys, even though I believe the crypto package already should take care of that.

a smal simple unit test would be nice :)

Is there a reason why this parameter is a generic interface and not a `rsa.PublicKey`? Because while it most likely can accept anything, the only thing I think it should accept is a `rsa.PublicKey`. Everything else is most likely a runtime error. So, the result should most likely be ```suggestion func pemBlockForPub(pub rsa.PublicKey) (string, error) { ``` or ```suggestion func pemBlockForPub(pub *rsa.PublicKey) (string, error) { ```

```suggestion ```

I don't think the `publicKey` function is needed as it is called only here. Additionally, the function declaration seems overly complicated to me. If I understand go syntax correctly, the following should still be valid, right? ```suggestion pubPem, err := pemBlockForPub(&priv.PublicKey) ```