Date: Wed, 9 Mar 2011 16:20:24 -0600 From: "jfoug" <jfoug@....net> To: <john-dev@...ts.openwall.com> Subject: RE: --utf8 option, proof of concept >From: magnum [mailto:rawsmooth@...dband.net] >>On 03/09/2011 04:16 PM, jfoug wrote: >> >> Also, I increased the plaintext_length if in utf8 >> mode. 40 may not be large enough. We want up to 27 unicode chars. >The call > >This is excellent! Here are the changes to NT_fmt.c, and to ConvertUTF8.c/h. I set the buffer to handle up to 95 utf8 byte strings. You asked for a reason to not go up to 4x 27, and I have one. It starts to degrade performance. Likely due to larger memory working set. >Would we benefit from knowing the length in advance? You do not know it in advance, but do know it 'after' the call, before you load the buffers. Yes, there is benefit to reworking the loading logic a little. Only a couple percent, but a couple percent gain is still a couple percent gain. >I have another problem, I think I've got mscash and mscash2 working >correctly now (with unicode salt) but I don't know how to produce test >hashes for the latter. I have no ideas. Jim.
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux - Powered by OpenVZ