Optimize Base-64 Encoding Algorithm

[nlordell]

The WebAuthn signing process requires encoding the challenge to base64. The "challenge" is a relying party chosen value for replay protection. In the passkey design we use, this is the hash of the data we are verifying for, and assume replay protection already applies to it (for example, the nonce is included in the Safe transaction hash which gets verified and ensures replay protection).

The issue is that the challenge is computed as a bytes32 on-chain, but needs to be encoded in base64 for computing the clientDataJSON which is ultimately used in computing the "signing message" (i.e. what is actually signed by the private key).

Currently, the base64 implementation that is used in FCL and in the experimental contracts first:

• Converts the bytes32 to a bytes memory array (thus incurring unnecessary allocations)
• Operates on arbitrarily sized bytes memory arrays (thus adding code complexity and marginal runtime costs)
• Returns a string memory which needs to be concatenated to an existing bytes memory (which incurs a copy loop - at least until mcopy is available - which has a non-negligible runtime and codesize cost).

The proposal is to instead compute the base64 incoding in-place with an algorithm specialized for 32 bytes of data, thus avoiding memory allocations and copies, and additional complexity for supporting arbitrary sized arrays.

The expected outcome is a specialized base64 encoding implementation for use in the WebAuthn signature validator contract.