We are talking about ways to establish shared secrets where both the Tool Consumer and Tool Provider contribute key material to an overall shared key used to sign and validate OAuth messages. Often these “secrets” are treated as strings of varying length. Common practice is to choose random numbers wih something like the uniq() PHP function or Java’s UUID() and then hex encode the random bits for strings of varying length.
Using the current approach, (a) we cannot assume the serialization of this data and (b) the secrets can be of effectively any length (short or long). By not specifing an encoding that allows us to transmit bit-level randomness, we implicitly shorten key lengths by using a non-predictable encoding so we have to fall back to strings and likely strings with a very limited character set.
We have not yet seen situations where secrets include non-Latin1 characters. As we move to moving secrets across web services – serialization becomes inclreasingly important and if we get too tricky with character sets we might find ourselves with some interoperability problems.
My proposal is to define the binary bit-length of the two halves of the “split secret” and insist that these are serialized using a known serialization so both sides can de-serialize these pieces to cryptographically strong secrets with a well understood bit length.
So each of the sides contributes 512 cryptographically random bits to the shared secret. When each side communicates the secret – they are serialized and transferred using 128-character hex encoded using only lower case letters for a-f. An example of a half-secret is as follows:
To form the OAuth consumer secret the two hex halves are just concatenated as hex strings. Since the OAuth signing simply appends the key to the message and computes a digest, we can make use of all 1024 bits of randomness by using a 256 character hex-encoded key. While this means that the pad has a known character set (0-9) and (a-f) – it makes up for that by being 4 times longer. Also we avoid any encoding problems if we allow non-latin1 characters in the OAuth shared secret.
By speicfing the bit length and encoding – both sides can build database models that store secrets in fixed length fields.
By insuring there are 1024-bits of cryptographically strong randomness – other uses like sending data between the sides with two-way encryption approaches like Blowfish or AES can create shorter bit length keys from the known 1024-bits of randomness.
I am just putting this up because I like openness in the design of any security scheme in case I made any mistakes or incorrect assumptions.
This design is not at all final – comments are very welcome.