Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ