Client Implementation Details
While I'm writing GRC's reference SQRL client I'm making notes here of things that will need to be fully articulated.
- How is entropy being collected?
- How is the rescue code being obtained?
(Successive multi-precision long division of 256-bits of entropy by 10 to obtain evenly distributed values from 0 to 9, then add '0' to convert to ASCII.
- How is the rescue code being used to encrypt the grand master Identity Unlock Key (IUK)?
Feed the rescue code's 24 ASCII digits (hex values 0x60-0x71) into EnScrypt in natural string display left-to-right sequence. In other words, feed in 24 bytes starting with the first byte of the string to the last.
- Are ALL buffer comparisons of any kind (strings, keys, etc.) being performed in constant time?
For secure crypto work, built-in string/buffer comparison's should never be used as the timing of their return is a direct function of where in the buffer the mismatch occurred. This leaks some of the most crucial information in any cryptosystem. Instead, all string and buffer comparisons must be performed in constant time. To do this, clear an error accumulator, then XOR the contents of the two buffers together then OR the result into the error accumulator. Always scan the entire buffer, and check the result at the end.
- Do all sensitive values (passwords, rescue codes, keys, etc.) reside together in safe guaranteed-volatile memory which is locked into RAM so that it cannot be swapped out to non-volatile memory? And are all of those values being proactively wiped as soon as it is no longer being actively used?