[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4EFDBAF8.9070104@hushmail.com>
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
