# Expanding truly random key into printable password for successive hashing

The STUN network protocol defines its client authorization in the terms of message-integrity check employing the following scheme [RFC5389, section 10.2]:

$$\DeclareMathOperator{\HMAC}{HMAC} \DeclareMathOperator*{\SHA}{SHA1} \DeclareMathOperator{\MD}{MD5} \mathrm{MessageIntegrity} = \HMAC_{\SHA}(\MD(k), m),$$ where the key $$k$$ is defined as the following string concatenation: $$k = \mathrm{username} :\mathrm{realm}:\mathrm{password}$$ In the above expression both username and realm may be treated as constant ASCII strings known to both the server and client (or any traffic eyedropper). The password, however, is a shared secret and never transmitted in plaintext.

I'm not particularly happy about this scheme, but it's that we have now. What I want is to generate a reliable enough password with as large entropy as possible.

1. Given that the password may contain only printable ASCII text, what password length would be enough to get a reasonable level of security if each password character is chosen at random?

2. Let's assume there are only $$N$$ bits of entropy available to generate the password, $$N \approx 80...120$$. Is it okay to seed these bits into a PRNG and generate a longer password? What would be the required password length in this case? Is it a good idea to generate a really long password in this case?

• The answer to 1 is 22 alphanumeric characters Mar 21 '18 at 0:58

Q1. Each printable ASCII character gives you $\log_2 M$ bits of security where $M$ is the number of printable characters, assuming uniformity and independence between the characters [the second assumption does not hold in natural language].
For ASCII $M=106,$ which gives approximately $6.74$ bits/character, but this is likely to be a massive overestimate of security unless a good randomness source is used to generate the passwords.