0
$\begingroup$

Let's say we generate a 256-bit key like: secret = base64(csprng(32)). Assume someone using the secret ascii-decodes the base64-encoded string and uses the output as a key (i.e. ascii_decode(secret)).

Note that in this specific scenario the key is used in a HMAC-SHA256 function.

What are the security implications of doing this? Are there any possible issues?

$\endgroup$
  • $\begingroup$ Just to be clear, what is ASCII decoding exactly? $\endgroup$ – Paul Uszak Aug 18 '17 at 15:23
  • $\begingroup$ As an example ascii_decode("QQ==") == [0x51, 0x51, 0x3d, 0x3d] $\endgroup$ – bayo Aug 18 '17 at 20:00
2
$\begingroup$

You only have $6$ bits of entropy in $8$ bits of your output - in general that does not fullfill the requirements for a cryptohraphic key of being drawn uniformly random over the full range. In general, this can potentially be desastorous: You have no security guarantees, because no security proof applies any more. In the worst case such a bias in the key can completely break the system - without anyone noticing.

In a general setting however, you should also notice that those $256$ bit output of the CSPRNG are not $256$ bit any more if you encode it as Base64 and decode as ASCII. It should be $344$ bit output, and that doesn't fit any more, if a $256$ bit key is expected.

In your specific case with HMAC it is probably fine - because HMAC is equipped to handle different keylengths: The first thing HMAC does is to transform the key into the correct length. If the key is too short, it is padded, if it's too long the hash function is used on the key. You have $256$ btis of entropy in a longer string, so this should be fine.


But please note: It is unusual that an cryptographic function is equipped to handle variable keylengths, this is a lucky catch. While it should work in this case, in general it is a really bad idea to neglect the assumptions about the key. The term key implies often, that it is drawn uniformly from a specific range and considered in binary format.

$\endgroup$
  • $\begingroup$ If we can write a security proof for p = 1/256, we (not me) should be able to write a proof based on p = 1/64. And that proof would have to factor in an overall 192 bits of input entropy. $\endgroup$ – Paul Uszak Aug 18 '17 at 15:24
  • $\begingroup$ @PaulUszak This is just one very specific example, where I think such a proof is possible. But I would strongly suggest against doing such a proof: It's based on pure luck, that it would work in this specific case. Neglecting the assumptions of a security proof is an almost-guaranteed way to break security for all but the most basic protocols. $\endgroup$ – tylo Aug 18 '17 at 15:44
0
$\begingroup$

No, I don't think that there are any security issues with this approach.

  1. A truncated base64 encoded key of 32 characters still contains 192 bits of entropy. 192 > 128 and 128 bit algorithms are ostensibly considered secure. Certainly secure enough for Joe Public if perhaps not for strategic defence.

  2. Base64 encoding only utilises 6 bits out of every available 8, but this is on a byte by byte basis along the entire key length. This clearly introduces a 2 bit bias to the key. However, strong cryptographic functions are considered randomising functions. Indeed, they are used for randomness extraction in true random number generators, and those tend to have (relatively) huge biases. You can easily have 33% biases compared to your 25%. The output becomes uniformly random anyway due to the avalanche effect. There is the concept of a weak key, but it's hard to imagine a weak key that still contains 192 bits of entropy.

So unless HMAC-SHA256 is extremely and weirdly susceptible to biased keys, the 192 bits of entropy plus the avalanche effect will keep your data secure. The bias simply gets subsumed by the 192 bits of randomness and disappears.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.