Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 30 Dec 2011 14:22:00 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Making a thread safe implementation of bitslice DES

On 12/29/2011 10:34 PM, Jordan Bradley wrote:
> On Thu, Dec 29, 2011 at 4:27 PM, Solar Designer<solar@...nwall.com>  wrote:
>> I asked about input to JtR.  If you're fine with having the input right
>> in the encoding needed for tripcodes, then I don't know what we're even
>> discussing now - there's no issue as-is.
>
> Sorry I misunderstood. In that case I suppose Unicode would be the
> most practical because all the other character maps are contained in
> it as far as I know. The input would have to be converted to their
> proper encoding, for example: shift-jis for tripcodes.

The existing --encoding support for Jumbo could easily be extended to 
handle Shift-JIS but for a format like tripcode this would not add 
functionality, unless we extend it to optionally do 8-bit -> 8-bit 
conversions. This is a fair bit down on my to-do list as it only adds 
convenience, and may hit performance.

We could make a dumb-sjis external mode though, similar to the dumb16 
one (the latter outputs UTF-8). This is likely very trivial.

For incremental mode, I think the quickest solution would be a separate 
--inc16 mode that is almost identical to the current one except it 
handles 16-bit characters internally (be it UTF-16 or any 16-bit 
representation of JIS). Together with some --enc glue, I think this 
would "solve" the problem for Unicode and Shift-JIS in one fell swoop.

magnum

Powered by blists - more mailing lists

Your e-mail address:

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