3 ms·
Thanks for the reminder. You could encode with a "base255" algorithm that just excludes the null byte to retain more entropy within 72 bytes.
by benmanns 10y ago
Thanks for the reminder. You could encode with a "base255" algorithm that just excludes the null byte to retain more entropy within 72 bytes.
- cmiller1 10y agohttp://stromberg.dnsalias.org/svn/base255/trunk/ http://stromberg.dnsalias.org/svn/base255/trunk/
- arielb1 10y agoEven hex-encoding for 288 bits of entropy is plenty good enough.
- KMag 10y agoMuch faster than all of those multiplications that invertibly maps 64 bytes to 65 bytes without nulls: replace first null with 255. Every later null, replace with the index of the previous null. Make the final byte the index of the last null (or 255 if no nulls were replaced). In this way, you've replaced the nulls with a linked list of the locations where nulls used to be. To invert the transformation, just start at the final byte and walk the linked list backward until you hit a 255. (You'd never do the inversion in practice, but the existence of the inversion algorithm proves that no entropy was discarded.) Use the time saved by not doing base 255 conversion to increase your iteration count.
- kijin 10y agoAny time you spend or save on these kinds of transformations is going to pale in comparison to the bcrypt step. It might not even amount to a single iteration.