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.